+++ This bug was initially created as a clone of Bug #1418822 +++

(See https://bugzilla.mozilla.org/show_bug.cgi?id=1418822#c40 for more context/backstory)

On Windows, when the OS setting for "number of lines to scroll per mousewheel tick" is set to any value other than the default of 3, Firefox's wheel scrolling distance drops in half. This makes the scrolling feel much slower than Chrome or Edge because the scroll distance is about half of what Chrome does at the same setting.

The reason we have this behaviour is because the 2x scaling factor in mousewheel.system_scroll_override_on_root_content.*.factor doesn't get applied when the OS setting is changed, because there was some concern about overriding user preferences but we still wanted to boost the scroll speed to support better "fast scrolling" scenarios (aka match Chrome's behaviour).

Other alternatives discussed in that bug involved some sort of scroll acceleration. This was implemented and exists in the code, but is disabled by default because some mouse drivers do their own acceleration and there's no good way to detect that and disable our own acceleration. So users end up with double acceleration and hard-to-control scrolling.

One alternative that wasn't discussed is what Edge does now, which is adjusting the scrolling speed based on the height of the scroller. This seems like a good solution as it allows scrolling large things faster while still scrolling smaller things slower so you don't jump past content entirely (a problem for short select elements). I think it might make sense to try implementing this behaviour and phasing out the "system scroll override" behaviour entirely.

One significant concern with any changes along these lines is migrating existing users to the new behaviour. We should tune the defaults of the new behaviour so that scrolling the root content on most websites remains roughly the same as it is now. And we should be pretty aggressive about using existing pref modifications as an indication that users have customized their prefs to get scrolling that works for them, and not fiddle with those much.

Even for users who haven't customized their prefs, it might be wise to gradually change the behaviour over a number of releases rather than do it abruptly, as a series of smaller changes over time will (I presume) be less likely to drive away users.

Also important is that currently precision trackpads on Windows get lumped into the same bucket as wheel mice, but they probably shouldn't be. With apz.allow_zooming=true (currently slated to ship in 82) we enable Direct Manipulation integration which allows us to distinguish those trackpads from other devices, and will make it easier to apply behaviour changes just to impulse mousewheels.

Ya I just saw this

"Windows applications have traditionally scrolled as a percentage of the scroller's visible size, whereas Chromium currently scrolls a fixed amount, based on the system settings and scroll modality.

We would like to introduce the option for Chromium (at least on Windows, potentially other platforms) to be able to perform percent-based scrolling."

here is the Chromium bug, there's a great document about it linked in there too https://bugs.chromium.org/p/chromium/issues/detail?id=1009735

See also
Intent to Implement: Percent-based scrolling
https://groups.google.com/a/chromium.org/forum/m/#!searchin/blink-dev/scrolling/blink-dev/U3kH6_98BuY
https://www.chromestatus.com/feature/5177131258609664

About percent-based scrolling; how does it behave with websites that have infinite scroll? If the distance per notch rolled is changing as the page gets longer, that sounds like a really bad experience. Users won't be getting consistent, predictable scroll distances.

(In reply to Will from comment #3)

About percent-based scrolling; how does it behave with websites that have infinite scroll? If the distance per notch rolled is changing as the page gets longer, that sounds like a really bad experience. Users won't be getting consistent, predictable scroll distances.

Percent-based scrolling would make the amount scrolled per wheel tick a percentage of the scrollable element's boundary size (so e.g. less for a textbox that's only a few lines of text tall, than for a scrollable element that takes up most of the page), not the length of the scrolled content, so infinite scrolling shouldn't make any difference.

