Scrolling is terribly scroll with FireFox

[pyronaur]

Loving IScroll here, but when testing iScroll 5.0.9 from FireFox 26 on a Mac with a Logitech Mouse and the scrolling is terrible. I mean really terrible.
Scrolling with a trackpad is fluid and perfect, but as soon as I use the mousewheel I can't get anywhere.

I've tried setting the mouseWheelSpeed to up to 12000, webkit at this point doesn't bother scrolling - it just jumps from top to bottom instantly onScroll, but FireFox is as slow as it was with the setting set to 1.

This is probably related to the "smooth" scrolling they've implemented, although I tried changing FireFox settings: hardware acceleration ( made it worse ) and smooth scrolling off, and they didn't help at all - so I have no solid idea what's going on...

How bad is it ? It takes me about 9-12 seconds to scroll to the bottom of this demo: http://lab.cubiq.org/iscroll5/demos/probe/

Is anyone able to replicate this ?

I am open to any suggestions on how to fix it.

[Prinzhorn]

I can confirm this with Firefox on Ubuntu. For me the scroller only moves 3px for every mousewheel.

[cubiq]

the wheel algo will be soon refactored. I hope this will be solved with the new code

[pyronaur]

I can't wait! Not to rush you or anything,- do you have any estimate when could it arrive ? I will appreciate any pointers on what to look for to make a hotfix for it too! Thanks.

[dark-rising]

cubiq, do You have any progress in this issue?

[cubiq]

sorry guys, pretty busy time. this is on top of my priorities, I'll work on it as soon as I get some spare time.

[pyronaur]

Alex,
This is what I did to make it bearable on FireFox:

Modifying the _wheel method directly in the source:

        if ( 'deltaX' in e ) {
            var multiply = ( e.deltaMode === 1 ) ? this.options.mouseWheelSpeed : 1;
            wheelDeltaX = -e.deltaX * multiply;
            wheelDeltaY = -e.deltaY * multiply;
        } 

For iScroll 5.1.1 iscroll-probe.js it's line 1061 to line 1065

I'm still waiting for an actual solution though, but this at least hopefully does more good than harm.

[brynner]

Thanks @justnorris

[dark-rising]

cubiq, thank You for the wonderful plugin! I will wait patch.

justnorris, thanks for Your tip, you helped me a lot.

[mylastshot]

standing ovation for justnorris!

[jDavidnet]

I just tested our implementation in FF, and it seems fast. Is this still a problem?

[nerkn]

I had problem also. Solved by similar modification to @justnorris

[pyronaur]

It's still a problem in FireFox 26.0 on a Mac

Where did you test from @jDavidnet ?

Edit:
Just updated to FireFox 27.0, same issue.

[jDavidnet]

I tested it on a MacBook Pro summer 2012, 16gb ram Firefox 26+

Sent from my iPad

On Feb 8, 2014, at 6:10 AM, Norris notifications@github.com wrote:

It's still a problem in FireFox 26.0 on a Mac

Where did you test from @jDavidnet ?

—
Reply to this email directly or view it on GitHub.

[milax]

Awaiting the fix for this issue as well.

Thanks for cool plugin!

[wclr]

+1
for those who will use @justnorris quick fix, don't forget to declare var, to avoid global leak
var multiply = ( e.deltaMode === 1 ) ? this.options.mouseWheelSpeed : 1;

[neatcoding]

@justnorris's fix also worked me in Firefox on Ubuntu. Thanks for tip @whitecolor.

[Wraithers]

Yup, the source mods from @justnorris and @whitecolor did the trick for me, too - Win 8, Firefox 27.0.1. One note, it seems the original code lines have changed to line 1055 - 1057. Cheers!

[pyronaur]

@whitecolor Ooops. I'm very much used to coffeescript - forgetting to declare my vars - thanks for that, I fixed it my post.

[tommytee]

This solution fixes the wheel but breaks the trackpad. The trackpad scrolls way too much now.

How can this fix be applied to the wheel and not the trackpad?

