New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don’t add onclick listener to React root #13778

Merged
merged 6 commits into from Oct 9, 2018

Conversation

Projects
None yet
6 participants
@philipp-spiess
Collaborator

philipp-spiess commented Oct 4, 2018

Fixes #13777

As part of #11927 we introduced a regression by adding onclick handler to the React root. This causes the whole React tree to flash when tapped on iOS devices (for reasons I outlined in #12989 (comment)).

To fix this, we should only apply onclick listeners to portal roots. I verified that my proposed fix indeed works by checking out our DOM fixtures and adding regression tests.

Strangely, I had to make changes to the DOM fixtures to see the behavior in the first place. This seems to be caused by our normal sites (and
thus their React root) being bigger than the viewport:

An alternative approach to finding out if we're appending to a React root would be to add a third parameter to appendChildToContainer based on the tag of the parent fiber.

Don’t add onclick listener to React root
Fixes #13777

As part of #11927 we introduced a regression by adding onclick handler
to the React root. This causes the whole React tree to flash
when tapped on iOS devices (for reasons I outlined in #12989 (comment)).

To fix this, we should only apply onclick listeners to portal roots. I
verified that this fix indeed worked by checkout out our DOM fixtures
and added regression tests as well.

Strangely, I had to make changes to the DOM fixtures to see the behavior
in the first place. This seems to be caused by our normal sites being
bigger than the viewport:

![](http://cl.ly/3f18f8b85e91/Screen%20Recording%202018-10-05%20at%2001.32%20AM.gif)

An alternative fix would be to add a third parameter to
`appendChildToContainer` based on the tag of the parent fiber. Although
I think relying on the `_reactRootContainer` property that we set on the
element is less intrusive.
@gaearon

gaearon approved these changes Oct 4, 2018

I think this is reasonable

@gaearon

This comment has been minimized.

Member

gaearon commented Oct 4, 2018

This seems to be caused by our normal sites (and thus their React root) being bigger than the viewport:

So the issue only appears when React root is bigger? Or when it is smaller?

I didn't see this in testing. But I don't remember what I used for testing.

@sizebot

This comment has been minimized.

sizebot commented Oct 4, 2018

Details of bundled changes.

Comparing: d836010...ea25fe7

scheduler

File Filesize Diff Gzip Diff Prev Size Current Size Prev Gzip Current Gzip ENV
scheduler.development.js n/a n/a 0 B 19.17 KB 0 B 5.74 KB UMD_DEV
scheduler.production.min.js n/a n/a 0 B 3.16 KB 0 B 1.53 KB UMD_PROD

Generated by 🚫 dangerJS

@philipp-spiess

This comment has been minimized.

Collaborator

philipp-spiess commented Oct 4, 2018

So the issue only appears when React root is bigger? Or when it is smaller?

Only when the React root is smaller than the viewport. In the gif you see the red flashing as long as the text does not cause the viewport to overflow.

This (kinda) explains my strange observations here as well: #12717 (comment)

@@ -341,8 +341,16 @@ export function appendChild(
parentInstance.appendChild(child);
}
type DOMContainer =

This comment has been minimized.

@philipp-spiess

philipp-spiess Oct 4, 2018

Collaborator

I can also export this type from ReactDOM if that makes more sense.

This comment has been minimized.

@gaearon

gaearon Oct 9, 2018

Member

Would make more sense than duplicating to me.

@@ -360,7 +368,7 @@ export function appendChildToContainer(
// event exists. So we wouldn't see it and dispatch it.
// This is why we ensure that containers have inline onclick defined.
// https://github.com/facebook/react/issues/11918
if (parentNode.onclick === null) {
if (!container._reactRootContainer && parentNode.onclick === null) {

This comment has been minimized.

@acdlite

acdlite Oct 5, 2018

Member

Compare to null and undefined explicitly, plz

@@ -360,7 +368,7 @@ export function appendChildToContainer(
// event exists. So we wouldn't see it and dispatch it.
// This is why we ensure that containers have inline onclick defined.

This comment has been minimized.

@NE-SmallTown

NE-SmallTown Oct 5, 2018

Contributor

Should we modify the comments together?

// https://github.com/facebook/react/issues/11918
if (!container._reactRootContainer && parentNode.onclick === null) {
const {_reactRootContainer} = container;

This comment has been minimized.

@acdlite

acdlite Oct 5, 2018

Member

Another style nit: we don't use destructuring, with some exceptions like module-style objects or function args (component props).

}
ReactDOM.render(<Component />, container);
expect(typeof portalContainer.onclick === 'function').toBeTruthy();

This comment has been minimized.

@gaearon

gaearon Oct 9, 2018

Member

You can just do expect(typeof ...).toBe('function'). Not that it matters.

@gaearon

gaearon approved these changes Oct 9, 2018

Feel free to merge

@gaearon

This comment has been minimized.

Member

gaearon commented Oct 9, 2018

(see nit in #13778 (comment))

@philipp-spiess philipp-spiess merged commit f47a958 into facebook:master Oct 9, 2018

1 check passed

ci/circleci Your tests passed on CircleCI!
Details

@philipp-spiess philipp-spiess deleted the philipp-spiess:ios-tap-highlight branch Oct 9, 2018

linjiajian999 pushed a commit to linjiajian999/react that referenced this pull request Oct 22, 2018

Don’t add onclick listener to React root (facebook#13778)
Fixes facebook#13777

As part of facebook#11927 we introduced a regression by adding onclick handler
to the React root. This causes the whole React tree to flash when tapped
on iOS devices (for reasons I outlined in
facebook#12989 (comment)).

To fix this, we should only apply onclick listeners to portal roots. I
verified that my proposed fix indeed works by checking out our DOM
fixtures and adding regression tests.

Strangely, I had to make changes to the DOM fixtures to see the behavior
in the first place. This seems to be caused by our normal sites (and 
thus their React root) being bigger than the viewport:

![](http://cl.ly/3f18f8b85e91/Screen%20Recording%202018-10-05%20at%2001.32%20AM.gif)

An alternative approach to finding out if we're appending to a React
root would be to add a third parameter to `appendChildToContainer` based
on the tag of the parent fiber.

@gaearon gaearon referenced this pull request Oct 23, 2018

Merged

Add 16.6.0 changelog #13927

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment