1388848 - Consider tuning the smooth scroll speed for mouse wheel scrolling

Status: RESOLVED DUPLICATE of bug 1418822

(Firefox :: General, enhancement, P3)

Description

[Ryan Hunt [:rhunt] (on leave until early May)]

I was comparing the different scroll behavior's between Chrome, Edge, and Firefox, and noticed that Firefox has a slower mouse wheel scroll than the others.

I think it would be worthwhile to review the scroll animation we're using, to increase perceptual responsiveness. I personally feel like shortening the animation duration could do this.

The scroll animation duration is configurable, the prefs for mouse wheel are

'general.smoothScroll.mouseWheel.durationMaxMS' (default 400)
'general.smoothScroll.mouseWheel.durationMinMS' (default 200)

I have these prefs halved to (200, 100), and I feel like scrolling is more responsive.

I know this is pretty subjective, so I'd like to get UX opinions on this.

I will link or attach screencasts of mouse wheel scrolling on the different browsers.

Comment 1

[Asa Dotzler [:asa]]

I was considering this for a pref flipping study. It would be pretty easy to get some user feedback on it that way.

Comment 2

[Ryan Hunt [:rhunt] (on leave until early May)]

The screencasts are too large for attachments so I've uploaded them to my dropbox.

They're 60fps and the dropbox streamer doesn't seem to have very good quality so I'd recommend downloading them.

Nightly (default prefs) - https://www.dropbox.com/s/mhja0er1n9ivbns/nightly-default.mp4?dl=1
Nightly (tweaked prefs) - https://www.dropbox.com/s/5i9375otc059bhd/nigthly-tweaked.mp4?dl=1
Chrome Canary - https://www.dropbox.com/s/2y1bg72n7m242hp/chrome-canary.mp4?dl=1
Edge - https://www.dropbox.com/s/0oq5k1xpfsvzs59/edge.mp4?dl=1

In each video I scroll one mouse wheel tick(?) at a time down and up the page, then I do a fast scroll down and back up.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

