1856196 - Smooth scrolling option resets after each update

Status: RESOLVED FIXED

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

Description

[michelesr]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/118.0

Steps to reproduce:

Update Firefox to the next stable release.

Actual results:

The "Use smooth scrolling option" reset to "enabled"

Expected results:

The option should have remained unchanged.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Panning and Zooming' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:botond, could you have a look please?

For more information, please visit BugBot documentation.

Comment 3

[Botond Ballo [:botond]]

Do you have Firefox Sync enabled (and maybe have smooth scrolling enabled on another device where you use Firefox)? If so, I'd say this is likely a duplicate of bug 1851024.

Comment 4

[michelesr]

(In reply to Botond Ballo [:botond] from comment #3)

Do you have Firefox Sync enabled (and maybe have smooth scrolling enabled on another device where you use Firefox)? If so, I'd say this is likely a duplicate of bug 1851024.

No, I don't use Firefox Sync.

Comment 5

[Botond Ballo [:botond]]

Ok; could you go to about:config, type in general.smoothScroll into the search field, and for the row corresponding to this pref, check:

• what is the current value (true or false)?
• is the row bolded (indicating a non-default value)?

Comment 6

[michelesr]

(In reply to Botond Ballo [:botond] from comment #5)

Ok; could you go to about:config, type in general.smoothScroll into the search field, and for the row corresponding to this pref, check:

• what is the current value (true or false)?
• is the row bolded (indicating a non-default value)?

The value is false and not bolded (so it's set as the default)

Comment 7

[Botond Ballo [:botond]]

Ok, so I believe that tells us that:

• your OS's "prefers reduced motion" setting is enabled (if you're on Linux, that translates to gtk-enable-animations being false)
• Firefox successfully sets the default value of general.smoothScroll to false based on this

Adding to that, based on the info in the comment 0:

• after you upgraded, the setting's value was true (and therefore not the default)
• before the upgrade, the setting's value was presumably false
  • this may or may not have been the default in the older Firefox version, since our method of computing the default changed recently to start taking "prefers reduced motion" into account

The relevant recent changes are:

• bug 1753565, which starting in Firefox 114 changed the default value of general.smoothScroll to take into account "prefers reduced motion", rather than the default always being true
• bug 1830103, which added a check when upgrading from 113 or earlier to 114 or later, to catch the case where the default changes from true to false but the pref value wasn't customized, and set a non-default value of true (to avoid the upgrade causing a silent pref change)

I can't think of a way these changes would cause the observed behaviour (in particular, if you were upgrading from 113 or earlier, and the old value of general.smoothScroll was false, that was not the default in the old version and thus the pref must have been customized to false, and so the check in bug 1830103 should not have fired).

cc'ing Dan who worked on the mentioned bugs, in case he has any theories.

Hopefully this was just a one-off, and future upgrades leave the pref value alone.

Comment 8

[michelesr]

If you refer to the dconf setting /org/gnome/desktop/interface/enable-animations that is indeed set to false (I'm not really using gnome so maybe that's not the right path). I've seen this behavior repeating different times during upgrade (at the very least 2 times, but probably even more than 3, sorry I can't remember exactly).

Comment 9

[Botond Ballo [:botond]]

(In reply to michelesr from comment #8)

I've seen this behavior repeating different times during upgrade (at the very least 2 times, but probably even more than 3, sorry I can't remember exactly).

Interesting; I think that rules out bug 1830103 being the culprit, because this branch should only be taken during one upgrade (the first one to version 114 or later), and not subsequent ones.

But I also don't see how bug 1753565 can be the culprit because it only changes the default value; presumably, when you experience this after an upgrade, the pref value is changed to the non-default value of true. (Just to confirm this, the next time this happens, it would be helpful if you could go to about:config and check that the pref's row now is bolded (and with value true), before you change it back to false.)

Comment 10

[michelesr]

I'm using Firejail to sandbox the browser, and this could interfere with the ability of Firefox to get the system value for the "disable animation" settings (for example running dconf-editor from the sandbox returns an error where the dbus interface is not available) ... is there a way to check exactly the value that is read by Firefox, e.g. by enabling some specific logging environment variable?

Comment 11

[michelesr]

Actually, using the browser console, I can see that Services.appinfo.prefersReducedMotion returns true, so Firefox should be aware that I don't want smooth scrolling.

Comment 12

[michelesr]

It happened again after updating to 119.0, the value of general.smoothScroll is true and not bolded.

Services.appinfo.prefersReducedMotion returns false in the browser console.

Comment 13

[michelesr]

