-
Notifications
You must be signed in to change notification settings - Fork 47k
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
Touch/Wheel Event Passiveness in React 17 #19651
Comments
We briefly discussed with @sebmarkbage and since the goal of 17 is to be as close to 16 as possible (while fixing interop), we're going to emulate Chrome's behavior and treat these as passive by default when attaching to roots. This doesn't solve the usability issue but that's orthogonal to the 17 release and should not block it. |
FYI, Firefox does the intervention as well. |
Is there a definitive list of affected events? I take it, we have:
https://docs.google.com/document/d/1II7oSIpd8pK91V5kEM3tDLKcIj398jOJn8Niqy6_loI/edit Anything else? |
MDN has a list for this. (I'm not sure whether the list is definitive or not.) |
Seems like it's just these four. (I excluded |
As far as the "do nothing" option is concerned: This seems like this is likely a bug in lighthouse (or otherwise it's a missing feature in react as per your first option). The intervention claims to only effect window and document level events, for performance reasons. If that's not true, then indeed it's a missing react feature to not be able to mark an event as passive. As far as "don't do delegation for effected events", I don't think that can address the problem. |
This is correct.
In my understanding, there is still a performance implication. But doing it for direct bindings is just a more breaking change so they weren't able to do it. |
Chrome did an "intervention" back in the day, breaking all React touch and wheel listeners which used
e.preventDefault()
(#14856) because React happened to attach them to thedocument
.In React 17, events are no longer attached to the
document
. This happens to "undo" Chrome's intervention (#6436 (comment)). However, since this functionality is already broken in 16 and we haven't patched it up, it seems like this would just be a performance regression for the majority of cases.It seems like we have a few options:
e.preventDefault()
is broken, just like it got broken in 16 by Chrome.e.preventDefault()
.document
level and not individual elements — and conceptually React users were putting their handlers on individual elements. Delegation is just an implementation detail.Filing this to be resolved before 17 final.
The text was updated successfully, but these errors were encountered: