Closed RByers closed 2 years ago
@dtapuska can you update the status of this in Chrome?
AsyncWheelEvents is available as a flag in Chrome. We are working at running a finch trial this quarter to resolve any issues we encounter with touchpad latching. It has taken longer than we anticipated.
(As noted in https://github.com/WICG/interventions/pull/72, we intend to archive this repository and are thus triaging and resolving all open issues)
From a standards perspective, this seems to be covered by https://w3c.github.io/uievents/#cancelability-of-wheel-events. I'm not sure if that is the same thing as "latching" and I would suggest following up in UI Events if there are aspects of this issue that are not yet resolved.
non-passive
wheel
listeners are a problem for scroll performance. The problem forwheel
is worse in some ways that fortouchstart/touchmove
because with touch at least it's just the beginning of the scroll that's blocked, not every single update. Most browsers already have some notion of a wheel sequence (group of wheel events that together "latch" to a single element, eg. based on when the users fingers actually lift from a touchpad). We could probably bring the "blocks only scroll start" property of touch events towheel
by saying thatwheel
events are uncancelable during a scroll (i.e. the site must cancel the first one if it wants to cancel any in a given sequence).Off the top of my head here's the behavior of the various major browsers related to this:
-ms-scroll-chaining: none
. Doesn't sendwheel
events at all for high-precision touchpads.Some day we might want to go further and try to address the first event problem (as we've done for touch in #18), but that's harder and much lower impact than this first step here.
/cc @tdresser @dtapuska who are thinking about this in blink.