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.
I was considering this for a pref flipping study. It would be pretty easy to get some user feedback on it that way.
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.
(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.
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
(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).
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?
(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.
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.
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.
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.
(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.
(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.
I haven't checked. But I've heard from many people that Edge's scrolling experience is regarded as superior.
[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.
status-firefox55: --- → wontfix
status-firefox56: --- → wontfix
status-firefox57: --- → affected
tracking-firefox57: --- → ?
We should run some a/b testing experiments to understand that better but it is indeed probably too late for 57.
status-firefox57: affected → fix-optional
tracking-firefox57: ? → -
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?
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
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?
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.
Component: Panning and Zooming → General
Priority: P3 → --
Product: Core → Firefox
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.
Dominik, fyi, something to discuss for future project; to lead the study here as this is in the backlog for way too long.
Flags: needinfo?(hkirschner) → needinfo?(dstrohmeier)
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.
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.
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).
(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.
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.
(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.
Okay, I took a closer look at how the browser engines on Windows handle wheel scrolls. Here's a google doc with some results  and a test that I used to generate the results . 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.  https://docs.google.com/spreadsheets/d/1J6EveEwT_II_jJtcOr7ywwCoydSH4A5WCwygiKIBR8k/edit?usp=sharing  https://eqrion.github.io/scrolling/wheel-test.html
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.
You need to log in before you can comment on or make changes to this bug.