Chrome 73 breaks wheel events

[blixt]

Similar to #8968, but for the wheel and mousewheel events. They are now passive by default for root elements in Chrome 73 (currently beta) which means React apps that have custom scrolling/zooming behaviors will run into issues.

The quick fix may be to manually add event listeners with {passive: false} but has the React team considered if this should be configurable for the React event handler?

Blog post from the Chrome team here: https://developers.google.com/web/updates/2019/02/scrolling-intervention

[gaearon]

We’ve definitely considered adding support for passive events and that’s on our longer term roadmap, but we’d rather not rush such an important API addition because of the Chrome intervention timings.

[gaearon]

Do you mind creating a small repro case to verify it's broken now?

[blixt]

Sure thing, here's a repro:

https://codesandbox.io/s/6zn44nmjvn

In Chrome stable / Safari / etc the box will move but the rest of the page will remain static. In Chrome 73, the entire page rubber bands as you scroll around (the box also moves). Since rubber banding only happens with a trackpad, make sure to test it with one.

Also note all the red errors in the console due to the intervention.

[nhunzaker]

The quick fix may be to manually add event listeners with {passive: false} [...]

I have mixed feelings on it, but I wonder if this is the best approach. We don't need to feature check for event options support either because all scroll events are captured anyway so the object coercing to true is fine:

react/packages/react-dom/src/events/ReactBrowserEventEmitter.js

Line 140 in f33e579

trapCapturedEvent(TOP_SCROLL, mountAt);

This at least keeps the React behavior consistent while passive events are being figured out, but definitely presses the need to add more configuration to events.

[nhunzaker]

For me, at least on Linux and ChromeOS, this is easier to reproduce with an actual mouse with a mousewheel (it could be that OSX emits mouse wheel events for trackpads).

I added a linear gradient to the background to better illustrate what's going on (event.preventDefault() should prevent scrolling on the parent, but it doesn't):
https://codesandbox.io/s/x3m6m17jop

Here's a vanilla example that uses { passive: false } to demonstrate the intended behavior:
https://codepen.io/nhunzaker/pen/rREpGo?editors=1010

The solution could be to just pass { passive: false } . I can prep a PR for that, even if we decide to hold off.

[nhunzaker]

I think this goes against the wishes of the Chrome team, but it's the only solution I can think of to maintain existing behavior while a passive event API is being figured out.

[nhunzaker]

Talking with @sophiebits: it sounds like we should hold off on making a change until we clamp down a passive event listener API.

We shouldn't undermine changes Chrome believes are important for improving site performance. If they have found that most scroll/wheel event listeners should be passive, that extends to React apps as well. We're shouldn't contribute to making apps slower for most cases when they don't need to be.

Until a passive event API is available to React, one way to work around this is to use a ref to attach a non-passive event listener. (Edit: this is a work in progress. See #15036).

I'm not super familiar with using TypeScript with hooks, but I've done my best to form @blixt's example to use a ref to attach a passive listener:

https://codesandbox.io/s/zzqxp1yvy3

I imagine others will come to the issue board confused about this change, so it'll be important to have a clear path forward for future issues. Are there ways to improve on the solution above?

[byronwall]

We shouldn't undermine changes Chrome believes are important for improving site performance.

Chrome shouldn't be changing default options that have such a significant impact on usability. Every site that relies on default {passive:false} behavior is now broken. Even if React pushes a fix, this is still broken for existing sites. The pace at which Chrome is willing to break standards is staggering. The passive option wasn't in the wild until Chrome 51 (June 2016) and now the default has been changed. Consider me unsympathetic to doing what "Chrome believes is important".

[cherscarlett]

@byronwall I strongly believe the Chrome team thinks very carefully and thoughtfully about the changes they make, and I don't believe it is right to call into question what they should or should not be doing without the full holistic picture of the drive behind the change and the expected outcome. It might be nice to get direct input here from someone who can provide a larger context that can help drive the path forward in a healthy way.

[catamphetamine]

@cherscarlett

I strongly believe the Chrome team thinks very carefully and thoughtfully about the changes they make, and I don't believe it is right to call into question what they should or should not be doing without the full holistic picture of the drive behind the change and the expected outcome.

One must not question the existence of God because one's mind is vanishingly small compared to the mind of God and so one can't possibly ever grasp a hint of His divine majesty.
If God tells you do something you must do that without questioning or hesitation, otherwise you're a heretic and must be judged by the Holy Inquisition and later bunt alive to clean your soul of the sins and earn forgiveness because God loves all of his children.

[nhunzaker]

@catamphetamine Sorry to hide your comment, but it doesn't help us come to a resolution and I want to keep this issue focused for others coming to the React issue board that might be confused.

The Chrome team didn't do this in a vacuum, and took the time to research this thoroughly, as linked in the original issue description (https://developers.google.com/web/updates/2019/02/scrolling-intervention):

Our goal with this change is to reduce the time it takes to update the display after the user starts scrolling by wheel or touchpad without developers needing to change code. Our metrics show that 75% of the wheel and mousewheel event listeners that are registered on root targets (window, document, or body) do not specify any values for the passive option and more than 98% of such listeners do not call preventDefault().

Much like React, Chrome is in a position to improve user experience across a broad base of users. Both teams are aligned in this goal, even if coordinating on a change like this could have been smoother.

Forcing wheel events to be impassive would create additional breaking changes for React users, while undermining performance improvements on the platform. Let's figure out the best API for passive event handlers in React moving forward. However in the interim, let's also come up with a good general purpose solution so that it's easier for React users to handle this change.