Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add WheelEvent#wheelDelta/wheelDeltaX/wheelDeltaY #138

Open
foolip opened this issue Mar 9, 2017 · 13 comments
Open

Add WheelEvent#wheelDelta/wheelDeltaX/wheelDeltaY #138

foolip opened this issue Mar 9, 2017 · 13 comments

Comments

@foolip
Copy link
Member

foolip commented Mar 9, 2017

These three attributes exist in Chromium, EdgeHTML and WebKit, but not in the spec:
https://w3c.github.io/uievents/#interface-wheelevent

@foolip
Copy link
Member Author

foolip commented Mar 9, 2017

@garykac

@foolip
Copy link
Member Author

foolip commented Mar 9, 2017

Usage is high enough that removing wouldn't be straightforward:
https://www.chromestatus.com/metrics/feature/timeline/popularity/491
https://www.chromestatus.com/metrics/feature/timeline/popularity/492
https://www.chromestatus.com/metrics/feature/timeline/popularity/493

These numbers may be inflated by event copying patterns (enumeration) though. Still, support in three engines is by itself a strong signal to standardize.

@masayuki-nakano
Copy link

I don't think that they can be standardized. See following document, these attribute values are really different between browsers:
https://developer.mozilla.org/en-US/docs/Web/Events/mousewheel#wheelDelta_wheelDeltaX_and_wheelDeltaY_value

That's the reason why Gecko doesn't support them.

@foolip
Copy link
Member Author

foolip commented Mar 9, 2017

Does content depend on these attributes behaving differently in Chrome, Edge and Safari, and do they actually? If those three are well enough aligned, are there additional compat constraints that Gecko would run into if trying to add them?

As a last resort, it's possible to do something like the navigator compatibility mode, but hopefully that shouldn't be necessary.

@masayuki-nakano
Copy link

Does content depend on these attributes behaving differently in Chrome, Edge and Safari, and do they actually?

I don't know, but in my experience, most web apps which handle wheel event directly have bugs with various situations. For example, not supporting high resolution scroll, not supporting page scroll.

If those three are well enough aligned, are there additional compat constraints that Gecko would run into if trying to add them?

It's difficult to say now. The attributes are designed before high resolution scroll, so, I'm not sure if these values can make sense even with modern devices.

The meaning of these attributes are really different in physical or logical level:

IE (I don't know about Edge's behavior), Chrome for Windows, Chrome for Linux, Chrome for macOS with non-continuous wheel device indicate physical amount of turned distance.

On the other hand, Chrome for macOS with continuous wheel device and Safari indicate computed scroll amount which is computed with acceleration, etc.

@foolip
Copy link
Member Author

foolip commented Mar 9, 2017

OK, sounds like we have a bit of a mess. @garykac, do you think this situation can be salvaged? If not, is there any plausible path to removing these attributes?

@garykac
Copy link
Member

garykac commented Mar 9, 2017

You mean remove from the browsers? I don't see that happening for backward-compat reasons.

They're already not in the spec because of the issues mentioned above. If we want to fix this issue in the spec, we'd probably need to introduce new attributes that were clearly defined to handle the different meanings currently assigned to wheelDelta*. We haven't had a lot of push for that however.

Although there's still value in documenting the current (inconsistent) behavior someplace.

@foolip
Copy link
Member Author

foolip commented Mar 10, 2017

Yes, I mean removing from browsers, and I also think that's fairly unlikely to work out.

If it's still possible that picking one behavior and trying to align on that would work out, that would be a good plan A, but failing that, documenting what the options are would be good, I agree.

@mustaqahmed
Copy link
Member

mustaqahmed commented Jul 9, 2020

Apparently in Chrome we have been misinterpreting wheelDelta sign, and nobody complained.

@foolip
Copy link
Member Author

foolip commented Jul 14, 2020

Reposting my anecdote from that bug:

I actually have heard a web developer complaint that sounds like it could be related, from the MDN browser compatibility survey/interviews. One developer had noticed that the scrollIntoView method doesn't work on the horizontal axis in Chrome, and also mentioned a scroll event where the the direction was inverted in Firefox. I'm not certain, but it's plausible that was also about horizontal scrolling and that the inversion of deltaX was the cause.

@foolip
Copy link
Member Author

foolip commented Jul 14, 2020

Does someone have a test case for this?

@mustaqahmed
Copy link
Member

I was too concise, sorry: the double-negation bug in Chrome affects both wheelDeltaX and wheelDeltaY.

@zcorpan
Copy link
Member

zcorpan commented Jun 20, 2022

Does this issue also cover the actual mousewheel event (supported by Chromium and WebKit but not Gecko)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants