1774247 - Enabling "privacy.resistFingerprinting" restricts Firefox to 60 FPS

Status: NEW

(Core :: Privacy: Anti-Tracking, defect, P3)

Description

[dragos.slash]

Attachment: Untitled.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0

Steps to reproduce:

Open about:config, set "privacy.resistFingerprinting" = true
Visit https://www.testufo.com/ and on a high refresh rate monitor, Firefox will be limited to 60 FPS rendering, resulting in a very sluggish UI.

I will attach screenshots of Firefox Beta 102b5 where everything works fine, and Firefox Beta 102b6, which was the first Beta exhibiting this issue.

I am running Windows 10, on a 360 Hz panel.

I can reproduce this issue on Firefox Nightly for Android as well.

Actual results:

Firefox UI is limited to 60 FPS.

Expected results:

On a high refresh rate monitor, Firefox should render everything at a framerate according to the monitor's refresh rate.

Comment 1

[dragos.slash]

Attachment: Chromium and display properties.

I will attach a screenshot providing the actual refresh rate of the monitor, and Chromium showing it as well.

Comment 2

[Gregory Pappas [:gregp]]

This is intended behavior per bug 1692609

Comment 3

[dragos.slash]

I wish this was an optional pref like "privacy.resistFingerprinting.letterboxing". In Firefox Stable 101 and ESR 91, "privacy.resistFingerprinting" has pretty much no user-facing negative consequences. Now it make me want it completely OFF because the performance is just unbearable.

Comment 4

[BugBot [:suhaib / :marco]]

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

Comment 5

[BugBot [:suhaib / :marco]]

:tjr, since you are the author of the regressor, bug 1692609, could you take a look?
For more information, please visit auto_nag documentation.

Comment 6

[Tom Ritter [:tjr]]

I regret the degradation in interactive performance of the browser; it was not something I anticipated or intended. At the same time; I am not sure what we want to do about it. We can't help the fact that sometimes peoples computers can't keep up with 60Hz and go below it. But given that > 60Hz refresh rate is a fingerprintable aspect (I expect something a minority of users have, making them more unique) the hard-line stance would be the ensure that web content can't detect that.

I don't know if the Firefox UI can have a refresh rate independent of content (if that was even something we wanted to do.) I think this (along with some other issues) are going to have to be elevated to Tor for decision-making....

Comment 7

[Pascal Chevrel (relman team) -> :pascalc|PTO until Sept 2]

