1392460 - deltaMode default should be DOM_DELTA_PIXEL

Status: RESOLVED FIXED

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

Description

[Karl Dubost💡 :karlcow]

This is a spin-off of https://webcompat.com/issues/8012

The site  https://privacy.google.com/ assumed that deltaMode is in pixel. It is breaking the scrolling on their site in Firefox.



Reading https://w3c.github.io/uievents/#dom-wheelevent-deltamode

>  The deltaMode attribute contains an indication of the units of measurement for the delta values. The default value is DOM_DELTA_PIXEL (pixels). 


We are not sure yet if it's also the cause of Bug 1390580

Comment 1

[:Atoll]

https://bugs.chromium.org/p/chromium/issues/detail?id=227454 highlights include "Hello, I'm the implementer of D3E WheelEvent on Gecko" so there is a lot more research opportunity there for someone more versed in this space.

Comment 2

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

I've already heard this dissatisfaction but I still don't think that it's a good thing to discard our lossless wheel events and make it lossy events. Note that on any platforms, we receive native wheel events with amount of scroll lines, scroll pages or abstract value. Only the exceptions is, macOS with Trackpad or mice supporting high resolution scroll.

Even if we'll convert the native scroll amount to pixels, there could be other compatibility issue with the other browsers because I cannot believe that they use exactly same computation for that.

Comment 3

[:Atoll]

I discovered the referenced Webcompat issue using the described macOS with trackpad configuration.

Comment 4

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

