Closed Bug 1659784 Opened 4 years ago Closed 4 years ago

Mouse wheel scrolling is not smooth when slowly rolling mousewheel

Categories

(Core :: Panning and Zooming, defect, P2)

Firefox 81
Desktop
Windows 10
defect

Tracking

()

RESOLVED FIXED
81 Branch
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:

  1. Open any long page
    e.g, https://en.wikipedia.org/wiki/Wikipedia
  2. 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

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.

Component: Layout: Scrolling and Overflow → Panning and Zooming
Summary: Mouse wheel scrolling is not smooth → Mouse wheel scrolling is not smooth when slowly rolling mousewheel

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.

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.

[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.

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.

I prefer
general.smoothScroll.mouseWheel.durationMaxMS; 300 or 350
general.smoothScroll.mouseWheel.durationMinMS"; 10

(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.

(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!

Flags: needinfo?(kats)

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: nobody → kats
Severity: -- → S2
Flags: needinfo?(kats)
Priority: -- → P2

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.

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.

Pushed by kgupta@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b6b562c539e3
Revert the speedup of mousewheel animations. r=jaws
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 81 Branch
Blocks: 1669894
No longer blocks: 1669894
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: