Default to passive: true on document level wheel/mousewheel event listeners

[sahel-sh]

Chromium/Blink would like to propose an intervention where the passive option for wheel/mousewheel event listeners added to Document level objects would be true by default. To opt out developers can explicitly specify passive: false when they want to prevent scrolling/zooming.

This intervention is the wheel equivalent of touch scroll intervention which is implemented by Chrome (since M56), Safari¹, and Firefox².

Our statistics show that:

• On Windows and Mac platforms scrolling by mouse wheel (and touchpad) accounts for more than 90% and 96% of scrolling respectively.
• 75% of the wheel event listeners added to a Document level element do not specify passive option and more than 98.5% of such listeners do not call preventDefault().

See more details in Document Level Passive Wheel Event Listener Intervention

---

1: Tried on Safari 11 (IOS 11.4)
2: Tried on Firefox 61

[hober]

cc @smfr @grorg

[sahel-sh]

/cc @staktrace @smaug----

[sahel-sh]

/cc @ChumpChief

Since high precision touchpad scrolling on Edge is already not blocked on wheel events. Edge might be implicitly in favor of the intervention.

[ChumpChief]

Yes, Edge is in favor. I've seen too many analytics libraries throwing benign wheel listeners on the document :)

I'd guess most pages with document-level preventDefaults are also non-scrollable, since it's weird for a user to see overflowing content and a scrollbar but not be able to scroll with mousewheel. Maybe some "parallax" sites that eat the wheel to apply their own physics/animation? Even with this intervention these probably function approximately as expected if setting scrollTop in script wins over the scroll animation.

That said, I'm now observing that in Chrome the scroll animation wins over setting scrollTop in script. Is that expected? Is there a means for a developer to halt an in-progress scroll animation in Chrome?

http://jsfiddle.net/gcxof62e/

You might want to consider changing this behavior to match Edge/FF to further reduce the compat risk of the intervention.

P.S. Precision Touchpad doesn't fire any wheel events in Edge so it's perhaps not quite fair to compare against. But regardless this intervention seems good.

[staktrace]

I don't have any objections to this intervention either. It should be straightforward to implement in FF as well.

[sahel-sh]

That said, I'm now observing that in Chrome the scroll animation wins over setting scrollTop in script. Is that expected? Is there a means for a developer to halt an in-progress scroll animation in Chrome?

Since M65 Chrome is handling wheel events asynchronously: https://www.chromestatus.com/feature/5728708706959360
In http://jsfiddle.net/gcxof62e/ if the developer wants to set document.scrollingElement.scrollTop they should preventDefault the wheel event and specify that the event listener is blocking.

[ChumpChief]

Love the scroll latching and async events :)

This is a slightly different point though - regardless of whether a developer is setting scrollTop in response to the wheel event or in response to something else, it seems that developer cannot interrupt the animation.

In this specific case, the compatibility risk I'm highlighting is for document-level script takeover of scrolling (e.g. maybe Nicescroll would be an example). Since these are not specifying passive: false today, I suspect the script-driven scroll animation might fight with the native scroll animation for some strange visual effects. Whereas if setting scrollTop halts the native scroll animation like in Edge and FF, then I suspect the script-driven scroll animation would be able to take over from the native animation and function mostly as expected (maybe barring a frame or two of native scrolling animation), potentially partially mitigating that compatibility risk.

In any case, I'm in favor of the intervention. Just offering a suggestion in case issues are discovered on that type of construction.

[sahel-sh]

Love the scroll latching and async events :)

This is a slightly different point though - regardless of whether a developer is setting scrollTop in response to the wheel event or in response to something else, it seems that developer cannot interrupt the animation.

In this specific case, the compatibility risk I'm highlighting is for document-level script takeover of scrolling (e.g. maybe Nicescroll would be an example). Since these are not specifying passive: false today, I suspect the script-driven scroll animation might fight with the native scroll animation for some strange visual effects. Whereas if setting scrollTop halts the native scroll animation like in Edge and FF, then I suspect the script-driven scroll animation would be able to take over from the native animation and function mostly as expected (maybe barring a frame or two of native scrolling animation), potentially partially mitigating that compatibility risk.

In any case, I'm in favor of the intervention. Just offering a suggestion in case issues are discovered on that type of construction.

