Skip to content
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

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

Open
sahel-sh opened this Issue Dec 5, 2018 · 9 comments

Comments

Projects
None yet
5 participants
@sahel-sh
Copy link

sahel-sh commented Dec 5, 2018

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), Safari1, and Firefox2.

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

This comment has been minimized.

Copy link

hober commented Dec 10, 2018

@sahel-sh

This comment has been minimized.

Copy link
Author

sahel-sh commented Jan 2, 2019

@sahel-sh

This comment has been minimized.

Copy link
Author

sahel-sh commented Jan 2, 2019

/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

This comment has been minimized.

Copy link

ChumpChief commented Jan 2, 2019

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

This comment has been minimized.

Copy link

staktrace commented Jan 2, 2019

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

@sahel-sh

This comment has been minimized.

Copy link
Author

sahel-sh commented Jan 4, 2019

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

This comment has been minimized.

Copy link

ChumpChief commented Jan 4, 2019

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

This comment has been minimized.

Copy link
Author

sahel-sh commented Jan 4, 2019

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

This comment has been minimized.

Copy link

pauljohnknight commented Mar 19, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.