(In reply to Asa Dotzler [:asa] from comment #1)
> I was considering this for a pref flipping study. It would be pretty easy to
> get some user feedback on it that way.

If we can do this in time for 57 that would be great. I agree with Ryan that a change like this could improve the perception of the browser and make it feel snappier.

Comment 4

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Perfect timing! I was working on a proposal for a pref-flipping study for this, but the effort has been dormant for a while.

The proposal touches on a few other prefs as well:
https://docs.google.com/document/d/1OCSQ_B_ukScIeSrgoIRzaWgs3Aa8Q7Y8woCtlwRwDRM/edit

Comment 5

[Ryan Hunt [:rhunt] (on leave until early May)]

(In reply to (Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #4)
> Perfect timing! I was working on a proposal for a pref-flipping study for
> this, but the effort has been dormant for a while.
> 
> The proposal touches on a few other prefs as well:
> https://docs.google.com/document/d/
> 1OCSQ_B_ukScIeSrgoIRzaWgs3Aa8Q7Y8woCtlwRwDRM/edit

Anecdotally, I quite like those pref changes. (testing on windows with a synaptics touchpad).

Comment 6

[:Harald Kirschner :digitarald]

Just talked with :phlsa and I'll be starting a hypothesis doc on the experiment.

For engagement metrics I am thinking about using the scroll-max (bug 1312881) and scroll-total (bug 1297867). 

Some questions that came up:

1) As a second test branch, would it be interesting to switch off smooth scrolling for mousewheel?

2) As a negative test for seeing how the metrics behave, would it make sense to make smooth scroll even slower for some users?

Comment 7

[Ryan Hunt [:rhunt] (on leave until early May)]

(In reply to :Harald Kirschner :digitarald from comment #6)
> Just talked with :phlsa and I'll be starting a hypothesis doc on the
> experiment.
> 
> For engagement metrics I am thinking about using the scroll-max (bug
> 1312881) and scroll-total (bug 1297867). 

Is bug 1328678 still an issue for scroll-total? IIRC we were getting clamped data because of it.

Comment 8

[Markus Stange [:mstange]]

Copying my comment from bug 1199468 here:

Here's a try build with tweaked smooth scroll physics: https://queue.taskcluster.net/v1/task/Uj55p0V0Q3i-fj7FDziM8w/runs/0/artifacts/public/build/target.zip

try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=24727cb0ac670c6753fb02803f44cc0405a8aa49

I've tried to make scrolling with regular scroll wheels feel a bit more like in Edge. I haven't tested this change with other input methods. The goal here was to maybe find a quick way of tweaking things to get a cheap improvement in 57.
I don't have the domain knowledge or the time to look into using DirectManipulation for scrolling.

I'd like to encourage interested parties to test the build.

Comment 9

[Markus Stange [:mstange]]

Some background:

Edge (or Windows 10 in general, I guess) seems to be using a dampened spring physics model for the animation, with varying spring constants. I'm not 100% sure about this but it very much feels like it.
So how does it decide on the spring constants? It looks like the spring is very soft when you do a very quick scroll, or if you do keyboard scroll; but if you do a scroll motion that slows down towards the end, it uses a stiffer spring so that the scroll comes to an end more quickly.
I've tried to emulate that a bit but the thresholds probably need to be tweaked.

Comment 10

[Markus Stange [:mstange]]

The other difference I found in Edge was the scroll distance. We match it if you change mousewheel.system_scroll_override_on_root_content.vertical.factor from 200 to 355.

Comment 11

[Ryan Hunt [:rhunt] (on leave until early May)]

(In reply to Markus Stange [:mstange] from comment #9)
> Some background:
> 
> Edge (or Windows 10 in general, I guess) seems to be using a dampened spring
> physics model for the animation, with varying spring constants. I'm not 100%
> sure about this but it very much feels like it.
> So how does it decide on the spring constants? It looks like the spring is
> very soft when you do a very quick scroll, or if you do keyboard scroll; but
> if you do a scroll motion that slows down towards the end, it uses a stiffer
> spring so that the scroll comes to an end more quickly.
> I've tried to emulate that a bit but the thresholds probably need to be
> tweaked.

I tried out your build and it definitely feels closer to what edge is doing. It feels looser than edge, but I'm guessing that is more tweaking spring constants than changing the algorithm.

If a telemetry probe is under consideration and there is time, it might be worth it to put in an edge style scrolling behavior behind a pref and have that be the third option.

Comment 12

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Markus Stange [:mstange] from comment #9)
> Some background:
> 
> Edge (or Windows 10 in general, I guess) seems to be using a dampened spring
> physics model for the animation, with varying spring constants. I'm not 100%
> sure about this but it very much feels like it.
> So how does it decide on the spring constants? It looks like the spring is
> very soft when you do a very quick scroll, or if you do keyboard scroll; but
> if you do a scroll motion that slows down towards the end, it uses a stiffer
> spring so that the scroll comes to an end more quickly.
> I've tried to emulate that a bit but the thresholds probably need to be
> tweaked.

Aside: What does Chrome do? People don't really browse the web much on Win10 using Edge compared to Chrome, so unless they're identical I think I'm more interested in chrome's behavior.

Comment 13

[Markus Stange [:mstange]]

I haven't checked. But I've heard from many people that Edge's scrolling experience is regarded as superior.

Comment 14

[Kartikaya Gupta (email:[e-mail])]

[Tracking Requested - why for this release]: Marking tracking as this is something that could help a lot in the perceived performance of Firefox Quantum. Not sure if we still have enough time to come up with tweaks for these prefs though. If it's too late we should mark 57 wontfix.

Comment 15

[Sylvestre Ledru [:Sylvestre]]

We should run some a/b testing experiments to understand that better but it is indeed probably too late for 57.

Comment 16

[Jet Villegas (inactive)]

Following up on this one. The ScrollAnimationMSDPhysics code that this disabled feature depends on is currently shipping. Let's enable this feature or remove the untested code.

Asa: in comment 1, you were considering a pref-flip study. Do you have everything you need for that?

Comment 17

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

I would _love it_ if we finally did something about scrolling!

Harald was going to run a study about this but then got re-assigned to devtools.
From speaking with mstange a while ago, I got the impression that the new Edge-like physics aren't ready for prime-time yet (and that they would only work for touch interactions anyway).

Last year, I did some desk research and experimentation with our scroll parameters, and I'm confident that we can improve the perceived performance of scrolling by just tweaking some of our existing prefs.

Here's a summary of the proposed changes:
https://docs.google.com/document/d/1OCSQ_B_ukScIeSrgoIRzaWgs3Aa8Q7Y8woCtlwRwDRM/edit
This has been tested with a variety of different input devices and hardware configurations.

Since it doesn't look like we are getting any traction on a study, I suggest to land some of these pref changes in Nightly. It would be an improvement by every heuristic I can think of. If we want to measure the effects in a more exact manner, we could do a reverse study.

These are the proposed changes:
general.smoothScroll.mouseWheel.durationMaxMS : 200
general.smoothScroll.mouseWheel.durationMinMS : 50
general.smoothScroll.pages.durationMaxMS : 200
general.smoothScroll.pages.durationMinMS : 100
mousewheel.default.delta_multiplier_y : 200

Comment 18

[Asa Dotzler [:asa]]

No study ever happened. Sorry. I like the idea of making the obvious scroll improvements :phlsa is suggesting. Harald, what do you think? Should we try to get a study? Perhaps between what we have now and phlsa's suggested changes? Or can we just make the changes and watch for feedback as it rides the trains?

Comment 19

[Kartikaya Gupta (email:[e-mail])]

I'm going to move this to Firefox since it's not actionable in platform at the moment. We need somebody with decision-making authority to decide if the prefs need flipping and if so, to what values.

Comment 20

[Asif Youssuff]

FWIW, I tried the settings in comment 17 along with enabling general.smoothScroll.msdPhysics.enabled, and I would bet that a study would show that most users prefer the new settings.

Comment 21

[:Harald Kirschner :digitarald]

Dominik, fyi, something to discuss for future project; to lead the study here as this is in the backlog for way too long.

Comment 22

[Ryan Hunt [:rhunt] (on leave until early May)]

Attachment: wheel-scroll-settings.patch

Comment 23

[Ryan Hunt [:rhunt] (on leave until early May)]

It feels like some of the deadlock here is because we don't have any objective measure for what an improved scrolling speed is, so some users may object strongly to us changing their scroll speeds.

That could be addressed by a study certainly, but what if we added a wheel scroll speed preference that would interpolate our scroll prefs individually between known good speeds? For example, 25% could be Gecko today, and 75% could be the speeds Phillipp recommended.

We could then make changes in nightly, and users would be able to adjust their scroll speeds to their liking. We can still do a study later in beta if desired, but this might help us get this moving forward.

I wrote up a simple patch to add this, along with a setting in about:preferences to modify it. The user experience could use some work, but the functionality seems to work well.

Comment 24

[Asif Youssuff]

Are there bugs for matching platform/OS scroll speeds - because that might be simpler to get released and have an objective measure to match against. For example, if Firefox matched Safari in macOS and GNOME Web in Ubuntu (for example). That way, Firefox feels more integrated with the platform. 

I know bug 1124108 exists for macOS for a small part of that kind of platform integration, but I think the question bears asking - should Firefox really have its own smooth scroll implementation when the platform apps provide their own standard behavior? Perhaps it made sense when Firefox first implemented this, and platforms didn't have this built in, but it seems like they do today.

Comment 25

[Asif Youssuff]

FWIW, I just tested on macOS, and using the settings in the Accessibility system preferences to increase or decrease scroll speed, along with disabling or enabling inertia scroll seems to work. So there is already some native integration going on in Firefox (at least on macOS).

Comment 26

[Ryan Hunt [:rhunt] (on leave until early May)]

(In reply to Asif Youssuff from comment #24)
> Are there bugs for matching platform/OS scroll speeds - because that might
> be simpler to get released and have an objective measure to match against.
> For example, if Firefox matched Safari in macOS and GNOME Web in Ubuntu (for
> example). That way, Firefox feels more integrated with the platform. 
> 
> I know bug 1124108 exists for macOS for a small part of that kind of
> platform integration, but I think the question bears asking - should Firefox
> really have its own smooth scroll implementation when the platform apps
> provide their own standard behavior? Perhaps it made sense when Firefox
> first implemented this, and platforms didn't have this built in, but it
> seems like they do today.

That's a good point. I don't know the full history of wheel scrolling support, and it seems platform specific. (I think some relevant bugs are bug 206438 and bug 737758)

From comparing browsers on OSX again, it seems like everyone has basically the same sensitivity. Windows is a very different story, there we are easily the slowest between Chrome and Edge. So maybe this is just a platform issue for Windows.

Unfortunately I cannot test Linux because my Fedora machine just updated, and I think it's bricked.

Comment 27

[:Dominik Strohmeier [:dstrohmeier]]

One issue with scrolling is that it's a combination of different prefs that feed into the user's scrolling experience. So, not only is it hard to have an objective measure of improved scrolling - and I don't even know if that exists. It's also hard for the user to come up with an easy tuning because of the multi-pref dependency.

What if we define three pre-defined options (at least for Win) that are easy to understand for users (slow, fast, medium or light, mid, heavy) and hide different combinations of prefs behind them. I think this is a similar approach than what Ryan suggested in comment #23.

Comment 28

[Botond Ballo [:botond]]

(In reply to Asif Youssuff from comment #24)
> I know bug 1124108 exists for macOS for a small part of that kind of
> platform integration, but I think the question bears asking - should Firefox
> really have its own smooth scroll implementation when the platform apps
> provide their own standard behavior? Perhaps it made sense when Firefox
> first implemented this, and platforms didn't have this built in, but it
> seems like they do today.

Matching the platform behaviour (at least by default) is generally the goal, yes.

However, there often isn't a mechanism for Firefox to hook into the actual platform implementation for things like smooth scroll physics and rubber-banding. Apps built using the platform's native widget toolkit can do that, but web content is rendered by Firefox "from scratch" (the pixels, including scrollable content and scrollbars, are drawn using Firefox's rendering engine, without going through platform widget toolkits). As a result, Firefox needs to reimplement things like rubber-banding and try to replicate the platform behaviour to achieve matching behaviour.

Comment 29

[Ryan Hunt [:rhunt] (on leave until early May)]

Okay, I took a closer look at how the browser engines on Windows handle wheel scrolls. Here's a google doc with some results [1] and a test that I used to generate the results [2].

To summarize, every browser is handling it different. All browsers respect the system scroll lines setting, but others adjust it.

The baseline is opening Notepad and adding 10k numbered lines. With a system setting of 'scroll 9 lines per click', notepad will scroll 9 lines.

Firefox behaves close to this and will report wheel events with lineDelta = 9, but seems to slightly undershoot the reported 9 lines per scroll.

Edge opts to report wheel events with pixel deltas using some adjustment. Doubling the system scroll line setting will double the pixel delta. Edge will also scale the scroll delta based on the height of the content area. So shrinking the window will make each scroll less. I haven't tried to correlate the exact weights yet. Edge also will undershoot the reported deltas. For pixelDelta=X, they will scroll by (2/3)X. In practice when maximized, Edge seems to scroll the most per click.

Chrome also opts to report wheel events with pixel deltas. It looks like the formula is (systemScrollLines/2)*100. So for systemScrollLines=9, Chrome will report pixelDelta=450. They also undershoot the reported pixelDelta by 2/3, for a final scroll delta of 300 pixels. Not sure why that is. Chrome doesn't adjust the scroll speed for the content area height. In practice, Chrome scrolls the second most per click.

[1] https://docs.google.com/spreadsheets/d/1J6EveEwT_II_jJtcOr7ywwCoydSH4A5WCwygiKIBR8k/edit?usp=sharing
[2] https://eqrion.github.io/scrolling/wheel-test.html

Comment 30

[Gary [:streetwolf52]]

This bug report caught my interest.  I recently started using a BenQ 32 inch monitor running at 3840x2160 (4K). My OS DPI is set at 200% to improve readability.  Before my new monitor I was using a 24 inch 1920x1200 monitor with an OS DPI of 125%.  I changed some prefs to make scrolling very smooth.  However I immediately noticed that smooth scrolling on my 4K monitor produced a stutter as I scrolled. Try as I may I haven't been able to get rid of the stutter by changing various prefs.  Turning off smooth scrolling does fix the problem at the expense of not being able to smooth scroll.  I tried the prefs proposed in this bug report and it did seem to help but it is more akin to turning off smooth scroll.

I was wondering if 4K and higher monitors running at a high OS DPI require different pref values or perhaps some other changes in order to scroll smoothly.

Comment 31

[:Harald Kirschner :digitarald]

Related, Edge's scroll tweaks to make Chrome's scroll inertia aligned to the native Windows behavior: https://docs.google.com/document/d/1edEPhXDp0Sp8NAVpTf6hKkDiZAcWo2IqF-wyk8T9kCk/edit

Comment 32

[Haik Aftandilian [:haik]]

(In reply to Ryan Hunt [:rhunt] from comment #26)

From comparing browsers on OSX again, it seems like everyone has basically
the same sensitivity. Windows is a very different story, there we are easily
the slowest between Chrome and Edge. So maybe this is just a platform issue
for Windows.

There's definitely a scroll speed difference on macOS between Chrome and Firefox too. I tested on a a 2018 and a 2012 MacBook Pro using a Logitech M310 mouse and found Firefox scrolls more slowly than Chrome. After using Chrome on a scroll-heavy page, switching to Firefox feels sluggish. After changing these prefs, Firefox feels just as fast.

general.smoothScroll.mouseWheel.durationMaxMS = 200
general.smoothScroll.mouseWheel.durationMinMS = 100
mousewheel.acceleration.factor = 4
mousewheel.acceleration.start = 1

Comment 33

[Daniel Holbert [:dholbert]]

harald, do still you think we might want to do a study here? (per comment 17)

Seems like we might just want to align with the native platform behavior (per comment 31 and 32). Anyway, feels p3 from a QF perspective.

Comment 34

[:Harald Kirschner :digitarald]

Forwarding to Eric. FWIF, native behavior seems also most reasonable to me as it matches user expectations. Edge is also going that route for Chromium.

Comment 35

[esmyth]

This is on the perf team's radar for 2020. We also have it P3.

Comment 36

[Kartikaya Gupta (email:[e-mail])]

I'm going to take another look at this and try to land something. Not gonna bother with studies this time!

Comment 37

[Kartikaya Gupta (email:[e-mail])]

I wrote up some details in bug 1418822 comment 32 and landed a patch for the mousewheel duration times which it seems (from previous comments) everybody agrees is an improvement. I have another change planned for the mousewheel acceleration prefs, but that will need to wait until we have direct manipulation turned on so that precision trackpads don't become uncontrollable. I guess I'll just use this bug for that patch.

Comment 38

[Kartikaya Gupta (email:[e-mail])]

Upon further consideration turning on the mousewheel acceleration by default might not be a good idea, because apparently some mouse drivers have their own acceleration and it's hard to detect that. Users end up getting double-accelerated which makes scrolling hard to control.

The patch on bug 1418822 addresses the concerns that this bug was originally filed for (and I probably should have landed that patch as part of this bug, my mistake) so I'm going to dupe this over. I've also filed bug 1659784 for further tuning of the mousewheel distance per tick.