Only the first wheel event in a sequence should be cancelable

[RByers]

non-passive wheel listeners are a problem for scroll performance. The problem for wheel is worse in some ways that for touchstart/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 to wheel by saying that wheel 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:

• Safari: Does latching (at least for touchpad) - so that there is a defined sequence of wheel events
• Chrome: Is close to shipping latching.
• Firefox: Latches, including generating "wheel transactions" based on a timer for mouse wheels which don't themselves have defined start/end. Also makes wheel events other than the first asynchronous so that cancelation is delayed (doesn't impact the scroll caused by that wheel event, only some future one).
• Edge: Doesn't latch by default, but can be enabled with -ms-scroll-chaining: none. Doesn't send wheel 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.

[ojanvafai]

@dtapuska can you update the status of this in Chrome?

[dtapuska]

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.

[johannhof]

(As noted in #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.