Closed Bug 1928570 Opened 1 year ago Closed 1 year ago

Smooth scrolling option is overridden by Resist Fingerprinting

Categories

(Core :: Panning and Zooming, defect)

Product:
Core
Component:
Panning and Zooming
Version:
Firefox 132
Platform:
Desktop
All
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: hackerpcs, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Steps to reproduce:

Firefox automatically updated to v132.0. To work around the issue, I had to downgrade to 131.0.3, disable updates via group policy (HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Mozilla\Firefox\\DisableAppUpdate=1) and launch Firefox 131.0.3 with "--allow-downgrade" to use my old profile and then on 131.0.3 it works as it should turning it on/off.

This was reported by another user too
https://forums.mozillazine.org/viewtopic.php?t=3126194

It does NOT happen on a clean profile ("%AppData%/Mozilla" folder renamed/moved), only on existing profiles

Actual results:

I noticed that smooth scrolling is on even though it's off in settings

Expected results:

Smooth scrolling should be turned off when the option is off.

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.

Component: Untriaged → Panning and Zooming
Product: Firefox → Core

Given that we've already cut off the relationship between Firefox Sync and the smooth scroll pref since Firefox 131 (bug 1851024), so Sync is unrelated I think.

Given that the issue happens on upgrading Firefox, there still remains an issue regressed by bug 1830103? Though I have no idea why it appeared on Firefox 132 upgrade. CCing Dan.

Or maybe Windows 11 24H2 update somehow changed the prefers-reduced-motion setting?

OS: Unspecified → Windows
Hardware: Unspecified → Desktop

It happened on a second different PC, both on Windows 10 22h2 (non-LTSC, general release) and I've never used Sync on both

As user De52A found out, the problematic setting is "general.smoothScroll.mouseWheel"
https://forums.mozillazine.org/viewtopic.php?p=14987105#p14987105
if set to false, on v132.0 smooth scrolling is disabled (what I want and a workaround for me to use v132.0), what seems to be the problem is that "general.smoothScroll" ("Use smooth scrolling" on Settings UI) is ineffective, if set to false it doesn't disable smooth scrolling in general like it should and does in 131.0.3, it doesn't do anything.

All other general.smoothScroll.* for me are default and user.js removed or present doesn't fix the problem

Hey all, I'm De52A from MozillaZine, I just discovered another preference affected, it's general.smoothScroll.pages if set to false disables smoothscorlling in page up, page down, home and end buttons. On a non buggy profile disabling smooth scrolling disables it entirely, on a buggy profile individual preferences in about:config has to be modified in order to disable it.

Please, if you're able to test this, disable smooth scrolling in preferences (or general.smoothScroll in about:config), if the profile's buggy, it won't be disabled, if it's not buggy. it will be disabled properly.

Somebody else pointed out that https://bugzilla.mozilla.org/show_bug.cgi?id=1927094 might be related to this but I'm not entirely sure.

I'm affected by this on Ubuntu 20.04 (Firefox package from the Ubuntu repo), so this doesn't appear Windows-related. After the upgrade to firefox-132.0+build1-0ubuntu0.20.04.1, mouse wheel smooth scroll appeared again despite being disabled in settings, and toggling the setting does not have any effect.
I can confirm that setting general.smoothScroll.mouseWheel to false disables smooth scrolling for me.
In case it's relevant, I launch Firefox using env -uGDK_CORE_DEVICE_EVENTS MOZ_USE_XINPUT2=1 firefox and am on XFCE.

I forgot to add modifying general.smoothScroll.other to false disabled it in home and end buttons too. Also, thank you Samuel, finally we're not alone! :D

I did a quick check of this on Linux:

For me, scrolling was still instant (i.e. smooth scrolling is disabled) after the upgrade. So there's something more to it needed to trigger the issue that we need to figure out to reproduce.

OS: Windows → All

See also bug 1912246 for a similar report in an earlier version.

See Also: → 1912246

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

I did a quick check of this on Linux:

For me, scrolling was still instant (i.e. smooth scrolling is disabled) after the upgrade. So there's something more to it needed to trigger the issue that we need to figure out to reproduce.

Hi! Thanks for testing this. Do you have multiple computers? Multiple VMs? Multiple operating systems? For me it happened on a Windows 11 computer, NOT on my mum's 14 year old laptop. Could it be the operating system? I've also a heavily modified (privacy settings mostly) Firefox profile. Could it be addons? I've Ublock Origin, NoScript, LocalCDN (to thwart the content delivery network spying) ClearURLs (to remove URL tracking code) just to name a few. Could it be the graphics adapter? I have an Intel integrated UHD 620, mum's is an ancient (by now) hybrid graphics system Intel/ATI Radeon (5000 mobility series if I remember correctly) something graphics. Did you test it on Windows 11? Then we could perhaps rule out the operating system I think, at least Windows 11.

Oops, I somehow missed posting below comment yesterday.

Can you guys post your about:support result?

general.smoothScroll.mouseWheel or general.smoothScroll.pages is used only in a few place in our code. With general.smoothScroll=false, those prefs should never cause smooth scrolling (unless you guys enable resist finger printing). So I wonder there's some addons are related or not.

As per comment 10, it looks like finger print settings are somewhat related?

See Also: → 1832598
See Also: → 1928161

(In reply to Hiroyuki Ikezoe (:hiro) from comment #11)

general.smoothScroll.mouseWheel or general.smoothScroll.pages is used only in a few place in our code. With general.smoothScroll=false, those prefs should never cause smooth scrolling (unless you guys enable resist finger printing).

This is it, privacy.resistFingerprinting set to true (which I have) makes smooth scrolling force-enabled disregarding the general.smoothScroll setting, I can confirm it with a new profile. Good thing is that the rest of the settings set to false

general.smoothScroll.mouseWheel
general.smoothScroll.other
general.smoothScroll.pages
general.smoothScroll.pixels
general.smoothScroll.scrollbars

makes the smooth scrolling disabled even if privacy.resistFingerprinting is set to true.

Thanks for the info.

So it looks like this is a regression from bug 1834307? It's in v132.

Keywords: regression
Regressed by: 1834307

:fkilic, since you are the author of the regressor, bug 1834307, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Flags: needinfo?(fkilic)

As per comment#2,

Ideally, for us, the patch would ignore all prefs and OS settings and just enforce smooth scroll, period. Maybe we can do that here with all but the UI pref, and TB can just lock/set that (we plan to make about:config interstitial sticky and scary with warnings/info)

I'm not sure how we should fix this, this is expected by RFP.

Flags: needinfo?(fkilic)

The Resist Fingerprinting mode does override many settings of the browser, including Smooth Scroll (and other accessibility-related preferences.) This is by design, and one of the reasons why Mozilla/Firefox does not recommend using Resist Fingerprinting, and why it is an about:config setting and not exposed via Browser Settings/Preferences. More details are available at https://support.mozilla.org/en-US/kb/resist-fingerprinting

Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Resolution: --- → INVALID
Summary: Smooth scrolling option is broken on 132.0 for existing profiles → Smooth scrolling option is overridden by Resist Fingerprinting
Duplicate of this bug: 1937881
Duplicate of this bug: 1974418
You need to log in before you can comment on or make changes to this bug.