Wheel event groups are not defined

[dlrobertson]

Both WebKit and Blink will group wheel events with a target, and I'm not sure if this is defined in event-type-wheel. Given the tests in web-platform-tests/wpt#37445:

Test	Blink	WebKit	Gecko
Wheel events are grouped and are not sent to a child element	✅	✅	❌
Wheel events are not bound to a scroll frame	✅	✅	✅
Wheel event groups beyond the origin bound have the same target	✅	❌	❌

Note: The failure in WebKit is due to an exception in the webdriver. When I manually run the steps, I get the expected behavior from the test.

Please let me know if any more information would be helpful. I'm working on fixing this in Gecko (bug 1168182), so any feedback would be very much welcomed (esp. feedback on the tests in web-platform-tests/wpt#37445).

[dlrobertson]

User Impact

Consider the case where a site has a large map like this site. The large map is a large element that has a wheel event listener that will preventDefault. Without wheel event groups (e.g. Firefox Release or Firefox Beta) a pan gesture or wheel scroll that starts immediately above the large map element will halt and cause the map to start zooming out as soon as the mouse is within the map element's bounds. This can cause sites that use preventDefault on wheel events like this to be somewhere between annoying to use to completely unusable if the element is large enough.

Suggested Change

Blink and WebKit already group wheel events that occur within a given time without another user action like a mousemove, and I'm in the progress of getting this added to Gecko. It would be nice to document this in the event-type-wheel section. Similar to this section that describes the behavior of "some user agents" in a non-normative manner. It might be helpful to start with something non-normative event though this is already the case in Blink, Webkit, and (hopefully soon) Gecko.

Note: I'm largely interested in some sort of change like this to ensure that I'm not going rogue with the changes I'm making to Gecko 😄.

[zcorpan]

I think it shouldn't be non-normative, if browser engines agree on a behavior and it's sensible (in this case seems like better UX), it seems better to require that behavior in the spec.

[dlrobertson]

I think it shouldn't be non-normative, if browser engines agree on a behavior and it's sensible (in this case seems like better UX), it seems better to require that behavior in the spec.

👍 makes sense

[dlrobertson]

@garykac do you have thoughts or questions about this issue or #344? I also did my best to describe the issue here... Any feedback or critiques would be very much welcomed