-
Notifications
You must be signed in to change notification settings - Fork 54
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
Huge difference in scroll speed between firefox and chrome #67
Comments
Feel free to create a PR to fix this issue. There also was a different issue (in the chat), that in chrome the event fires far more often than in Firefox. It would make sense if chrome fires it for every px instead of line. What about figuring out how high a DOM_DELTA_LINE is in Firefox and multiply by that amount? Feels more stable... |
As per https://stackoverflow.com/questions/20110224/what-is-the-height-of-a-line-in-a-wheel-event-deltamode-dom-delta-line , computing the exact pixel height is difficult :( But for my case of using zoom, I don't need it to be pixel accurate, I just don't want it to be unusable. Would you accept a simple PR multiplying by 17 just to make it usable again ? |
The thing is: I used panzoom in both browsers and never had an issue with scroll speed. Is this something which is only present on linux? |
according to w3c/uievents#181 (comment) it should be slow with firefox on all platforms.. Maybe you haven't seen the problem because you only changed recently in 01a627a Date: Wed Jan 29 07:01:21 2020 +0100 (release 2.1.0)
before you had "ev.deltaY / Math.abs(ev.deltaY)" which was always +1 or -1 |
No, actually I tried it with that change. But I could be wrong. Do you mind creating a codepen with a minimal example so I can look into the issue? |
Sure, here you go: https://codepen.io/jonenst/pen/PoPbxrg and here's a ®high quality gif ™ of it (on the right chrome zooming, on the left firefox) cheers, |
jep confirmed - that sucks... |
The nice thing with using the real value of deltaY is that you get slow/fast scrolling with a touchpad depending on how fast you swipe.
Then it will only affect the firefox broken case. Make PIXELS_PER_LINE configurable and it should work for everyone ? I don't know how many events are fired but I don't think going back to the +-1 is the best option. By the way, if you have a windows machine, maybe you can try to look what happens when the browser uses deltaMode=2 ( https://i.stack.imgur.com/3AtUg.png ), if zooming is fixable in this mode or not. Cheers, |
That could work. I hereby declare to not support deltaMode=2. This is just nonesense... |
Do you want me to do the PR ? You might know better how to make the PIXELS_PER_LINE value configurable |
just add an option. It should be quite obvious were to put it :) |
There are too many inconsistencies with delta values across browsers, even today. Related web spec issue: |
@trusktr how would you go about to solve this issue? Good old browser sniffing maybe? |
Hi,
you are using ev.deltaY in
svg.panzoom.js/src/svg.panzoom.js
Line 51 in 27f5e88
On firefox on linux, we get the following event when scrolling:
on chrome on linux, we get
This results in huge scrolling speeds which make the zooming almost unusable. Since we don't need absolute pixel precision here, I suggest to add code to multiply the deltaY by some value, maybe 17 or just 15 or 20 when deltaMode is (1) DOM_DELTA_LINE.
Reference: https://developer.mozilla.org/en-US/docs/Web/API/WheelEvent/deltaY
Note that there are currently debates on what do to, but it's been going on for years:
https://bugzilla.mozilla.org/show_bug.cgi?id=1392460
w3c/uievents#181
Adding this would fix the problem right now.
Cheers,
Jon
The text was updated successfully, but these errors were encountered: