1529953 - Consider supporting the legacy mousewheel event for interop.

Status: NEW

(Core :: DOM: Events, enhancement, P3)

Description

[Thomas Wisniewski [:twisniewski]]

It seems that sites which play around with the (complicated) legacy mouse-wheel event system can be easily burned. For instance, typescriptlang.org's playground wants to override scrollbar behaviour by preventing the default mouse wheel events, but because it settles on DOMMouseScroll as the event type to prevent in Firefox, the events aren't actually prevented (MozMousePixelScroll would have to be prevented, if the site is only dealing with legacy events).

While the standard wheel event exists now to help with the situation, I feel it's worth supporting the "dominant" legacy event mousewheel as well if sites like typescriptlang.org are affected in ways that are subtle enough to not easily discover (or deemed worth to fix). According to MDN the mousewheel event seems to be supported by Blink, WebKit, Edge and Explorer, so it's pretty much entrenched.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

See wheelDelta value of Chrome. Even if we follow Chrome's spec, the behavior does not make sense (although I don't check the latest behavior of Chrome).

Currently, I'm investigating what we can do for bug 1406243. One possible idea is, start to dispatch DOMMouseScroll with 0 for detail even in the cases we dispatch only MozMousePixelScroll. But if there are web apps which do like the following, it breaks the web apps anyway:

foo.addEventListener("DOMMouseScroll", (event) => {
  if (event.detail > 0) {
    // Do something for scroll to bottom event.
    return;
  }
  // Do something for scroll to up event.
});

So, 0 may be handled as scroll down or up.

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Another possible idea is, we stop handling wheel events whose delta value is less than 1 line only when there is DOMMouseScroll non-passive listener, but no wheel nor MozMousePixelScroll. However, in this case, scroll will be started when user scrolls over one line. So, the UX becomes worse.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

And if web apps call addEventListener() with both DOMMouseScroll and mousewheel (i.e., without UA check), both event listeners run only on Firefox. E.g., if both listeners are same function, Firefox users see x2 faster scroll for each wheel operation.

Comment 4

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 5

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 6

[Adam Stevenson [:adamopenweb]]

Going to remove https://webcompat.com/issues/57716 from see also, since it was fixed so quickly by the site.
Also https://webcompat.com/issues/23101 was fixed by the site.

The Google search issue (bug #1507150) is the last remaining one that we know of. I pinged our Google contacts to see if they can resolve.

Comment 7

[Kagami Rosylight [:saschanaz] (they/them)]

Hi Emilio, you added .wheelData* on bug 1708829, do you want to try this one too?

Comment 8

[Emilio Cobos Álvarez (:emilio)]

I'm not sure what it'd entail, would it be reasonable enough to alias to wheel?

Comment 9

[Kagami Rosylight [:saschanaz] (they/them)]

I believe yes unless wheelData behaves differently on each event or there's some weird bubbling issue, but probably should double check.

Comment 10

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Removing https://webcompat.com/issues/64112 from see-also as it's fixed.

Comment 11

[Simon Pieters [:zcorpan]]

Spec issue for mousewheel event: https://github.com/w3c/uievents/issues/331

Comment 13

[Calin Tanase (OOO until 22nd of Nov)]

Seems fixed based on the linked wecompat issues:

• https://github.com/webcompat/web-bugs/issues/62877
• https://github.com/webcompat/web-bugs/issues/67972

Environment:
Operating system: Windows 10
Browsers tested: Firefox Nightly 128.0a1 (2024-05-28) / Firefox Release 126 / Chrome 125.0.6422.113

Comment 14

[Simon Pieters [:zcorpan]]

Based on this demo the mousewheel event is still not supported. https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=10430

Comment 15

[Simon Pieters [:zcorpan]]

Tests:

• https://wpt.fyi/results/dom/events/passive-by-default.html
• https://wpt.fyi/results/dom/events/non-cancelable-when-passive
• https://wpt.fyi/results/html/browsers/the-window-object/security-window/window-security.https.html
• https://wpt.fyi/results/html/browsers/the-window-object/window-properties.https.html

There aren't tests (or spec) yet for the logic to decide whether to fire mousewheel based on presence of a wheel event listener: https://github.com/w3c/uievents/issues/331#issuecomment-1171005798