1834307 - Smooth scrolls are disabled if the user prefers-reduced-motion regardless of fingerprint resistance

Status: VERIFIED FIXED

(Core :: Layout: Scrolling and Overflow, defect, P3)

Description

[Dan Robertson (:dlrobertson)]

+++ This bug was initially created as a clone of Bug #1832598 +++

Summary

When privacy.resistFingerprinting is set smooth scrolling should immediately default to disabled without requiring a restart.

Steps to reproduce

0. Set prefers reduced motion or set general.smoothScroll to false
1. Set privacy.resistFingerprinting to true
2. Navigate to https://dlrobertson.com/examples/scrollinto-view-scrollend.html

Actual Results:

Both scrolls run in the script are instant

Expected Results:

Regardless of the value of prefers-reduced-motion or general.smoothScroll, we should smooth scroll for the second programmatic scroll.

Comment 1

[Fatih Kilic [:fkilic]]

This is an easy fix, but I'm not sure if this would be desirable. We are only writing to default pref branch, and if the user changed the pref, we respect it. I do agree that it adds to the user's fingerprintability, but I'm not sure how we can solve this without breaking the things for people that depend on this feature.

Comment 2

[Thorin [:thorin]]

test: https://arkenfox.github.io/TZP/tests/scroll.html

So part of the issue is RFP doesn't really protect this - I think it's set when RFP is enabled but then can get over-riden in several ways, one of which includes the UI (which is not a good fit for FF, whereas TB can remove UI elements)

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)

Comment 3

[Fatih Kilic [:fkilic]]

I see. I mean if accessibility isn't that big of a concern sure, I can working on a fix.

Comment 4

[Fatih Kilic [:fkilic]]

Attachment: Bug 1834307: Change StaticPrefs::general_smoothScroll() calls with nsLayoutUtils::IsSmoothScrollingEnabled. r?tjr

Comment 5

[Fatih Kilic [:fkilic]]

Attachment: Bug 1834307: Check RFPTarget::CSSPrefersReducedMotion in nsLayoutUtils::IsSmoothScrollingEnabled. r?tjr

Comment 6

[Thorin [:thorin]]

see https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42070 for downstream

(In reply to Fatih Kilic from comment #3)

I see. I mean if accessibility isn't that big of a concern sure, I can working on a fix.

It is, but requires a different solution - maybe a bit like RFPTargets and some UI. Personally I don't see an issue with smoothScroll being enforced, see this but IANAE on a11y

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5fedb6066739
Change StaticPrefs::general_smoothScroll() calls with nsLayoutUtils::IsSmoothScrollingEnabled. r=tjr
https://hg.mozilla.org/integration/autoland/rev/7ff8b1689b34
Check RFPTarget::CSSPrefersReducedMotion in nsLayoutUtils::IsSmoothScrollingEnabled. r=tjr

Comment 8

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/5fedb6066739
https://hg.mozilla.org/mozilla-central/rev/7ff8b1689b34

Comment 9

[Thorin [:thorin]]

verified as fixed

• tested with RFP + combos of general.smoothScroll and ui.prefersReducedMotion
• did not test with setting OS reduced motion and restarting the browser

Comment 10

[Ada C.]

I was able to reproduce the issue on Win10x64 using Firefox build 131.0a1 (2024-09-01).
Verified as fixed on Win10x64 and macOS 13.6 ARM using Firefox build 134.0a1 and 133.0b9.