1380217 - Implement non-standard WheelEvent.wheelDelta properties

Status: RESOLVED DUPLICATE of bug 1708829

(Core :: DOM: Core & HTML, enhancement, P3)

Description

[poiru]

On Windows, WheelEvent.deltaY is scaled by the system SPI_GETWHEELSCROLLLINES setting. This makes it impossible to accurately detect how much the scroll wheel has actually turned. This makes life difficult for web apps that have no concept of pages or lines (e.g. <canvas>-based drawing tools like figma.com).

In Chrome, the non-standard WheelEvent.wheelDeltaY is similar to deltaY except that it is not scaled by SPI_GETWHEELSCROLLLINES.

For web compatibility, we should match Chrome's implementation. See: https://developer.mozilla.org/en-US/docs/Web/Events/mousewheel#wheelDelta_wheelDeltaX_and_wheelDeltaY_value

Markus, what do you think?

Comment 1

[Alecazam]

Just make sure that you don't replicate where Chrome multiples both delta and wheelDelta by the browserZoom (devicePixelRatio).  That's incorrect.  Also make sure to include both wheelDeltaX and wheelDeltaY, and note that wheelDeltaXY = -deltaXY.  We mostly need this on Windows where the numLinesToScrollXY and browser-specific wheel -> delta conversions throw off any attempts to normalize the values.   Also carefully deal with physical wheel vs. touchpad-simulated wheel and pinch.

Comment 2

[Markus Stange [:mstange]]

Sorry for the delay here, I still haven't had the chance to give this the proper amount of thought.
I'm mostly worried about compatibility with existing websites and their fallback code.

Maybe Masayuki can weigh in in the meantime.

Comment 3

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

(In reply to Birunthan Mohanathas [:poiru] from comment #0)
> On Windows, WheelEvent.deltaY is scaled by the system
> SPI_GETWHEELSCROLLLINES setting. This makes it impossible to accurately
> detect how much the scroll wheel has actually turned.

This is even if the deltaMode is DOM_DELTA_PIXEL too. The amount of physical device operation may be mapped to how many pixels differently between environments.

> This makes life
> difficult for web apps that have no concept of pages or lines (e.g.
> <canvas>-based drawing tools like figma.com).

Used for what? If scrolling <canvas> contents, it assumes proper line-height for converting line scroll amount to pixel scroll amount. Page scroll is really simpler, it can covert to pixels with its page height.

> In Chrome, the non-standard WheelEvent.wheelDeltaY is similar to deltaY
> except that it is not scaled by SPI_GETWHEELSCROLLLINES.

Yes, but the attribute's meaning is really different between browsers. So, we shouldn't implement it with specific browser's behavior.

> For web compatibility, we should match Chrome's implementation. See:
> https://developer.mozilla.org/en-US/docs/Web/Events/
> mousewheel#wheelDelta_wheelDeltaX_and_wheelDeltaY_value

I don't think so. See also spec bug: https://github.com/w3c/uievents/issues/138

I think that this should be INVA until browser vendors gets some consent around this issue.

# Although, I believe that standard spec should just add new attribute rather than making new compatibility issue for non-standard attribute.

Comment 4

[Markus Stange [:mstange]]

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #3)
> I don't think so. See also spec bug:
> https://github.com/w3c/uievents/issues/138
> 
> I think that this should be INVA until browser vendors gets some consent
> around this issue.
> 
> # Although, I believe that standard spec should just add new attribute
> rather than making new compatibility issue for non-standard attribute.

How can interested parties help move this along? Would writing up a proposal help?

Comment 5

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

FYI: If we support wheelDelta(X|Y), it will break feature detection of existing web pages. So, it's risky even if wheelDelta(X|Y) behavior is consistent between browsers.

On the other hand, how should we set on macOS? NSEvent doesn't have physical operation amount. So, we cannot set "raw" value.
https://developer.apple.com/documentation/appkit/nsevent

Such platform limitation may cause some inconvenient to end-users. If a web-app is tested only on Windows, macOS users may see too fast scroll or too slow scroll and vice versa.

Comment 6

[Karl Dubost💡 :karlcow]

In the case of https://webcompat.com/issues/21643

The code is

```js
        $('.stopOverScroll').on('mousewheel DOMMouseScroll', function (n) {
          var t = n.originalEvent,
          i = t.wheelDelta || - t.detail;
          this.scrollTop += (i < 0 ? 1 : - 1) * 30;
          n.preventDefault()
        });

```

https://www.realtor.ca/bundles/desktop?v=masr2XEChWFSbZJcKtJRKFkPYoxW1OiCulrl6AXoyw01&ver=1.0.6879.30667&k=1

Comment 7

[Mike Taylor [:miketaylr]]

It would be interesting to search HTTPArchive via BigQuery to understand more how sites are using this. Currently Chrome's use counters show it at ~0.44%, which is too high for them to remove. But we don't seem to have a lot of broken sites without it (at least, reported sites).

edit: here's a run that gives sites and URLs to scripts using wheelDelta for investigation: https://docs.google.com/spreadsheets/d/1tkwuxHvVj9qKQOhWWywS_fqZvdMaV7XkTvcyT7KEOWM/edit#gid=289863620

Comment 8

[Firefox Bug Husbandry Bot]

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

Comment 9

[Firefox Bug Husbandry Bot]

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

Comment 10

[Adam Stevenson [:adamopenweb]]

Removing https://webcompat.com/issues/21643 from the see also, since it is fixed by the site now. Chrome counters show 0.41% now, which is slightly lower but not much. The spreadsheet in comment #7 from ~2 years ago lists half of the entries as old jquery files.

I think we should leave this as P3 and revisit, we haven't seen reports of more breakage in ~2 years.