[mrkeyboard]

+1 this issue occurs on all modern ff browsers and should be fixed. Meanwhile using the temp fix

[BryanCrow]

+1 this is still a big problem, 6 months later.

[jDavidnet]

Can you guys post more information on where it breaks?

I never had a problem in Firefox.

On Tue, Jul 15, 2014 at 12:53 PM, BryanTheCrow notifications@github.com
wrote:

+1 this is still a big problem, 6 months later.

—
Reply to this email directly or view it on GitHub
#577 (comment).

Justin Kruger
Social Media Software Engineer -
San Francisco, CA

http://jDavid.net
http://twitter.com/jdavid
http://www.linkedin.com/in/jdavid

jDavid.net@gmail.com

[BryanCrow]

It may have to do with the type of mouse you have (if it supports high dpi scrolling or not). Basically for me, the mouse wheel scrolls 1 pixel at a time. I just submitted a pull request with a patch based on @justnorris' suggestion: #752

[BryanCrow]

I did some reading up to verify this fix. Basically in Firefox, the scroll event can come with a deltaMode for pixels (0), lines (1), as in lines of text, or pages (2). The event comes through with different modes for different people, depending on the OS / Mouse combo. Details here: https://developer.mozilla.org/en-US/docs/Web/Events/wheel#The_deltaMode_value

When the event comes in with a deltaMode of lines (1), the typical system default number of lines of text to scroll per mouse-wheel click is 3 (at least that is the case in Windows). That said, if someone changes that value, chances are they prefer slower or faster scrolling so it's a good value to multiply by.

So, if we treat the delta we recieve of "3" as a pixel value instead of line value (the issue at hand here), we end up getting a very very slow scrolling speed. Hence the fix is to multiply the line value by the mouseWheelSpeed option, when the deltaMode of the event comes in as 1 (DOM_DELTA_LINE). With the default mouseWheelSpeed of 20, that will scroll 60px per wheel click. I'm not sure if a standard pixel amount per wheel click is desired, but if so, you can tweak the multiplier accordingly before applying this patch.

Note that when scrolling very fast, you'll receive a multiple of the system default number of lines to scroll in some of the wheel events (as if it queues them up and fires them less often). Ex: a flick of my mouse wheel gave me the following deltas: 3, 3, 3, 6, 9, 15, 6, 3, 3, 3, 3. Still, I believe amusing 3 to be a single click, you should multiply the delta by whatever value is needed in order to get the desired, consistent scroll speed. The other option one could considder would be to ignore the delta value, and just hard-code the multiplier based on if it's negative or positive. The problem with this is that precision trackpads (new in windows 8.1, and used by Microsoft's Surface tablets) will give you fractions of a line to scroll in each event (and far more events). So again, a multiplier is ideal.

More trial and error discussion here:
http://stackoverflow.com/questions/20110224/what-is-the-height-of-a-line-in-a-wheel-event-deltamode-dom-delta-line

...and here you can see Mozilla is not going to change this line-based scrolling behavior, so I believe this is a safe change to make and not one that will break in future versions of Firefox):
https://bugzilla.mozilla.org/show_bug.cgi?id=943034

[sulzbacher]

When will you solve this?

[filipmares]

Is this a issue reference?

[iSimonWeb]

+1 is there any news? This is unbearable.

[cubiq]

I'll fix this, probably tomorrow

[filipmares]

awesome!
-Filip

On Wed, Sep 17, 2014 at 9:50 AM, Matteo Spinelli notifications@github.com
wrote:

I'll fix this, probably tomorrow

Reply to this email directly or view it on GitHub:
#577 (comment)

[chchrist]

any news on this?

[boaz-amit]

This issue has been resolved in the latest release, version 5.1.3: 3480247

[nrstaber]

I am still seeing this as a problem. I have tried updating the about:config and it will be fixed for that time, but when I open Firefox up again it is slow like it was before I made the change.

[FractalizeR]

Why isn't 5.1.3 on CDN yet? Want to try it since I have the same problem.