(In reply to Richard Soderberg  [:atoll] from comment #3)
> I discovered the referenced Webcompat issue using the described macOS with
> trackpad configuration.

Then, the issue isn't caused by delatMode difference. As far as I know, Trackpad on macOS never cause line scroll.

Comment 5

[:Atoll]

Hmm. (checks something.)  It also occurs with the trackpad fully powered off and a wired USB mouse plugged in (causing all the scrollbars to affix themselves to the right permanently).

Comment 6

[Rick Byers]

It looks like Edge, Safari and Chrome all use DOM_DELTA_PIXEL on major OSes in their default configuration.  I believe Firefox will have much greater compat problems by being the only one to use DOM_DELTA_LINE than by risking having a different calculation between ticks and pixels (users can change their scroll speed anyway so sites can't assume any particular pixel/per/tick behavior).  Note that spec also says under DOM_DELTA_PIXEL "This is the most typical case in most operating system and implementation configurations."

I verified that Chrome will switch to DOM_DELTA_PAGE on Windows when the OS mouse settings are changed to scroll by page.
  But Edge appears not to - using DOM_DELTA_PIXEL with large values instead.  That seems like an Edge bug to me since there's no fixed mapping from pages to pixels.

I can see a similar argument for why we should be using DOM_DELTA_LINE by default, but my gut instinct is that it's not worth it in practice.  Having line-height-dependent scrolling doesn't seem too valuable, and by far most uses I've seen of wheel listeners really just want to reason in pixels, preserving whatever the OS/browser default mapping is.  Eg. if I build an app like Google sheets which scrolls a canvas manually, I really want it to move the exact number of pixels the browser would have scrolled a normal page by. Users expect a consistency scroll velocity in terms of pixels.  Plus I believe the majority of scrolling these days occurs on touchpads which will always be DOM_DELTA_PIXEL - I'd prefer that old-style clicky mousewheels and touchpads were exposed to the web in the same way by default to avoid developers having to reason about them differently in the common case.

If we really want to preserve the "lossless" property then I'd suggest the right way would be to add lineDeltaX/lineDeltaY members to WheelEvent.

Comment 7

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

(In reply to Rick Byers from comment #6)
> If we really want to preserve the "lossless" property then I'd suggest the
> right way would be to add lineDeltaX/lineDeltaY members to WheelEvent.

Yes, should be discussed in UI Events WG if we really need to change it. (I don't think we should do it since Chromium also uses DOM_DELTA_PAGE as your comment.) Perhaps, adding pixelDelta(X|Y|Z) is smarter and won't break any web apps which supports every delta mode correctly.

Comment 8

[Rick Byers]

Right, I'm definitely happy to have these discussions in the context of UI Events.

But I think the key discussion to have here is that the spec encourages DOM_DELTA_PIXEL to be the common case, all other browsers do that except Firefox and Firefox sees a greater level of web compat problems as a result.  So should Firefox change to match the other browsers in this regard?

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

Yeah, I think we'll just need to change our behavior, even though the current behavior makes more sense.

Comment 10

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

I wonder, how about this approach? If WheelEvent.delta(X|Y|Z) is accessed before WheelEvent.deltaMode, we return computed pixel delta values and return DOM_DELTE_PIXEL from deltaMode, otherwise, i.e., content script accesses deltaMode first, returns current (raw) value.

This could keep some web apps being broken if web apps access only delta(X|Y|Z) but script of external services like UX analyzer accessed deltaMode first, though, but in most cases, this must be the best approach for both types of web apps.

Comment 11

[Masatoshi Kimura [:emk]]

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #10)
> I wonder, how about this approach? If WheelEvent.delta(X|Y|Z) is accessed
> before WheelEvent.deltaMode, we return computed pixel delta values and
> return DOM_DELTE_PIXEL from deltaMode, otherwise, i.e., content script
> accesses deltaMode first, returns current (raw) value.
> 
> This could keep some web apps being broken if web apps access only
> delta(X|Y|Z) but script of external services like UX analyzer accessed
> deltaMode first, though, but in most cases, this must be the best approach
> for both types of web apps.

If script A touches deltaMode first and script B touches delta(X|Y|Z) first, does the behavior of script B depend on the script loading order?  If scripts are loaded asynchronously, the behavior will intermittently change.  It will be a bug-triage nightmare.  If a web page fails intermittently only with Firefox, I bet the web page author will not bother to find out the reason only for Firefox.

WebExtensions content scripts will also affect the behavior (again, intermittently). As an aside, I suggest you not use the term "content script" for page scripts because it is confusing with WebExtensions content scripts.

IMO a deterministic behavior would be better even if it is less than optimal.

Comment 12

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

(In reply to Masatoshi Kimura [:emk] from comment #11)
> If script A touches deltaMode first and script B touches delta(X|Y|Z) first,
> does the behavior of script B depend on the script loading order?  If
> scripts are loaded asynchronously, the behavior will intermittently change. 
> It will be a bug-triage nightmare.

Indeed. We should avoid such hell.

However, I don't like to change existing web apps which handle delta(X|Y|Z) with deltaMode correctly. I'd be great if we could reset the state whether deltaMode was checked when delte(X|Y|Z) was accessed from different event handler, though.

Comment 13

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

I have a question, how many reports which are caused by this difference?

Comment 14

[Thomas Wisniewski]

There was another instances of this just now in https://webcompat.com/issues/15071

Comment 15

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

Filed spec issue: https://github.com/w3c/uievents/issues/181

I strongly believe that if we fix WheelEvent.deltaMode to WheelEvent.DOM_DELTA_PIXEL, we and standard spec should define alternative attributes which current developers can retrieve from Firefox's WheelEvent.

Comment 17

[Firefox Bug Husbandry Bot]

See bug 1547409. Moving webcompat whiteboard tags to project flags.

Comment 18

[Mike Taylor [:miketaylr]]

(removing URL, because Google has fixed privacy.google.com (and it now redirects to https://safety.google/privacy/ -- no more mouse scroll issues)

Comment 21

[Bas Schouten (:bas.schouten)]

There's decent evidence this is affecting a significant amount of websites. Marking this qf:p1 for now.

Comment 22

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

I wonder, a lot of web developers do not know WheelEvent.deltaMode. From point of the other side view, there might be multiplying our delta values if and only if running on Firefox. If so, changing default deltaMode value would break some web apps which do not have any trouble on Firefox...

Blacklist might be useful like keypress events?

Comment 23

[Mike Taylor [:miketaylr]]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #22)

Blacklist might be useful like keypress events?

I think so, yeah. There's bound to be weird breakage we won't know about (until someone complains).

Comment 24

[:Atoll]

Is it possible to collect telemetry on pages that read WheelEvent.deltaY without either having read WheelEvent.deltaMode already or reading deltaMode within the next clock second or so?

Comment 25

[Karl Dubost💡 :karlcow]

example:

https://github.com/AurelienBallier/dart-sdk/blob/66931ab8372ef61e3ea421f094764d158f0a0669/dart/tools/dom/templates/html/impl/impl_WheelEvent.darttemplate#L124-L139

https://github.com/voidrayco/webgl/blob/7e433100d8bf06e540d2fff6526e98d8391881c4/src/webgl-surface/util/mouse.ts#L5-L11

https://github.com/marian-m12l/studio/blob/3b62d31da7fc5a23a68054ef3e21078cf46dd149/web-ui/javascript/src/components/diagram/actions/FixedZoomCanvasAction.js#L28-L54

https://github.com/erasme/erajs/blob/29f7231fa70ae91fa4beb8f2129250feaeecf595/era/ui/wheelevent.js#L74-L79

etc.

found with https://github.com/search?p=5&q=WheelEvent+firefox+deltay&type=Code

I didn't check if they had an impact.

Comment 26

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

Obviously, the last one will be broken (and also already broken on some environments).

Comment 27

[Karl Dubost💡 :karlcow]

Masayuki,

1. Is it possible to have a telemetry probe to detect how many times Websites are using wheelEvent.delta(X|Y|Z) without reading wheelEvent.deltaMode (Probably quite hard or at least difficult to clearly assess).
2. Do you think we could release Firefox Nightly with the wheelEvent.deltaMode = 0 by default with a preference we could set on/off. Not necessary for a long time, but to study if we detect massive webcompat issues here and there after this move?

The item 2 would give us a better picture of the reality?

• Proposal for new values
• Current state of implementations

Comment 28

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

(In reply to Karl Dubost💡 :karlcow from comment #27)

Masayuki,

1. Is it possible to have a telemetry probe to detect how many times Websites are using wheelEvent.delta(X|Y|Z) without reading wheelEvent.deltaMode (Probably quite hard or at least difficult to clearly assess).

If we ignore origin of the referrer of the attributes (i.e., the case referred by 3rd party's iframe document, etc), we can do it. In that case, we can know number and/or percentage of web sites which completely ignore deltaMode.

2. Do you think we could release Firefox Nightly with the wheelEvent.deltaMode = 0 by default with a preference we could set on/off. Not necessary for a long time, but to study if we detect massive webcompat issues here and there after this move?

Technically, of course, it's possible. But I worry about:

• some Nightly users stop using latest builds
• they don't report that

And I don't have much time until I ship beforeinput event.

Finally, I'm not sure the policy about this kind of risky examination.

The item 2 would give us a better picture of the reality?

• Proposal for new values
• Current state of implementations

I hope so if it's allowed.

Comment 30

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1392460 - Add a couple prefs to expose DOM_DELTA_PIXEL rather than DOM_DELTA_LINES to the web. r=masayuki,smaug

And use them to disable DOM_DELTA_LINES on Nightly builds, to see the
impact, since this is pretty hard to measure just with telemetry.

Comment 31

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/021dcc5231fb
Add a couple prefs to expose DOM_DELTA_PIXEL rather than DOM_DELTA_LINES to the web. r=masayuki,smaug

Comment 32

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/021dcc5231fb

Comment 33

[jasonthomasgray]

I'm trying to understand the fix that was implemented for this bug (or if a later fix has changed this).
From my testing it looks like delta values will be in DOM_DELTA_PIXEL unless the value of deltaMode is checked in which case it switches to DOM_DELTA_LINES.

This seems rather inconvenient in my situation. I would like the pixel values but if I check that I'm getting pixel values then I will end up with line values, which I will then have to somehow convert back to pixels...

Comment 34

[Emilio Cobos Álvarez (:emilio)]

It returns pixels unless deltaMode is checked before getting the delta. If you prefer pixels, you can get the delta before checking deltaMode (and deltaMode would return pixels with the fix for this bug).

Comment 35

[Ziad [:ziadkh]]

Hello everyone and happy new year,

This is my first time commenting in bugzilla, so apologies if this is not the right place it, feel free to remove it if deemed inappropriate.

First of all I would like to thank the people working on this to improve web compatibility and the web standards.
But this undocumented behavior has cost me (and probably others) a day of frustration and I'll explain why:

0. 1. I was trying to implement scroll based interactions in a web app that don't concern actual scrolling content (like zooming on a map and changing a value of a field, eg. the numeric input field)
   2. I was checking the deltaMode but not before accessing deltaY (because I didn't know of this change)

1. First thing I noticed was that deltaMode was always DOM_DELTA_PIXEL even-though I remembered getting DOM_DELTA_LINE before.

2. delta* varied with the font-size of the event.target for imprecise devices (like a mouse) in Firefox but not in the others.

3. So I tried to undo that variation to get a constant delta* like what I get in other browsers. (This took a lot of trail and error)

4. Then I found out that for precise devices (like a trackpad) everything works the as expected in Safari, Chrome and Firefox 🌈, but the problem is that there's no way to distinguish between precise and imprecise which rendered my work in 3. useless.

5. Finally I came to bugzilla to report my findings, and the "Find similar issues" thing pointed me this thread and I finally understood.

So to save others from going though this again I opened an issue mdn/content#11811 to update the documentation on MDN.

I just hope that the next time a breaking change is released, the documentation (eg. MDN) is updated.
I mean no offense to anyone, I just wish the web platform wasn't filled with booby-traps like this one.

Thanks again for your work on improving web compatibility and specs.

PS: I've omitted the steps where I searched the web for information about the subject but came out empty before finding this thread.

Comment 36

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

(In reply to ziad.khoury.h from comment #35)

I just hope that the next time a breaking change is released, the documentation (eg. MDN) is updated.
I mean no offense to anyone, I just wish the web platform wasn't filled with booby-traps like this one.

Sorry for wasting your time with the hacky fix. I apologize that we forgot to add dev-doc-needed keyword here to update MDN. We just announced this change in the "Intent to ship" post.