Very strange, I've toggled the value from about:config to false and then back to the default (true). I've restarted Firefox and now Services.appinfo.prefersReducedMotion returns true and the general.smoothScroll option changed back to being set to false and false being the default. Unfortunately I'm unable to determine whether restarting Firefox was sufficient or it was the toggling to false and then back to the default (true) that determined the change in behavior (defaulting again to false) after the restart.

Comment 14

[Botond Ballo [:botond]]

Thanks, the updates in comment 12 and comment 13 are quite interesting!

They suggest that the default value of general.smoothScroll is tracking (the negation of) Services.appinfo.prefersReducedMotion as expected, but the value of Services.appinfo.prefersReducedMotion is sometimes unexpectedly false, in spite of you (presumably) not changing your system setting.

I'm unsure whether this is a result of a Firefox bug (e.g. a race between code that checks the prefersReducedMotion setting and code that populates that value based on the system setting), or something external (e.g. the query for the system setting itself sometimes returning false, perhaps related to the Firejail setup?)

In any case, it does tell us this is a regression from bug 1753565 which introduced the business of the default value of smoothScroll depending on the system setting to begin with.

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

:dlrobertson, since you are the author of the regressor, bug 1753565, could you take a look?

For more information, please visit BugBot documentation.

Comment 16

[Botond Ballo [:botond]]

The fact that we don't call EnsureInit() in this block looks suspicious.

Comment 17

[Dan Robertson (:dlrobertson)]

(In reply to Botond Ballo [:botond] from comment #16)

The fact that we don't call EnsureInit() in this block looks suspicious.

That seems to largely deal with populating system color settings, but it could be the issue. I'll continue to dig into this a bit.

Comment 18

[Botond Ballo [:botond]]

EnsureInit() calls Initialize() which calls InitializeGlobalSettings() which sets mPrefersReducedMotion. It seems important to make sure that runs before we read mPrefersReducedMotion.

Comment 19

[Dan Robertson (:dlrobertson)]

Aha! You're right. I was looking at the Windows version of EnsureInit here were it looks like Initialize may not be called if we're not initialized yet. I do wonder if we need to call Initialize there as well.

Comment 20

[Botond Ballo [:botond]]

(In reply to Dan Robertson (:dlrobertson) from comment #19)

Aha! You're right. I was looking at the Windows version of EnsureInit here were it looks like Initialize may not be called if we're not initialized yet. I do wonder if we need to call Initialize there as well.

I'm only seeting a method named Initialize() in the GTK version of nsLookAndFeel.

Comment 21

[Dan Robertson (:dlrobertson)]

Right again! I looked through the other implementations and the gtk implementation of look and feel is the only one that uses an initialization function to populate the value.

Comment 22

[Dan Robertson (:dlrobertson)]

Attachment: Bug 1856196 - prefers-reduced-motion look and feel settings are initialized on linux. r=botond

Ensure that the look and feel settings are initialized on linux before
returning prefers-reduced-motion settings are evaluated.

Comment 23

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1753565

Comment 24

[michelesr]

It happened again after updating some packages (but not Firefox) in the system and rebooting. The first time I've started Firefox it had smooth scrolling enabled, I just closed it and opened it again and this time it was disabled again.

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d9499582f464
prefers-reduced-motion look and feel settings are initialized on linux. r=botond

Comment 26

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/d9499582f464

Comment 27

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:dlrobertson, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox120 to wontfix.

For more information, please visit BugBot documentation.

Comment 28

[Dan Robertson (:dlrobertson)]

Attachment: Bug 1856196 - prefers-reduced-motion look and feel settings are initialized on linux.

The prefers-reduced-motion settings must be initialized before the value
is requested. If EnsureInit() has not been called before the
prefers-reduced-motion value is evaluated, we may return an unexpected
value of false.

Original Revision: https://phabricator.services.mozilla.com/D192475

Comment 29

[Phabricator Automation]

Uplift Approval Request

• Steps to reproduce for manual QE testing: Have the prefers-reduced-motion system setting set. Update firefox and ensure that smooth scrolling is disabled.
• String changes made/needed: No
• Needs manual QE test: no
• Explanation of risk level: Fixes a fairly obvious error and only impacts value initialization of a user preference on Linux.
• Fix verified in Nightly: no
• User impact if declined: Smooth scrolling user setting may reset on update
• Risk associated with taking this patch: Minimal
• Code covered by automated testing: no
• Is Android affected?: no

Comment 30

[Dianna Smith [:diannaS]]

Comment on attachment 9362820 [details]
Bug 1856196 - prefers-reduced-motion look and feel settings are initialized on linux.

Approved for 120.0b9

Comment 31

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/03a9bf50f31d