Mouse wheel scrolling is not smooth when slowly rolling mousewheel
Categories
(Core :: Panning and Zooming, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox-esr78 | --- | unaffected |
firefox79 | --- | unaffected |
firefox80 | --- | unaffected |
firefox81 | + | fixed |
People
(Reporter: alice0775, Assigned: kats)
References
(Regression)
Details
(Keywords: nightly-community, regression)
Attachments
(1 file)
Reproducible: always
Steps to reproduce:
- Open any long page
e.g, https://en.wikipedia.org/wiki/Wikipedia - Attempt to scroll with mouse wheel
Actual Results:
Scrolling is jerky(moving like a measuring worm) when I turned mouse wheel slowly relatively.
Expected results:
Scrolling is smooth, fluently.
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=7e5f806e44a8d35de67bf4ea3e9060836bcf440d&tochange=39fd3e407dbab97068bb1b8254d74e70ce82d8e5
Assignee | ||
Comment 1•4 years ago
|
||
Thanks. I'd be interested to know if you get used to the new behaviour or if it still bothers you after a day or two.
Assignee | ||
Updated•4 years ago
|
Reporter | ||
Comment 2•4 years ago
|
||
Screencast:
After landing bug 1418822: https://youtu.be/zMvxCE9w84E
Before landing Bug 1418822: https://youtu.be/3MOkGalxu7w
Assignee | ||
Comment 3•4 years ago
|
||
Thanks. It makes sense that if you are scrolling the mousewheel every 200ms or so, then with the old prefs the new wheel event would come in while the old animation was still going, and so it would end up extending the animation to the new destination, making it appear more smooth. With the new prefs the first animation completes before you the second wheel event comes in, so there's a bunch of start-stop behaviour. I can see this would appear to be a regression with slow scrolling.
From #layout, Itiel (who also noticed the change in scroll behaviour) says:
I'm sure I'll be able to live with it. The issue I'm having now (maybe until I'll get used to it...) is that when I'm reading a paragraph and scrolling, I'm losing focus as to where I stopped reading, causing me to look again where I should continue
If after a day or two you still feel like it's jarring I can try to implement a fix where the animation starts off slow but then speeds up if you do a lot of wheel events in quick succession. That might help refine the behaviour so that slow and fast scrolling both work well. But each additional change increases the risk that something else will break, so I'd like to avoid that if possible.
Comment 4•4 years ago
|
||
Add me to those that would like to see the fix you mentioned. Scrolling is noticeably worse. I'm using all the default prefs that control smooth scrolling.
Assignee | ||
Comment 6•4 years ago
|
||
[Tracking Requested - why for this release]: I made a change to the feel of mousewheel scrolling in bug 1418822 based on previous discussions and UX suggestions, but it seems that some people don't like it. I'm going to try and find a middle ground that addresses the concerns but we should track this as a possible regression for now.
Updated•4 years ago
|
Assignee | ||
Comment 7•4 years ago
|
||
For those who don't like the new setting: can you also try setting general.smoothScroll.mouseWheel.durationMinMS
to 100 or 150 and see if that makes it feel acceptable? Other line-scrolling methods (down arrow on scrollarbar, or down button on keyboard) use a 150ms animation so if we made the mousewheel match that it might seem more reasonable.
Reporter | ||
Comment 8•4 years ago
|
||
I prefer
general.smoothScroll.mouseWheel.durationMaxMS; 300 or 350
general.smoothScroll.mouseWheel.durationMinMS"; 10
Assignee | ||
Comment 9•4 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #3)
I can try to implement a fix where the animation starts off slow but then speeds up if you do a lot of wheel events in quick succession
Turns out this is what the existing code already does, although slightly differently from what I had in mind. Bumping the maxMS value up to 300 might be the best compromise then. I'll wait a few more days and see if we do or don't get complaints from Beta users too.
Comment 10•4 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #9)
I'll wait a few more days and see if we do or don't get complaints from Beta users too.
I assume this reads as "we don't know yet what severity this has". ni'ing you as reminder. Thanks!
Assignee | ||
Comment 11•4 years ago
|
||
I can mark it S2 for now and park it with me. Might end up being a wontfix, or a small tweak to the prefs.
Assignee | ||
Comment 12•4 years ago
|
||
After some discussion it looks like we might be able to get some support from the data team to run an experiment and see how users respond to this. I talked with Bas and we came up with some concrete things we can try. So I'm going to revert the change for now.
Assignee | ||
Comment 13•4 years ago
|
||
This undoes the change in bug 1418822 as it's not clear if it's a strict
improvement. We have concrete plans to do some experimentation to at least
ensure it won't drive away users.
Comment 14•4 years ago
|
||
Comment 15•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Description
•