1660933 - Speed up wheel animation for new users and allow gradual migration for existing users

Status: RESOLVED FIXED

(Core :: Panning and Zooming, task)

Description

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

Recently I landed a patch in bug 1418822 that sped up the mousewheel animation. We don't have any formal way of measuring the impact of this, but anecdotally the feedback I got was positive. There were, however, some users who found this resulted in more jumpy-feeling scrolling which interfered with trying to read content while scrolling slowly (bug 1659784 and dupes).

As a result of this feedback, I backed out the changes to figure out a better way forward. I also discussed the situation with Bas who represented some members of the perf/data science teams and we agreed to try to make this change more data-driven.

However, it turns out that right now it's hard/impossible to do A/B experimentation because trying to follow the shield study steps leads to dead ends (can't get a data scientist assigned because the bugzilla component is closed). So in this bug I'm proposing a way to make this change that hopefully meets all the constraints (listed below) and can proceed even without support from the data science team. If they find resources to help then this plan could certainly benefit from their involvement in terms of doing A/B tests to measure retention.

The main goals here are:

1. Bring our scrolling behaviour more in line with other browsers, so that people trying Firefox from Chrome or Edge don't feel like Firefox's scrolling is too slow in comparison. Ideally this will boost our new user retention rate.
2. Avoid alienating our existing users by drastically changing the scrolling behaviour from what they're used to. Scrolling experience is quite subjective, and while our existing users might like the new behaviour, the sudden change from one release to the next can only hurt us (in the absence of action on our part, presumably they would remain Firefox users).

So the combination of these two goals suggests that we should only change the animation speed for new users, and leave the existing animation speed for existing users.

However, if it turns out that the new animation speed is well-received, we will want to consider migrating our existing users to the new animation speed, so that they too can enjoy better scrolling. Instead of doing this in one go, I propose gradually adjusting the value over a period of a few releases, so that each incremental change is not jarring, but by the end of the migration, their scrolling experience will be the same as a new user. And of course, if the users have modified the prefs manually, then we should respect that.

I have a WIP patch that should accomplish this, that I'll clean up and test a bit before posting.

Comment 1

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

Attachment: Bug 1660933 - Update default mousewheel animation durations. r?jaws

Also detect existing users and carry forward their customizations if needed.
If no customization was done, we set a pref to indicate they should remain
at their old defaults, which we can gradually migrate to the new values.

Comment 2

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

Attachment: Bug 1660933 - Respect wheel migration value. r?botond

This introduces a linear interpolation when computing the wheel animation
durations, based on the migration percentage of the user. Initially the
migration percentage defaults to 100 (fully migrated) for new users and for
existing users who have customized these prefs. The migration percentage
defaults to zero for existing users without customizations, so they will
still get the old default values of min=200,max=400. Over time we can adjust
the migration pref clamping to move that percentage up and migrate those
users to get the new values.

Depends on D88162

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cd543a0b85c4
Update default mousewheel animation durations. r=jaws
https://hg.mozilla.org/integration/autoland/rev/dcfb243788f7
Respect wheel migration value. r=botond

Comment 4

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/cd543a0b85c4
https://hg.mozilla.org/mozilla-central/rev/dcfb243788f7

Comment 5

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

Comment on attachment 9171949 [details]
Bug 1660933 - Update default mousewheel animation durations. r?jaws

Beta/Release Uplift Approval Request

• User impact if declined: New users coming to Firefox from Chrome might find Firefox scrolling to be sluggish when using a line-based scrolling device (impulse mousewheel or trackpad).

Note that there is some ongoing email discussion about including this change in the omnibus experiment for 81, but even if it's not part of the experiment I think it's worth uplifting as it likely will help retention of new users.
Also note that the patches retain the old scrolling speed for pre-existing users, so that they don't find the new behaviour jarring. Therefore there should be zero user impact for pre-existing users whether or not this patch is uplifted.

• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce:
  -- Launch the browser (with patch applied) on a new profile. Verify that mousewheel scrolling animations are fast, comparable to Chrome.
  -- Launch the browser (with patch applied) on a profile created with a build without the patch. Verify the mousehweel scrolling animations are the same as they were on the old build (should be noticeably slower than Chrome).
  -- Create a profile with a build that doesn't have the patch. Manually change the value of the general.smoothScroll.mouseWheel.durationMinMS and/or general.smoothScroll.mouseWheel.durationMaxMS prefs. Verify that when using a build with the patch, the mousewheel scroll animation speed is the same (customized) value as using the old build.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The change is fundamentally just a pref change, so pretty low risk. The second patch adds some code which is needed to retain the old behaviour for existing users/profiles, but is also pretty straightforward and low-risk.
• String changes made/needed:

Comment 6

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

Also, a note for users following along on this bug: if you have customized the mousewheel duration prefs prior to using a build with this patch, your customizations should be retained. If you customize the prefs after using a build with this patch, then you should also set the general.smoothScroll.mouseWheel.migrationPercent pref to 100, which will indicate to FF that no migration is necessary for you. Otherwise the actual animation speed will be a interpolated value between (200,400) and your customization. I couldn't think of an easy way to automatically detect this case and figured that if you're manually changing those prefs anyway then it shouldn't be a huge burden to also manually change the migrationPercent pref.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

I'd feel a lot better about taking this on Beta if we've done some validation on Nightly first. I'm also waiting on a clear signal from the email thread about this.

Comment 8

[Adrian Florinescu [:aflorinescu]]

Using the following environments:

Mac 10.14.6
Ubuntu 20.04
Windows 10

with the following hardware:

Windows - desktop PC (gaming mouse Logitech G502 - includes free scrolling)
Ubuntu - laptop (Dell G5 - with mouse Logitech Pilot + touchpad )
Mac 10.14.6 - MacBook Pro (touchpad only)

using:

• Firefox Nightly 82.0a1 2020-09-01 (old scroll)

   general.smoothScroll.mouseWheel.durationMinMS 200
   general.smoothScroll.mouseWheel.durationMaxMS 400 
  

• Firefox Nightly 82.0a1 2020-09-01 (new scroll)

  general.smoothScroll.mouseWheel.durationMinMS 50
  general.smoothScroll.mouseWheel.durationMaxMS 200
  

• Chrome Version 85.0.*

and used the following sites as testing datasheet:

https://www.google.com - 100 results per page
https://9gag.com
https://www.awwwards.com/30-great-websites-with-parallax-scrolling.html
https://upload.wikimedia.org/wikipedia/commons/2/2c/USA_New_Jersey_location_map.svg
https://www.w3.org/conf/2013sf/
https://brendaneich.com/2012/10/harmony-of-dreams-come-true/
http://chrsl.net/gospel/
https://edition.cnn.com/

I have tried to cover the following categories on each of the above site:
1. fast scrolling - mouse
2. fast scrolling - touchpad
3. slow scrolling(reading simulation) - mouse
4. slow scrolling(reading simulation) - touchpad

From the general comparison point of view, betwen old scroll and new scroll there is a visible difference in responsivness, which seems noticeably snapier: close or even on par with chrome (depeding also on the site tested on or if mouse or touchpad). There are still positive diferences when uing touchpad, but it does seem to me that they are less visible then when using a mouse.
Most visible somehow negative diference betwen Firefox with the new scrolling settings, Chrome vs the old scroll settings are in very slow scrolling + or slow free scrolling. Personally, in this area I don't like Chrome and I don't like the new scroll settings either: they do feel a bit chunkier than the old settings smoothness when going very slowly. (for example: trying to reading a text in page while slowly scrolling, seems easier with old than new scroll settings)

Overall, for new users, I think that the new scroll values have overall more pluses than drawbacks, in terms of user experience. For existing users, the old vs new settings is highly debatable and in the end depends on each prefrence.

Comment 9

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

(In reply to Adrian Florinescu [:aflorinescu] from comment #8)

Most visible somehow negative diference betwen Firefox with the new scrolling settings, Chrome vs the old scroll settings are in very slow scrolling + or slow free scrolling. Personally, in this area I don't like Chrome and I don't like the new scroll settings either: they do feel a bit chunkier than the old settings smoothness when going very slowly. (for example: trying to reading a text in page while slowly scrolling, seems easier with old than new scroll settings)

I agree that this seems to be the main complaint with the new preferences. I'm debating if we should increase the durationMaxMS value from 200 to 250 or 300 which should slow down the slow scrolls a bit. The numbers I went with were based on these UX suggestions but again that's basically one person's preference and pretty subjective.

Comment 10

[Adrian Florinescu [:aflorinescu]]

I've also tried to validate the part with new users vs old users, but I didn't quite understand the patch that is supposed to do that. What I understood was that new users would get the new values and old users will keep the old or the customizations, if they did any.

Testing on Nightly 82, with update from 81 or just an older profile, I would still get the new settings and general.smoothScroll.mouseWheel.migrationPercent - 0.

:kats, could you pretty please detail a bit more what I should be expecting here?

Comment 11

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

(In reply to Adrian Florinescu [:aflorinescu] from comment #10)

Testing on Nightly 82, with update from 81 or just an older profile, I would still get the new settings and general.smoothScroll.mouseWheel.migrationPercent - 0.

This matches the expected behaviour, assuming the profile didn't have the durations already customized. The migrationPercent being 0 means that the users will get the old behaviour. Here's a bit more detail on what I expect to see:

Scenario 1: older profile with no customizations. Run Nightly 82, you should see the new default durationMinMS and durationMaxMS values in about:config, but migrationPercent set to 0. This indicates the user has not been migrated to the new duration values, and they should still experience the older (slower) scrolling speed.

Scenario 2: older profile with durationMinMS and/or durationMaxMS customized. Run Nightly 82, you should see the same old customized durationMinMS and durationMaxMS values in about:config, but migrationPercent will now be set to 100. This indicates the user has been "migrated" to their customized values, and they should continue getting the same customized behaviour as before. Note that in this case, if only one of the duration values was customized on the old profile, the other will also become customized (i.e. show up as bold in about:config) in Nightly 82 and will retain the old default value (200 for minMS, 400 for maxMS).

Scenario 3: brand new profile with Nightly 82. In this case you should see all the new defaults: durationMinMS as 50, durationMaxMS as 200, and migrationPercent as 100. This indicates the user is "migrated" and is getting the new defaults which is faster scrolling.

Hopefully that explains things a bit better, let me know if it's still unclear!

Comment 12

[Adrian Florinescu [:aflorinescu]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #11)

Scenario 1: older profile with no customizations. Run Nightly 82, you should see the new default durationMinMS and durationMaxMS values in about:config, but migrationPercent set to 0. This indicates the user has not been migrated to the new duration values, and they should still experience the older (slower) scrolling speed.

Only on scenario 1, there is a bit of confusion. The expected result is that for users in this scenario, the durationMinMS and durationMaxMS should be 200 respectively 400 (old values). But the users get updated to the new values, with migrationpercent 0.

Steps:

1. User installs and starts with new profile 73.0a1 20200102094341
2. User updates to latest 82.0a1 20200903094553

Actual Result:

1. general.smoothScroll.mouseWheel.durationMinMS = 200;
   general.smoothScroll.mouseWheel.durationMaxMS = 400;
2. general.smoothScroll.mouseWheel.durationMinMS = 50;
   general.smoothScroll.mouseWheel.durationMaxMS = 200;
   general.smoothScroll.mouseWheel.migrationPercent = 0;

Comment 13

[Asif Youssuff]

Was this meant to change things on OSes other than Windows? I had thought that the scroll wheel performance on those places more closely aligned to those OSes, but I could definitely be wrong. Was this considered?

Comment 14

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

(In reply to Adrian Florinescu [:aflorinescu] from comment #12)

Only on scenario 1, there is a bit of confusion. The expected result is that for users in this scenario, the durationMinMS and durationMaxMS should be 200 respectively 400 (old values). But the users get updated to the new values, with migrationpercent 0.

What you're seeing here is expected. The values of durationMinMS and durationMaxMS shown in about:config will be 50 and 200 (new values). But the values actually used when scrolling will be 200 and 400 (old values), because the migrationpercent is set to 0. The old 200 and 400 values are hard-coded into the code now so they don't show up as the pref values in about:config.

Comment 15

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

(In reply to Asif Youssuff from comment #13)

Was this meant to change things on OSes other than Windows? I had thought that the scroll wheel performance on those places more closely aligned to those OSes, but I could definitely be wrong. Was this considered?

From my (admittedly brief) experimenting on macOS and Linux it seemed like Chrome's scrolling was faster than our old default, so I made the change for all platforms.

Comment 16

[Asif Youssuff]

Kartikaya, Is the correct comparison Chrome and on macOS, and not Safari? I'd also compare to GNOME Web (Epiphany Browser) on Linux. The original bug seemed to be scoped to Windows, and the platform default has changed to Chromium Edge, so matching it on Windows makes sense to me, not so much for macOS and Linux.

Comment 17

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

I did some more comparisons.

On macOS, the default scroll distance for one notch of the mousewheel is very small in all browsers, so the animation speed here doesn't make much of a noticeable difference. That being said, the new Firefox speed is closer to what Chrome/Safari do. If you roll the mousewheel multiple notches in a row, all browsers do an "acceleration" effect where the total distance scrolled is much greater than simply the sum of the individual notches. However, in this respect, Firefox applies much less "acceleration", so a "fast scroll" (5-6 notches at a time) will make FF scroll fewer pixels down the page than the other browsers. I'm not sure offhand why that it is, and might be something to look into as a separate bug.

On Linux, Epiphany feels like it doesn't have smooth scrolling at all. If it does, the animation is sufficiently short that it feels like it doesn't. So speeding up the FF animation can only bring it closer to Epiphany.

Comment 18

[Adrian Florinescu [:aflorinescu]]

Redid the upgrade scenario with migration percent 0 and 100% and taking in account comment 14, works as expected.

As a personal note, also stated in comment 8, my overall preference would be somewhere around the old scroll values, due to the fact that I probably got used to it along the way. I'm uncertain how would I feel (objectively) if I'd get automatically updated to the faster values.

All in all, taking in account comment 8 and comment 14 I think we can mark this as verified for Nightly 82.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9171949 [details]
Bug 1660933 - Update default mousewheel animation durations. r?jaws

Per the email thread, we're going to let this ride the 82 train.

Comment 20

[Adrian Florinescu [:aflorinescu]]

Please re-add the qe+ if follow-up testing is needed.

Comment 21

[Steven Penny]

I just noticed that starting with Firefox 82 (Oct 2020), this setting:

general.smoothScroll.mouseWheel.durationMinMS

was changed from 200 to 50. Now the default mouse wheel scrolling is awful. Its jerky and jumpy, just as OP said. I cant possible imagine how anyone would like this.