Needs alternative WheelEvent.deltaMode, WheelEvent.delta(X|Y|Z)

[masayuki-nakano]

Currently, unit of WheelEvent.delta(X|Y|Z) value is defined by WheelEvent.deltaMode in UI Events. However, Chrome and Edge almost always fire wheel events with WheelEvent.DOM_DELTA_PIXEL. Therefore, a lot of web sites are broken on Gecko which is the only browser firing wheel events with native event's units.

So, for backward compatibility, WheelEvent.deltaMode should return always WheelEvent.DOM_DELTA_PIXEL, unfortunately. However, some better web application developers may want raw delta(X|Y|Z) values as far as possible.

Therefore, I'd like to propose that UI Events should declare that WheelEvent.delatMode always return WheelEvent.DOM_DELTA_PIXEL and WheelEvent.delta(X|Y|Z) are delta values in pixels. Additionally, there should be alternative attributes which are set raw event information. E.g., WheelEvent.rawDelta(Mode|X|Y|Z).

[masayuki-nakano]

Bug of Firefox is here: https://bugzilla.mozilla.org/show_bug.cgi?id=1392460

If it'd be possible, there should've been:

• WheelEvent.pixelDeltaX
• WheelEvent.pixelDeltaY
• WheelEvent.pixelDeltaZ
• WheelEvent.rawDeltaMode
• WheelEvent.rawDeltaX
• WheelEvent.rawDeltaY
• WheelEvent.rawDeltaZ
  However, we've met this issue with existing attributes, Wheel.delta*. We cannot rename them to pixelDelta*, unfortunately...

[masayuki-nakano]

@garykac Could you take a look? This is really annoying Spec issue. (Perhaps, some Chrome for Windows users have same issue as users of Firefox for Windows or Linux users since Chrome uses DOM_DELTA_PAGE if user sets per-page-scroll in the system settings.)

[garykac]

To summarize the proposal:

Because many web developers don't respect the deltaMode setting and simply assume that delta* always returns pixel values, we're proposing changing delta* to always return pixel values.

• Change definition of deltaMode to always return DOM_DELTA_PIXEL
• Change definition of delta(X|Y|Z) to always return pixels values
  • This will be a change for Firefox, but not for Chrome, Edge and Safari.
• Add rawDelta(X|Y|Z) and rawDeltaMode so that sites that want the non-pixel deltas, can explicitly request it.
  • The simplest implementation would be to duplicate the previous definition for deltaX and deltaMode. Although browsers may choose to return LINE or PAGE since PIXEL is already covered.

This change won't affect sites that properly check the deltaMode attribute, but it would break any site that assumes Firefox == DOM_PIXEL_LINE without actually checking deltaMode.

Sites that currently take advantage of Firefox's non-pixel deltas will no longer do so until they switch to use the new attributes on the event.

[masayuki-nakano]

FYI: As far as I've tested, deltaMode value of each browser:

• Windows (system setting is set to multiple line scroll)
  • Edge: DOM_DELTA_PIXEL
  • Chrome: DOM_DELTA_PIXEL
  • Firefox: DOM_DELTA_LINE
• Windows (system setting is set to per page scroll)
  • Edge: DOM_DELTA_PIXEL
  • Chrome: DOM_DELTA_PAGE
  • Firefox: DOM_DELTA_PAGE
• macOS (trackpad)
  • Safari: DOM_DELTA_PIXEL
  • Chrome: DOM_DELTA_PIXEL
  • Firefox: DOM_DELTA_PIXEL
• macOS (mouse)
  • Safari: DOM_DELTA_PIXEL
  • Chrome: DOM_DELTA_PIXEL
  • Firefox: DOM_DELTA_LINE
• Linux
  • Firefox: DOM_DELTA_LINE
  • Chrome: DOM_DELTA_PIXEL

[garykac]

@RByers @travisleithead Any thoughts on this proposal?

[RByers]

