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

Huge difference in scroll speed between firefox and chrome #67

Closed
jonenst opened this issue Apr 20, 2020 · 13 comments
Closed

Huge difference in scroll speed between firefox and chrome #67

jonenst opened this issue Apr 20, 2020 · 13 comments

Comments

@jonenst
Copy link
Contributor

jonenst commented Apr 20, 2020

Hi,
you are using ev.deltaY in

let lvl = Math.pow(1 + zoomFactor, (-1 * ev.deltaY) / 100) * this.zoom()
without checking the ev.deltaMode

On firefox on linux, we get the following event when scrolling:

{ deltaY: 3, deltaMode: 1}

on chrome on linux, we get

{ deltaY: 53, deltaMode: 0}

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

@Fuzzyma
Copy link
Member

Fuzzyma commented Apr 20, 2020

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...

@jonenst
Copy link
Contributor Author

jonenst commented Apr 21, 2020

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 ?

@Fuzzyma
Copy link
Member

Fuzzyma commented Apr 21, 2020

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?

@jonenst
Copy link
Contributor Author

jonenst commented Apr 21, 2020

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)

-      let lvl = this.zoom() - zoomFactor * ev.deltaY / Math.abs(ev.deltaY)
+      let lvl = Math.pow(1 + zoomFactor, (-1) * ev.deltaY / 100) * this.zoom()

before you had "ev.deltaY / Math.abs(ev.deltaY)" which was always +1 or -1
now you use ev.deltaY directly

@Fuzzyma
Copy link
Member

Fuzzyma commented Apr 22, 2020

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?

@jonenst
Copy link
Contributor Author

jonenst commented Apr 22, 2020

Sure, here you go: https://codepen.io/jonenst/pen/PoPbxrg
I used
https://unpkg.com/@svgdotjs/[email protected]/dist/svg.js
https://unpkg.com/@svgdotjs/[email protected]/dist/svg.panzoom.js

and here's a ®high quality gif ™ of it (on the right chrome zooming, on the left firefox)

panzoom

cheers,
Jon

@Fuzzyma
Copy link
Member

Fuzzyma commented Apr 22, 2020

jep confirmed - that sucks...
If the events indeed fire different number of times we have to go with your solution. But if they fire about the same amount, we can just use +-1 again instead of the delta

@jonenst
Copy link
Contributor Author

jonenst commented Apr 22, 2020

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.
Also, if we use something like

(if deltaMode == 1) {
  deltaY = deltaY * PIXELS_PER_LINE
}

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,
Jon

@Fuzzyma
Copy link
Member

Fuzzyma commented Apr 22, 2020

That could work. I hereby declare to not support deltaMode=2. This is just nonesense...

@jonenst
Copy link
Contributor Author

jonenst commented Apr 22, 2020

Do you want me to do the PR ? You might know better how to make the PIXELS_PER_LINE value configurable

@Fuzzyma
Copy link
Member

Fuzzyma commented Apr 23, 2020

just add an option. It should be quite obvious were to put it :)

@trusktr
Copy link

trusktr commented Mar 22, 2024

There are too many inconsistencies with delta values across browsers, even today. Related web spec issue:

@Fuzzyma
Copy link
Member

Fuzzyma commented Jun 18, 2024

@trusktr how would you go about to solve this issue? Good old browser sniffing maybe?

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

No branches or pull requests

3 participants