-
Notifications
You must be signed in to change notification settings - Fork 46.8k
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 emulate bubbling of the scroll event #19464
Conversation
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 189132c:
|
Details of bundled changes.Comparing: 217ecf5...189132c react-dom
ReactDOM: size: 0.0%, gzip: 0.0% Size changes (stable) |
Details of bundled changes.Comparing: 217ecf5...189132c react-dom
Size changes (experimental) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great stuff :)
What does onScrollCapture do? |
Not sure what you mean. It does regular capturing? That mirrors the browser behavior AFAIK. |
Meaning, it would currently capture at the root and call React capture listeners. |
I'm thinking this is worth putting behind a flag. Kind of risky. |
I'm gonna land this behind a flag so we can quickly roll back if something's broken. |
Currently, scroll event is somewhat broken on master.
This will fire both handlers if we scroll the child:
But this will not fire the parent handler if we scroll the child:
In other words, bubbling the scroll event currently doesn't work if the event target itself doesn't have a React listener.
This is a regression in the modern system.
Possible Fixes
This is based on @trueadm's writeup.
Option 1: Add native
scroll
handler to everydiv
so that we can't "miss" the event — whether it has a React handler or not. This is a similar strategy we use for other events that don't bubble in the browser (e.g.toggle
,invalid
,play
, etc). However, for those cases, we know which elements need it (e.g.audio
andvideo
). Adding ascroll
listener to every singlediv
seems untenable. So this is ruled out for performance reasons.Option 2 (Breaking Change): Stop emulating bubbling for
onScroll
. It it confusing anyway (Bug: Strange onScroll behaviour when child editing #19156, Strange onScroll behaviour #15723). This is what this PR does. The downside is that now this event is special and different from all others.Option 3 (Even Bigger Breaking Change): Stop emulating bubbling for all events that don't bubble in the browser. This includes
invalid
,load
,toggle
,close
,cancel
, and media events. We could consider this but it's a bigger breaking change. Arguably, some of them, likeonInvalid
, are actually useful and not too confusing to bubble. So I think this needs to wait until 18.Option 4 (Status Quo): We could go back to React 16 behavior, which attaches
onScroll
in the capture phase. That would solve the current inconsistency, but wouldn't be in line with our strategy for how nested Reacts should work. It also wouldn't solve the problem that bubblingonScroll
is inherently confusing.