I've seen this difference between Chrome and Firefox cause real compat problems on real sites, so I support trying to fix it. I agree that delta is so often pixel that it's safer to require that it ALWAYS be pixel.

So the proposal seems reasonable to me, though I worry we might just have the same problem with rawDeltaMode. It seems to me having any property whose units vary based on another property is potentially problematic. Why not have linesDeltaX/Y and pageDeltaX/Y values (which could be undefined)? The Z axis almost certainly doesn't make sense for lines/pages, right? Does the X axis have a sensible and useful definition for lines?

Anyway @NavidZ is the Chrome expert here, so this is just my $0.02 - I don't have objections either way.

[wisniewskit]

Let's try to get some momentum going on this one again :)

@NavidZ, mind chiming in with your thoughts?

@masayuki-nakano, what do you think about the concern @RByers raised?

For what it's worth, I feel Rick has a good point and suggestion here. I feel that the default behavior should be consistent, as in my experience working on webcompat, web pages almost always presume pixel values and aren't even aware that there are other potential units. I feel that making the existing property a legacy (and pixel-only) value would be best, along with new properties that are specific to the units.

In fact I wonder if there is even a need to have "pages" and "lines" values at all (as well as a variable default unit)? I also wonder if they aren't a potential fingerprinting vector in some way?

[masayuki-nakano]

(Sorry, I didn't realize the mention here.)

Yes, sounds like that's great idea. I agree with it.

However, I have a concern about implementing it. For making it, each implementation should have computed value of lineDeltaX/Y and pageDeltaX/Y or line height or page height/width for computing them later since events may be stored with variables and may be referred later (i.e., after ending the propagation).

I don't mind the cost as a developer of Mozilla DOM Events, but I'm not sure how other browser developers.

And in my understanding, the line height, page width and page height values are used the value at dispatching wheel event rather than the attributes are accessed. So, I hope that UI Events should define:

1. When these reference values are fixed.
2. Which element's size should be referred (Event.target? Nearest ancestor scrollable Element? Root element?).

[CWies]

@masayuki-nakano could you add the unit in which the values(deltaX/Y/Z) are actually returned to your list above? I found that, on Windows, when set to multiple line scroll, the actual unit is always lines, and when set to pages it is always pages. Though I have neither a macOS nor a Linux device. Are they always returned in lines? I am especially wondering about macOS with trackpad, since firefox also uses pixels there.

[masayuki-nakano]

@CWies Isn't you asking about what I commented in #181 (comment) ?

[CWies]

@masayuki-nakano As I understand, thats what deltaMode returns in each browser. Though I need to know in which unit deltaX/Y/Z are actually returned, because in my testing, both edge and chrome, while returning DOM_DELTA_PIXEL for deltaMode, only give values of 1 for deltaX/Y/Z every time i turn the scrollwheel to the next step, which is actually 1 Line and not 1 Pixel(as far as i understand)

[masayuki-nakano]

I need to know in which unit deltaX/Y/Z are actually returned

The value can be checked with deletaMode as you know.

because in my testing, both edge and chrome, while returning DOM_DELTA_PIXEL for deltaMode, only give values of 1 for deltaX/Y/Z every time i turn the scrollwheel to the next step, which is actually 1 Line and not 1 Pixel

Don't you see a lot of wheel events in such case? If so, the device tries to scroll smoothly with splitting one action to multiple wheel events.

[CWies]

Don't you see a lot of wheel events in such case?

No... both on edge and chrome not

The value can be checked with deletaMode as you know.

Why the whole discussion then? Shouldnt something like
if (mode == 0) multiplier = 1; else if (mode == 1) multiplier = Number( window .getComputedStyle(document.body) .getPropertyValue("font-size") .match(/\d+/)[0] ); else if (mode == 2) multiplier = window.innerHeight; else multiplier = 0;
solve any problems? I mean it shouldnt matter in what unit they are returned, as long as you know the unit...

[masayuki-nakano]

@CWies because we got some web-compat issues which some web apps don't check deltaMode even though they refer delta(X|Y).