Sorry to come back to this again but, although Windows is set to 3 by default (so I assume most Firefox users aren't being effected by this issue), I think Microsoft is wrong to have it set to 3 by default because mouse wheel scrolling is just too sensitive when it's set to 3. But as stated in comment 0, if a user changes it to 2 or 1, mouse wheel scrolling in Firefox is frustratingly inefficient/slow :(

Is this something you are able to work around by modifying other Firefox prefs, like mousewheel.default.delta_multiplier_y?

Yes, I've tinkered with Firefox extensively to get it to my liking, the reason I filed this bug (original is 1418822) is because I didn't want casual/non-technical users to be effected by this. Is it possible this can be fixed before the Chrome-extension-apocalypse happens in January? Firefox should be getting a lot of new users because of that and I'm certain many of them will be bothered by the less efficient mouse wheel scrolling. UX efficiency is important, especially for scrolling. It makes Firefox's scrolling "seem/feel" slow, even though it's not :(

We discussed this in our (Panning and Zooming) team meeting today.

The current behaviour is best illustrated in bug 1418822 comment 40:

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

As explained in comment 0, this happens because we apply a 2x increase (the "system scroll override") to the scroll distance when the OS setting for "number of lines to scroll per mousewheel tick" is at its default value of 3, but not for any other value.

TL;DR: We feel this behaviour is unintuitive, and we should aim to apply the system scroll override for all values of the OS setting.

The behaviour is unintuitive for two main reasons:

1. Discontinuity. Users expect that lowering the OS setting decreases scroll distances and raising the OS setting increases scroll distances. For Firefox, due to the discontinuity at n=3, this is not necessarily the case (e.g. increasing the setting from n=3 to n=4 results in a net decrease to Firefox's scroll distance).
2. Inconsistency between applications. A user who wants to adjust scrolling speed across the board may adjust the OS setting accordingly, only to find that the adjustment has a different effect in Firefox than in other applications (e.g. increasing the setting from n=3 to n=4 would increase Chrome's scroll distance but decrease Firefox's), and then have to resort to additional, application-specific tuning.

While a carve-out for n != 3 may have made sense at the time the system scroll override was introduced to avoid stomping on users who have already customized their behaviour, we feel the above downsides make this carve-out undesirable as a permanent fixture.

An open question is how to approach rolling out this change. Some possible options:

• Remove the carve-out for n != 3 unconditionally.
• Remove the carve-out for n != 3 for new profiles, while transitioning existing profiles gradually, the way we did for the smooth scroll animation duration in bug 1418822.
  • My personal feeling is that a gradual transition may be less suitable for this change, than it was for the animation duration change. The animation duration is mostly a matter of what you're used to, and gradually transitioning helps you get used to the new behaviour more easily. However, for scroll distance, users who like the current distance may find it easier to see an abrupt change and customize their settings to change it back once, rather than seeing gradual movement away from what they like over several releases.
• Only remove the carve-out for profiles where the user has imported data (e.g. bookmarks) from a Chrome installation, suggesting that they have switched to Firefox from Chrome. (This leaves open what to do with other profiles, which could range from nothing, through gradual transition, to a one-shot change at a future date.)

cc Masayuki in case you have any thoughts on this proposed direction.

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

One alternative that wasn't discussed is what Edge does now, which is adjusting the scrolling speed based on the height of the scroller. This seems like a good solution as it allows scrolling large things faster while still scrolling smaller things slower so you don't jump past content entirely (a problem for short select elements). I think it might make sense to try implementing this behaviour and phasing out the "system scroll override" behaviour entirely.

This seems like a potentially worthwhile change to explore, but it seems orthogonal to the change proposed in the previous comment.

In particular, if the concern is that small scrollers scroll too fast with the system scroll override in place, that's already the case today for users whose OS setting is the default n=3. I don't see a reason for fixing that to be a blocker for the proposed change for n != 3.

Just wanted to say that that's such an excellent point you made about users that decided to go from Windows default of 3 up to 4 or 5 will make things even worse for them! Some users must have been properly confused by that. And it's quite funny that, in Firefox, when Windows' setting is at 3 or 6, the scroll distance is the same

+1 for "Remove the carve-out for n != 3 unconditionally" for making handling reported bugs easier.

The reason why I made the system scroll speed override applied only when the value is "3" is, some bug reports come from the users who want to keep the original speed which are set before implementing the feature. Therefore, it's limited only when the system settings are the default value, "3", so the limitation is for the power uses who aggressively report bugs. On the other hand, the reason why the feature was added is, Chrome used x2 speed for making users feel faster. Therefore, for most users who don't customize anything, override the scroll speed.

However, the time passed, a lot of users who complained to apply the x2 speed unconditionally have already switched to another browser (and maybe non-Windows platform), and the major pointing device is switched from mouse to touchpad, so we could get of the limit in these days since users can disable the system scroll speed override with a pref, mousewheel.system_scroll_override.enabled.

On the other hand, some uses may have already customized their scroll speed with mousewheel.default.delta_multiplier_[xy]. So, if it's possible, we should migrate prefs, e.g., if the system settings are not "3" and mousewheel.default.delta_multiplier_[xy] is not "100", resetting mousewheel.default.delta_multiplier_[xy] to half value makes users never confused at crazy scroll speed.

Apply the system scroll override to the scroll distance regardless of
the Windows setting for the number of lines to scroll per mouswheel
tick.

https://hg.mozilla.org/mozilla-central/rev/ce0eeaca46e5

:dlrobertson did you want to nominate this for a mention in the fx116 release notes?

(In reply to Dianna Smith [:diannaS] from comment #15)

:dlrobertson did you want to nominate this for a mention in the fx116 release notes?

This really only impacts non-default configurations, so I don't think it really warrants a mention in the release notes.