Expose wheel event scrolling state to DOM events

[sahel-sh]

Scrolling on trackpads can give additional information about the state of scrolling that determines the first wheel event of a scrolling sequence (from the time that user starts scrolling till when they lift their fingers). This information helps with optimizations like async wheel events which lets preventDefault call only on the first wheel event of a scroll sequence to cancel the event and the rest of the wheel events in the sequence are non-cancellable.

It should be mentioned in the spec that not all wheel events are cancelable similar to what is mentioned for touchmove events.

[dtapuska]

These events are already detected as cancelable inside Event.idl

[RByers]

Here's my recollection of the state in various browsers:

• In Chrome wheel events (for which there's a non-passive listener) are always cancelable and synchronous, a big problem for scroll performance. Your change proposes making only the first wheel in a touchpad gesture cancelable, so the rest can be async.
• Edge doesn't fire wheel events at all for touchpads due to this perf issue. I talked with @toddreifsteck and @scottlow at TPAC. At the moment they're looking to send touchscreen pointer events for touchpad scrolling, but admitted it wouldn't fix all the web compat problems with their lack of wheel support and so sounded intrigued by this proposal.
• Firefox makes latter wheel events async to avoid this problem, but they're still cancelable with some complex after-the-fact interruption behavior (@staktrace). It's not clear to me there are use cases which really justify this strange "after-the-fact interruption" behavior.
• Safari - if the first wheel event isn't canceled, no subsequent wheel events are sent at all (@smfr). This addresses the perf issue in the same way but makes it harder for the page (eg. an activity logging library, or something trying to move along with the scroll) to see what's happening on the touchpad (have to find the right element to follow scroll events on). This is cheaper in theory than sending async wheel events as proposed here, but I doubt it makes much difference in practice.

@sahel-sh does this seem correct? Do you have test cases you've been using to share?

[staktrace]

Firefox makes latter wheel events async to avoid this problem, but they're still cancelable with some complex after-the-fact interruption behavior (@staktrace). It's not clear to me there are use cases which really justify this strange "after-the-fact interruption" behavior.

Yeah, the behaviour is basically, "if content does preventDefault on a wheel event later in the transaction, then try to stop the scrolling ASAP and start a new transaction". It can result in non-deterministic behaviour, and we didn't really have specific use cases that drove this behaviour, it was more so just trying to get as much async scrolling as we could while still leaving an escape hatch for content to stop it in some theoretical cases. It may be that we don't need this complexity and can just treat those wheel events as non-cancelable.

[dtapuska]

I'd much prefer if we detailed what we thought was necessary for wheel events and add a new pointerType == "touchpad" for PointerEvents with all the properties needed.

Since these phased wheel events generally come from touchpads I think it really is necessary to define the other things that are useful like the raw pointer co-ordinates.

[sahel-sh]

Microsoft edge 42.17035.1000.0 sends wheel events while scrolling with touchpad but it doesn't support async wheel events. A minor change in Safari's case: Only in case of scrolling on the mainframe the rest of the wheel events are skipped and otherwise they are all sent. While scrolling on a div it sends all wheel events and doesn't support async wheel events.

I used a simple scrollable div and added a blocking wheel event listener with a busy loop of 200ms inside.

[sahel-sh]

Edge version 42.17035.1000.0 fires wheel events for touchpad scrolling, while version 40.15063.674.0 doesn't fire wheel events as Rick mentioned.

[bokand]

Since these phased wheel events generally come from touchpads I think it really is necessary to define the other things that are useful like the raw pointer co-ordinates.

I like this, but would the behavior be the same as what we're doing for wheels? i.e. send first PointerEvent that's cancellable - if it's not preventDefaulted the rest are async? Would we still need to send a wheel event for compat?

[RByers]

Would we still need to send a wheel event for compat?

I do think wheel events are required for compat. Eg. Google sheets is basically unusable on Edge with a precision touchpad (except in the apparently unpredictable cases where Edge decides to send wheel events) because you can't scroll with wheel (they draw their UI manually into a canvas, can't rely on browser scrolling).