I understand your concern about the fight between script-driven scroll animation and the native scroll animation which is the current behavior of Chrome and Firefox (tried http://jsfiddle.net/gcxof62e/ on 60.2.0esr (64-bit))
However this intervention won't change/add any compatibility risks: Regardless of the value of the passive option, even in cases that it used to be false by default and this intervention changes it to be true, with async wheel events if the first wheel event is not prevented by default the rest of the wheel events in the current scroll sequence are not cancelable and the fight between script-driven scroll animation and the native scroll animation will happen anyway with our without this intervention.

[pauljohnknight]

Hi

Since this has been implemented it has broken a number of smooth-scroll plugins / libraries that remove the 'judder' created by a traditional mouse wheel when scrolling on Chrome.

How would you set explicitly set passive: false as mentioned in the original post on this thread via javascript, as a stand-alone function (to save me going through all the code of a plugin finding where best to place it)?

Any help would be wonderful.

Paul.

@RByers or
whoever implemented this change , you studied web sites but did you study chrome extensions and chrome apps?

Chrome extensions share same zoom level across popup, background, options and all other HTML documents.

That means if a chrome extension is not able to prevent users from zooming in and out on certain pages then the zoom level for all pages gets messed up and UI across all documents in a chrome extension is broken, then their users start to complain about broken UI and give 1 star reviews and uninstall the extension or app.

Chrome extension developers prevent this issue by calling e.preventDefault() on zoom document level zoom events so the zoom level across all documents stays the same, but because this breaking change is shipped, all chrome extensions that relied on e.preventDefault() for preventing zoom events are now broken!

Because I work at a company that develops nothing but Chrome extensions I can tell you that all of our chrome extensions are broken because of this change, I'm not sure about how many chrome extensions currently shipped on chrome web store are affected by this change.

Also note that not only chrome extensions but many of the Google's own products such as Google AdWords, AdSens and other products that make use of Dart programming language and dart:html package and Angular Dart framework that call e.preventDefault() are all broken, because Dart at the moment does not support passive events, See this issue for more information:
dart-lang/sdk#26544

Above issue was opened on 26 May 2016 , but support for passive events is still not there as of 2019 this just shows it can take months, sometimes years to get these breaking changes to work well with the existing apps and extensions.

If you care so much about web developers going bankrupt because of slow web sites, then why not care about chrome extension developers going bankrupt because of messed up zoom levels.

Why there is no browser level API to change zoom levels so we don't have to use hacks like e.preventDefault();

I have to record tutorials on how to fix messed up zoom levels and show it to users that mail me that their UI is messed up.

But instead of fixing real issues we decide to create more non-issues like making events passive by default.

Node’s development direction favoured performance over usability and robustness, eventually backend developers got tired because of that and switched to better alternatives such as Golang.

I see chrome developers are also following a similar approach that favours raw performance over usability and robustness, and this discussing already shows how wrong that is :)

Never favour raw performance over usability and robustness.

In my opinion, robustness and usability is far more important than anything else, and because we are a small team we want our apps to be robust and at the end of the day we want to sleep well in the night rather than having to worry about some event handlers failing to do what they should be doing otherwise if this breaking change was not shipped.

[grorg]

Maybe I don't understand how this repository is supposed to work. Have Chrome/Blink + Firefox implemented this intervention? If so, why is this issue still open?

My specific question is whether WebKit should do it now, but my general question is how to know what the state of an intervention issue proposed here is.

[bzbarsky]

Firefox has not implemented this. It was discussed in https://bugzilla.mozilla.org/show_bug.cgi?id=1526725 back in February.

[sahel-sh]

...

Chrome extension developers prevent this issue by calling e.preventDefault() on zoom document level zoom events so the zoom level across all documents stays the same, but because this breaking change is shipped, all chrome extensions that relied on e.preventDefault() for preventing zoom events are now broken!
...
Above issue was opened on 26 May 2016 , but support for passive events is still not there as of 2019 this just shows it can take months, sometimes years to get these breaking changes to work well with the existing apps and extensions.

I am sorry that your extensions are negatively impacted by the intervention. However e.preventDefault() is not broken:
If a document level wheel event listener needs to call e.preventDefault() for wheel events to keep the zoom level the same, it should get declared as blocking using the {passive:false} option. Please check this developer's guide for more details:
https://developers.google.com/web/updates/2019/02/scrolling-intervention You can also file a bug using https://crbug.com/wizard and provide and example extension to get better guidance.

Please not that the intervention for touchmove and touchend has been shipped in chrome 56, and implemented by Edge, Firefox, and Safari layer on. This new issue (opened on Dec 2018) is for wheel events.