(In reply to Tom Ritter [:tjr] (ni? for sec-related stuff) from comment #6)

I regret the degradation in interactive performance of the browser; it was not something I anticipated or intended. At the same time; I am not sure what we want to do about it. We can't help the fact that sometimes peoples computers can't keep up with 60Hz and go below it. But given that > 60Hz refresh rate is a fingerprintable aspect (I expect something a minority of users have, making them more unique) the hard-line stance would be the ensure that web content can't detect that.

I don't know if the Firefox UI can have a refresh rate independent of content (if that was even something we wanted to do.) I think this (along with some other issues) are going to have to be elevated to Tor for decision-making....

Should we backout bug 1692609 on beta?

Comment 8

[Tom Ritter [:tjr]]

After checking with Tor they would like to keep this in ESR 102.

Comment 9

[kaancaliskan]

This bug also affects Android https://github.com/mozilla-mobile/fenix/issues/25530

Comment 10

[dragos.slash]

Attachment: privacy.resistFingerprinting=false.png

privacy.resistFingerprinting=false ESR 102
no dropped frames playing a 60fps video

Comment 11

[dragos.slash]

Attachment: privacy.resistFingerprinting=true.png

privacy.resistFingerprinting=true ESR 102
lots of dropped frames playing a 60fps video, not being able to maintain 60fps playback anymore

Comment 12

[dragos.slash]

The situation seems to be a lot worse than I initially thought. The framepasing is incorrect, as a consequence my machine no longer is capable of maintaining 60fps at all. I will upload two screenshots, one with privacy.resistFingerprinting enabled and another one with it disabled.

YouTube's own statistics confirms my machine is no longer capable of playing a 60fps video properly, skipping many frames and maintaining an average of below 50fps.

This is being felt throughoout the UI as well, everything feeling very sluggish.

What is even worse is that I can fully reproduce this issue when I run my PC at 60Hz (monitor's native refresh rate is 360Hz) as well. In theory a 60fps cap on a 60Hz monitor should be no problem, but that's not the case. privacy.resistFingerprinting just destroys the performance.

This is on ESR 102, sadly. I think I'm fairly unique now on the internet with a 44fps cap.

Comment 13

[BugBot [:suhaib / :marco]]

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

Comment 14

[Franklin]

I'm chiming in to agree with dragos.slash. This new cap for ResistFingerprinting makes the UI feel sluggish and downright unpleasant on high refresh rate monitors -- which includes most smartphones as well. This is the first usability issue that has forced my to turn off RFP, as the performance regression is just too extreme.

Please reconsider your choice of throttling the entire UI to 60hz

Comment 15

[Donal Meehan [:dmeehan]]

:tjr would it be enough to keep this patch on ESR102 but backing this out of the train releases?

Comment 16

[dragos.slash]

It would be best moved as a separate pref. It doesn't need to be part of privacy.resistFingerprinting

Comment 17

[Tom Ritter [:tjr]]

I'm afraid we could not, as Tor builds Tor Browser for Android from the release train.

Comment 18

[Dot]

This makes browsing a micro-stutter-fest even on 60Hz effectively neutering almost-perfect mousewheel smooth scrolling.

///  NATURAL SMOOTH SCROLLING V4 "SHARP" - AveYo, 2020-2022             preset     [default]
user_pref("general.smoothScroll.msdPhysics.continuousMotionMaxDeltaMS",   12);//NSS    [120]
user_pref("general.smoothScroll.msdPhysics.enabled",                    true);//NSS  [false]
user_pref("general.smoothScroll.msdPhysics.motionBeginSpringConstant",   200);//NSS   [1250]
user_pref("general.smoothScroll.msdPhysics.regularSpringConstant",       250);//NSS   [1000]
user_pref("general.smoothScroll.msdPhysics.slowdownMinDeltaMS",           25);//NSS     [12]
user_pref("general.smoothScroll.msdPhysics.slowdownMinDeltaRatio",     "2.0");//NSS    [1.3]
user_pref("general.smoothScroll.msdPhysics.slowdownSpringConstant",      250);//NSS   [2000]
user_pref("general.smoothScroll.currentVelocityWeighting",             "1.0");//NSS ["0.25"]
user_pref("general.smoothScroll.stopDecelerationWeighting",            "1.0");//NSS  ["0.4"]

Comment 19

[Franklin]

Is there any hope of this being fixed? It continues to make privacy.resistfingerprinting unresponsive on high refresh rate displays.

Comment 21

[Bren Smarkles]

Any update on this? this situation makes a browser choosing between privacy and browser usability.

Comment 22

[Bren Smarkles]

can anyone update on how you're dealing with this issue? are there any easy workarounds like switching profiles or RFP automatically for videos etc.?

Comment 23

[Tom Ritter [:tjr]]

It is possible to disable this behavior while keeping the rest of RFP behaviors by setting:

privacy.resistFingerprinting = false
privacy.fingerprintingProtection = true
privacy.fingerprintingProtection.overrides = "+AllTargets,-FrameRate"

Note that like RFP, this is an unsupported configuration and we make no guarantees that this makes you less fingerprintable and not more. But if you like playing with prefs, this should do what you want.

Comment 24

[throwaway.m62487sjyr47]

Fact is this is a major regression for users with screens that go above 60hz. Touch scrolling at 60fps is super janky on 120hz smartphone.

For me, the point of fingerprinting "resistance" has never been avoiding uniqueness. Logging in to an account already identifies "unique" user. Actual value of privacy.resistFingerprinting comes from obfuscating locale/timezone and other stuff sites do not need to know.

Why not just add opt-out preference for 60 fps limit?