This deserves more attention. Firefox's scrolling performance has improved significantly in recent years but you wouldn't know it because of this issue (it's making Firefox's mouse wheel scrolling feel slow)

I thought we fixed this in bug 1217715.

Apparently not :(
I can still repro on 65.0.2 on Windows 10 (version 1809), vertical scrolling "The following number of lines at a time" is set to 2 . Edge and Chrome scroll pretty much the same distance per notch roll (maybe a few pixels off).

I'm pretty sure this isn't relevant but my system display scaling is set to 175%

Can this please be given a higher priority? Scrolling is such a core and important part of the experience and mouse wheel scrolling effectively being slower than other browsers is a serious problem

I've been trying to make some time to look at this, but I'm also juggling a bunch of correctness bugs, and it's hard to justify working on a scrolling speed issue in preference to issues that cause some websites to not be usable at all.

As an interim solution, does increasing mousewheel.default.delta_multiplier_y in about:config resolve the issue for you?

My interim solution was changing Windows' mouse wheel "The following number of lines at a time" to 3. The reason I keep coming back to this issue is because I'm certain it's making users think Firefox's scrolling is "slow", and I'm certain we've lost users because of this. I tried looking in MSDN for something about distance per notch rolled but I couldn't find anything. Maybe someone should reach out to Microsoft about this? It does seem like something that should be standard and consistent across all apps

(In reply to Will from comment #15)

The reason I keep coming back to this issue is because I'm certain it's making users think Firefox's scrolling is "slow", and I'm certain we've lost users because of this.

Thanks. I agree that this is concerning. I'm adding the [qf] whiteboard tag to get this bug into the performance team's triage queue.

Justin

Justin: This came up during QF triage. This is a perceived responsiveness issue, but doesn't appear to actually by a perf issue in Firefox. Can we get someone on the front end team or in UX to figure out whether we should be changing the default values of the prefs in comment #1 above? Maybe we should have a slider somewhere in our UI where the scroll speed can be altered?

Can someone ask Microsoft what is the "correct" amount of pixels per notch rolled? Surely they have a standard for this

(In reply to Botond Ballo [:botond] from comment #14)

I've been trying to make some time to look at this, but I'm also juggling a bunch of correctness bugs, and it's hard to justify working on a scrolling speed issue in preference to issues that cause some websites to not be usable at all.

As an interim solution, does increasing mousewheel.default.delta_multiplier_y in about:config resolve the issue for you?

Ive been looking around and trying a plethora of about config settings to fix this. My issue is that I want to totally turn off the gravity based animation of the scrolling, aka disable smooth scrolling (I think), but it just doesnt appear to work in 70 on Windows 10. I want it to instantly scroll a page, not animate.

Of all the settings I tried, this was the closest to making it very fast (at least, if not instant), but it also had the repercussion of making it scroll further than one page, so that doesnt work.

(In reply to taosk8r from comment #20)

My issue is that I want to totally turn off the gravity based animation of the scrolling, aka disable smooth scrolling (I think), but it just doesnt appear to work in 70 on Windows 10. I want it to instantly scroll a page, not animate.

That sounds like a different issue than this bug, which is about not scrolling far enough per wheel tick.

Smooth scrolling can be disabled in Edit -> Preferences -> General -> Browsing -> "Use smooth scrolling". Does that help?

(In reply to taosk8r from comment #20)

(In reply to Botond Ballo [:botond] from comment #14)

I've been trying to make some time to look at this, but I'm also juggling a bunch of correctness bugs, and it's hard to justify working on a scrolling speed issue in preference to issues that cause some websites to not be usable at all.

As an interim solution, does increasing mousewheel.default.delta_multiplier_y in about:config resolve the issue for you?

Ive been looking around and trying a plethora of about config settings to fix this. My issue is that I want to totally turn off the gravity based animation of the scrolling, aka disable smooth scrolling (I think), but it just doesnt appear to work in 70 on Windows 10. I want it to instantly scroll a page, not animate.

Of all the settings I tried, this was the closest to making it very fast (at least, if not instant), but it also had the repercussion of making it scroll further than one page, so that doesnt work.

But this issue is not about the animation used for smooth scrolling (or at least, it shouldn't be). It shouldn't matter if the user has smooth scrolling enabled or not, it should scroll the same distance per notch for both. If you want them to change the curve or the duration of the smooth scrolling animation, you should open a different bug.

(In reply to Botond Ballo [:botond] from comment #21)

(In reply to taosk8r from comment #20)

My issue is that I want to totally turn off the gravity based animation of the scrolling, aka disable smooth scrolling (I think), but it just doesnt appear to work in 70 on Windows 10. I want it to instantly scroll a page, not animate.

That sounds like a different issue than this bug, which is about not scrolling far enough per wheel tick.

Smooth scrolling can be disabled in Edit -> Preferences -> General -> Browsing -> "Use smooth scrolling". Does that help?

Yeah, I guess I use full page, so I dont see the tick speed, but no, turning off smooth scrolling in either options or about config doesnt actually appear to have any effect to my perception, and so I guess Ill make a new report about that.

Backed out changeset 967ed92f3655 (Bug 1418822) for causing mochitest and reftest failures in layout/generic/test/test_page_scroll_with_fixed_pos.html CLOSED TREE

https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&selectedJob=287988950

https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&selectedJob=287990521

https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=287988950&repo=autoland&lineNumber=18007

https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=287990521&repo=autoland&lineNumber=17479

https://treeherder.mozilla.org/#/jobs?repo=try&revision=fc9f2f0647941cae413baaac992e693723a8fa44

Finally have an official figure for mousewheel tick distance: "Chromium browsers use a fixed scroll delta value (100px per mousewheel tick"

from a blog post from Microsoft today, scroll down to "Percent-based scrolling" section https://blogs.windows.com/msedgedev/2020/04/02/scrolling-personality-improvements/

Interestingly though, Microsoft goes on to say they're changing that for their Chromium-based Edge: "We are changing this behavior to match previous versions of Microsoft Edge, which use scroller height to compute scroll deltas. Percent based scrolling is a great functional addition making it much easier to navigate smaller scrollers."

I don't know why this never landed but I'll see if I can get it landed.

Ok, I've read over all the related bugs (bug 1216934, bug 1388848, this one, and a few others) and looked at all the different prefs whose tweaking has been suggested. I have a limited set of hardware to test with but I tried a few things.

It seems pretty clear that we absolutely want to reduce the general.smoothScroll.mouseWheel.duration*MS prefs, probably to min=50,max=200 as Philipp had suggested. That makes impulse wheel-scrolling much snappier.

The distance that impulse wheel-scrolling goes on a single impulse is (in a default Windows configuration, no user modifications) controlled by the mousewheel.system_scroll_override_on_root_content.*.factor prefs, which are set to 200. I think this is reasonable and gives us a scroll distance that matches Chrome. Edge's scroll distance varies based on window size; on my maximized window Edge scrolls more (equivalent to what we do if the aforementioned prefs are set to 300) but on a smaller window it scroll less. So an "average" of 200 seems reasonable.

mousewheel.default.delta_multiplier_y affects mousewheel distance on Windows only if user-modified, but does affect trackpad scrolling on macOS, and probably mousewheel on Linux. So I think for now we can just leave that be. If people want faster scrolling on macOS (or Linux) we can look into adjusting this.

mousewheel.acceleration.start and mousewheel.acceleration.factor control acceleration of mousewheel scrolling after a certain number of wheel events in quick succession. The default values of -1 and 10 disable the acceleration entirely. Scrolling long pages can be somewhat tedious with these defaults. Haik's suggestion of 1 and 4 makes single scrolls go less distance (40% of baseline) but if I set the values to 3 and 4 that provides a reasonable behaviour. The scroll distances for a quick sequence of wheel events would then be 1x, 1x, 1.2x, 1.6x, 2.0x, .... I think having this acceleration will help when comparing to Edge's larger "max window scroll distance per impulse" because scrolling fast on a big window will behave somewhat similar to Edge. HOWEVER, the problem here is that with apz.allow_zooming=false (which will be the default on 81 and older) this acceleration ends up getting applied to precision trackpad scroll events too, because for some reason we send those as line-based events rather than pixel-based events. So that makes scrolling way too fast and uncontrollable. Once we turn on direct manipulation support with apz.allow_zooming=true in 82, we can set these prefs and make impulse wheels better. Alternatively we can try and land something in 81 that makes trackpads send pixel events instead of line events, and then turn these prefs on in 81.

Hitting page up/pagedown or clicking on the scrollbar track uses the general.smoothScroll.pages.duration*MS values, and our behaviour seems somewhere in between Chrome and Edge, closer to Chrome. Edge feels almost lethargic - it starts out fast but then the tail end of the animation is quite slow. Chrome is pretty snappy and abrupt. We're snappy but not quite as fast as Chrome. I slightly prefer our behaviour here but if we wanted to be closer to Chrome by reducing those time values I wouldn't object. Note that with apz.allow_zooming=true and apz.force_disable_desktop_zooming_scrollbars=false we end up using the MSD physics for scrollbar track clicks which feels very different, much closer to Edge. So we'll want to fix that, and that's tracked in bug 1658169.

So in summary I plan to make these changes right now:
general.smoothScroll.mouseWheel.durationMaxMS: old=400, new=200
general.smoothScroll.mouseWheel.durationMinMS: old=200, new=50
And these changes once we can get trackpads to send pixel-based events instead of line-based events:
mousewheel.acceleration.start: old=-1, new=3
mousewheel.acceleration.factor: old=10, new=4

As long as this is a strict improvement over the current behaviour (which I believe it should be) we can refine based on feedback in subsequent patches.

Respectfully, and without intending to turn this into an opinion thread, there is (in my view) a group of users that prefer Firefox's scrolling behavior compared to Chrome and Edge: https://www.reddit.com/r/firefox/comments/ibiawu/better_mousewheel_scroll_coming_to_firefox_more/

To me, if feels more natural, although I accept this is subjective.
If, however, the bug is in relation to Firefox not respecting Windows' mouse settings, then I understand.

Is there a consensus from users, or an experiment that suggests this is an issue?

Thanks

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #32)

Ok, I've read over all the related bugs (bug 1216934, bug 1388848, this one, and a few others) and looked at all the different prefs whose tweaking has been suggested. I have a limited set of hardware to test with but I tried a few things.

It seems pretty clear that we absolutely want to reduce the general.smoothScroll.mouseWheel.duration*MS prefs, probably to min=50,max=200 as Philipp had suggested. That makes impulse wheel-scrolling much snappier.

The distance that impulse wheel-scrolling goes on a single impulse is (in a default Windows configuration, no user modifications) controlled by the mousewheel.system_scroll_override_on_root_content.*.factor prefs, which are set to 200. I think this is reasonable and gives us a scroll distance that matches Chrome. Edge's scroll distance varies based on window size; on my maximized window Edge scrolls more (equivalent to what we do if the aforementioned prefs are set to 300) but on a smaller window it scroll less. So an "average" of 200 seems reasonable.

mousewheel.default.delta_multiplier_y affects mousewheel distance on Windows only if user-modified, but does affect trackpad scrolling on macOS, and probably mousewheel on Linux. So I think for now we can just leave that be. If people want faster scrolling on macOS (or Linux) we can look into adjusting this.

mousewheel.acceleration.start and mousewheel.acceleration.factor control acceleration of mousewheel scrolling after a certain number of wheel events in quick succession. The default values of -1 and 10 disable the acceleration entirely. Scrolling long pages can be somewhat tedious with these defaults. Haik's suggestion of 1 and 4 makes single scrolls go less distance (40% of baseline) but if I set the values to 3 and 4 that provides a reasonable behaviour. The scroll distances for a quick sequence of wheel events would then be 1x, 1x, 1.2x, 1.6x, 2.0x, .... I think having this acceleration will help when comparing to Edge's larger "max window scroll distance per impulse" because scrolling fast on a big window will behave somewhat similar to Edge. HOWEVER, the problem here is that with apz.allow_zooming=false (which will be the default on 81 and older) this acceleration ends up getting applied to precision trackpad scroll events too, because for some reason we send those as line-based events rather than pixel-based events. So that makes scrolling way too fast and uncontrollable. Once we turn on direct manipulation support with apz.allow_zooming=true in 82, we can set these prefs and make impulse wheels better. Alternatively we can try and land something in 81 that makes trackpads send pixel events instead of line events, and then turn these prefs on in 81.

Hitting page up/pagedown or clicking on the scrollbar track uses the general.smoothScroll.pages.duration*MS values, and our behaviour seems somewhere in between Chrome and Edge, closer to Chrome. Edge feels almost lethargic - it starts out fast but then the tail end of the animation is quite slow. Chrome is pretty snappy and abrupt. We're snappy but not quite as fast as Chrome. I slightly prefer our behaviour here but if we wanted to be closer to Chrome by reducing those time values I wouldn't object. Note that with apz.allow_zooming=true and apz.force_disable_desktop_zooming_scrollbars=false we end up using the MSD physics for scrollbar track clicks which feels very different, much closer to Edge. So we'll want to fix that, and that's tracked in bug 1658169.

So in summary I plan to make these changes right now:
general.smoothScroll.mouseWheel.durationMaxMS: old=400, new=200
general.smoothScroll.mouseWheel.durationMinMS: old=200, new=50
And these changes once we can get trackpads to send pixel-based events instead of line-based events:
mousewheel.acceleration.start: old=-1, new=3
mousewheel.acceleration.factor: old=10, new=4

As long as this is a strict improvement over the current behaviour (which I believe it should be) we can refine based on feedback in subsequent patches.

You're not making any changes for distance per mousewheel tick?

(In reply to bug.zilla from comment #35)

Respectfully, and without intending to turn this into an opinion thread

Don't worry, it's already an opinion thread. Scrolling behaviour is very subjective and there's no one-size-fits-all.

, there is (in my view) a group of users that prefer Firefox's scrolling behavior compared to Chrome and Edge: https://www.reddit.com/r/firefox/comments/ibiawu/better_mousewheel_scroll_coming_to_firefox_more/

There's a bunch of confusion on that thread, which is not surprising because the discussion on this bug has veered through a bunch of topics and is not really easy to follow. And in particular the prefs I propose to change do nothing about the current bug summary (which is about scroll distance per mousewheel "tick") so maybe I should change the summary to match what I'm actually doing. But for now the only change I'm making is to make mousewheel scrolling snappier.

Is there a consensus from users, or an experiment that suggests this is an issue?

It's hard to get any sort of consensus on this topic. Experiments have been proposed and never happened, and are unlikely to happen anytime in the forseeable future. But anecdotally a lot of people have complained about the mousewheel scrolling behaviour, and I'd like to tweak the defaults in a way that makes it feel better while having a low risk of alienating current users who feel it works ok. In particular I don't want to blindly adopt Chrome or Edge's behaviour (and hopefully as you can see from comment 32, I'm not doing that).

In the end it is totally subjective, but hopefully more people will prefer the new behaviour and people who feel strongly about the old behaviour still have the prefs they can adjust to fit their needs.

(In reply to Will from comment #36)

You're not making any changes for distance per mousewheel tick?

Not in the patch that landed, but I should test the distance settings a bit more. When I tested I was getting approximately the same distance per mousewheel tick on Chrome and Firefox. That's with (I believe) the default Windows system settings of "3 lines per mouse wheel scroll". I just tried changing that parameter and I do see that as it goes up, Chrome scrolls significantly further than we do, which is unexpected to me - I would have expected it to remain on par. I'll play around with that more tomorrow, marking this bug leave-open for now.

But I don't think the distance per mousewheel tick is subjective, or at least it probably shouldn't be. It's unfortunate that it's not perfectly clear what should be done for distance (Edge using percent-based, Chrome using fixed), but I guess just test each setting ("The following number of lines at a time" in Mouse Properties) and make sure Firefox is similar or between Edge and Chrome on a variety of common websites. The reason I originally filed this issue is because when I switched from Chrome to Firefox 3 years ago, the thing I noticed right away is that I had to scroll a lot more in Firefox compared to Chrome. It was frustrating. UX efficiency is very important. I think the average user would quickly abandon Firefox and go right back to Chrome because of the UX efficiency downgrade for mouse wheel scrolling, so please try to do something about the distance issue

https://hg.mozilla.org/mozilla-central/rev/39fd3e407dba

I tested a bit more at different "number of lines at a time" in the Windows settings. Using the same page in Chrome and FF:

@ 1 line => Chrome = 33, Firefox.= 17
@ 2 lines => Chrome = 67, Firefox = 34
@ 3 lines => Chrome = 100, Firefox = 102
@ 4 lines => Chrome = 133, Firefox = 68
@ 5 lines => Chrome = 167, Firefox = 85
@ n lines, for n !=3 => Chrome = 33.33 * n, Firefox = 17 * n

So yes, Firefox is objectively wrong here, because it has some sort of magical behaviour when n = 3 and uses n * 17 for all other values.

I tried a few different websites and also fiddled with the font sizes on the body/html elements and none of that seemed to make a difference, the values seem effectively hard-coded.

When applying reflow zoom at 200%, Chrome's scroll per line remained constant in screen pixels (values reported by window.scrollY in CSS pixels got halved). Firefox's scroll got scaled up in CSS pixels but only by a tiny amount. e.g. at 5 lines/tick, it went from 85 CSS pixels to 90 CSS pixels. At the magical value of n=3 it went from 102 CSS pixels to 108 CSS pixels.

So obviously there are things here that need fixing, I'll spend some time debugging this.

FWIW..

Many years ago I had to change the various prefs that controlled scrolling in order for it to be smooth. After applying the Nightly update, which includes this patch, scrolling is absolutely worse now. It is no longer smooth. The scrolling looks like only the lines per scroll set in my mouse control panel under Windows 10 are taking affect.

Can you provide the set of prefs you have modified? That would be slightly more useful than a non-specific complaint.

Ouch!

user_pref("general.smoothScroll.lines.durationMaxMS", 400);
user_pref("general.smoothScroll.lines.durationMinMS", 200);
user_pref("general.smoothScroll.other.durationMaxMS", 400);
user_pref("general.smoothScroll.other.durationMinMS", 200);
user_pref("general.smoothScroll.pages.durationMaxMS", 400);
user_pref("general.smoothScroll.pages.durationMinMS", 200);
user_pref("general.smoothScroll.pixels.durationMaxMS", 400);
user_pref("general.smoothScroll.pixels.durationMinMS", 200);
user_pref("general.smoothScroll.scrollbars.durationMaxMS", 400);
user_pref("general.smoothScroll.scrollbars.durationMinMS", 200);
user_pref("mousewheel.acceleration.start", 1);

Sorry if that came out snarky. It seems clear that you have a preference for scrolls that take 200-400ms to complete. So yes, since the patch speeds up wheel scrolls from the 200-400ms range down to the 50-200ms (which brings it more in line with the defaults for the prefs you've modified), it makes sense that you would observe a difference. But I would argue that since you've modified all these other prefs to bring those scrolls in the 200-400ms range, you can just do the same for the general.smoothScroll.mouseWheel.duration prefs (i.e. revert my patch by modifying those prefs back locally). I don't consider this a reason to back out the patch.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #40)

So yes, Firefox is objectively wrong here, because it has some sort of magical behaviour when n = 3 and uses n * 17 for all other values.

This is because when the system default "lines per wheel" is changed, we no longer apply the mousewheel.system_scroll_override_on_root_content scaling prefs (which by default multiply distance by 2.0x). Getting rid of this special-case behaviour may not be trivial though.

Other related reading material that I came across for those following along at home:

https://bugzilla.mozilla.org/show_bug.cgi?id=513817 <-- this one is where the override thing was first added, and discusses it in quite a bit of detail
https://bugzilla.mozilla.org/show_bug.cgi?id=1153156#c56
https://wiki.mozilla.org/Gecko:Mouse_Wheel_Scrolling
https://wiki.mozilla.org/Firefox/Projects/AcceleratedScrolling
https://bugzilla.mozilla.org/show_bug.cgi?id=509651

Some of this is about the "accelerated scrolling" prefs I said I was intending to change (mousewheel.acceleration.start and mousewheel.acceleration.factor) and I'm no longer sure I want to do that, because apparently some mice already have built-in acceleration and users with those mice will get double-accelerated.

For scroll distance tuning, I'm now thinking that doing the Edge-style "scroll distance depends on scroller height" might be the way to go, as it should allow us to remove the override behaviour, and should work reasonably without acceleration on our part.

(In reply to Will from comment #15)

My interim solution was changing Windows' mouse wheel "The following number of lines at a time" to 3.

What value do you normally have for this setting? I mostly just want to confirm here that your initial complaint in this bug was about the distance when the setting is set to something other than 3. In that scenario I do see Firefox's scroll distance per tick is about half what Chrome does, which is already less than Edge (but dependent on scroller size). Given that 3 is the windows default setting, most users will not experience this bug, and might be used to (or prefer) Firefox's current scroll distance behaviour.

In retrospect I should have landed the patch using a different bug instead of repurposing this one, but now that the patch has landed, I think the best way forward is to close this bug and file a new one about improving the scroll distance behaviour, which is what you wanted all along, and that I agree needs to be done. I don't want to do that work in this bug because it likely won't be easy to do well until 82, when we can separate precision trackpads (which will get the direct manipulation codepath) from everything else.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #46)

(In reply to Will from comment #15)

My interim solution was changing Windows' mouse wheel "The following number of lines at a time" to 3.

What value do you normally have for this setting? I mostly just want to confirm here that your initial complaint in this bug was about the distance when the setting is set to something other than 3. In that scenario I do see Firefox's scroll distance per tick is about half what Chrome does, which is already less than Edge (but dependent on scroller size). Given that 3 is the windows default setting, most users will not experience this bug, and might be used to (or prefer) Firefox's current scroll distance behaviour.

In retrospect I should have landed the patch using a different bug instead of repurposing this one, but now that the patch has landed, I think the best way forward is to close this bug and file a new one about improving the scroll distance behaviour, which is what you wanted all along, and that I agree needs to be done. I don't want to do that work in this bug because it likely won't be easy to do well until 82, when we can separate precision trackpads (which will get the direct manipulation codepath) from everything else.

I had "The following number of lines at a time" set to 2. When I switched to Firefox and noticed how much more I had to scroll compared to Chrome, I put it up to 3.

Btw, thank you for taking this on. I'm quite surprised this wasn't caught sooner though.

Ok, thanks. I've filed bug 1659790 to track adjusting the mousewheel distance, and I'll close this bug.