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
See Also: → https://webcompat.com/issues/8012
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.
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.
I discovered the referenced Webcompat issue using the described macOS with trackpad configuration.
(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.
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).
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.
(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.
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?
Yeah, I think we'll just need to change our behavior, even though the current behavior makes more sense.
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.
(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.
(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.
I have a question, how many reports which are caused by this difference?
There was another instances of this just now in https://webcompat.com/issues/15071
See Also: → https://webcompat.com/issues/15071
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.
You need to log in before you can comment on or make changes to this bug.