1863853 - layout.frame_rate has no effect if `privacy.resistFingerprinting.pbmode` is toggled

Status: NEW

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

Description

[Daniel Holbert [:dholbert]]

STR:

1. If you're on Linux with wayland, run this in the terminal that you'll be launching Firefox from, to make sure you don't run in wayland mode (as a workaround for bug 1771017):

export MOZ_ENABLE_WAYLAND=0

2. Start Firefox with a fresh profile.
3. Visit about:config and set layout.frame_rate to 1.
4. Try opening a new tab (or several). Observe that the new-tab animation renders at ~1 frame per second. If you like, view a youtube video like this one and notice that it renders at ~1 fps too.
5. Now switch back to your about:config tab and set privacy.resistFingerprinting.pbmode to true.
6. Restart Firefox, and observe how it behaves now.

ACTUAL RESULTS:
Firefox seems to ignore the layout.frame_rate setting when privacy.resistFingerprinting.pbmode is set to true at startup.

EXPECTED RESULTS:
There shouldn't be any connection between privacy.resistFingerprinting.pbmode and layout.frame_rate, except maybe for private browsing windows (or after I've opened a private browsing window).

From testing with mozregression, this is reproducible back to the push that contains the commit that created this privacy.resistFingerprinting.pbmode pref in the first place. So I think this has been broken going back to that point (i.e. this .pbmode pref inadvertently has non-pbmode side effects, and has ever since it was created).

Comment 1

[Daniel Holbert [:dholbert]]

From adding a bit of logging, it looks like this layout.frame_rate pref gets read here:
https://searchfox.org/mozilla-central/rev/02841791400cf7cf5760c0cfaf31f5d772624253/gfx/thebes/gfxPlatform.cpp#3354-3361

static int LayoutFrameRateFromPrefs() {
  auto val = StaticPrefs::layout_frame_rate();
  if (nsContentUtils::ShouldResistFingerprinting(
          "The frame rate is a global property.", RFPTarget::FrameRate)) {
    val = 60;
  }
  return val;
}

If privacy.resistFingerprinting.pbmode is true, then the nsContentUtils::ShouldResistFingerprinting call there returns true, and that's what nerfs the user's chosen frame_rate and makes us force it to 60.

Comment 2

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

Based on comment #0, this bug contains a bisection range found by mozregression. However, the Regressed by field is still not filled.

:tjr, since you are the author of the changes in the range, if possible, could you fill the Regressed by field and investigate this regression?

For more information, please visit BugBot documentation.

Comment 3

[Daniel Holbert [:dholbert]]

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #2)

:tjr, since you are the author of the changes in the range, if possible, could you fill the Regressed by field and investigate this regression?

Not exactly a regression given that the STR requires a pref to be set, and the pref didn't exist before the already-identified related commit from that push range. (hence: I've got this already set up as depends-on, not regressed-by that bug.)

Comment 4

[Tom Ritter [:tjr]]

I believe that this is working as intended. One of the things that RFP does is limit the granularity of system timers. A timer can be constructed based off requestAnimationFrame, so the granularity can be no coarser than how often that gets called. We hardcoded it at 60 for a granularity of 16.67 ms.

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Tom Ritter [:tjr] from comment #4)

I believe that this is working as intended.

Not exactly. privacy.resistFingerprinting.pbmode is documented as such (**-emphasis added by me):
# When the .pbmode pref is on, RFP or FPP will be **enabled in PBM**
https://searchfox.org/mozilla-central/rev/76b13c585e575cf273fd05ab3b48a1532c1d1faa/modules/libpref/init/StaticPrefList.yaml#13114,13116

In the STR here, I am at no point entering PBM, so it's surprising that there's any behavior-change from this pref being enabled.

Having said that: I did notice the code you linked to which notes "The frame rate is a global property", so it's presumably not possible to turn it off specifically for PBM windows. But we could still only start throttling it when a PBM window is opened, perhaps? (which would affect normal windows too, but at least it'd be a bit more scoped and understandable-to-users due to the temporal connection between the frame-rate change and the private browsing window opening.)

(LayoutFrameRateFromPrefs is a dynamic function -- it does seem to be responsive to live changes to the pref, in a fresh profile without any fingerprinting prefs toggled. So it seems conceivable that we could adjust it so that its privacy.resistFingerprinting.pbmode-specific behavior gets dynamically enabled when a Private Browsing window is opened.)

Comment 6

[Daniel Holbert [:dholbert]]

(And the commit that introduced our current behavior had something to the same effect in its extended commit message: "Create two pbmode prefs that will enable RFP/FPP in PBMode only". That implies that the intent here is that these .pbmode prefs only make a difference when you're in private browsing mode.)

Users probably won't read that documentation, but I think there's a natural assumption that this is how these .pbmode prefs work -- they only make a difference if/when you use private browsing mode.

Comment 7

[Tom Ritter [:tjr]]

Bug 1851816 is something I am working on to fix the situation with you have FPP enabled globally and RFP.pbmode enabled - right now RFP will be enabled globally also.

But that's separate from what you're talking about which is that yes - there are a few things that apply globally when you have RFP.pbmode enabled. I definitely think we should improve the documentation (we have a SUMO article on RFP in the works, and this would fit well there.)

As far as enabling this behavior dynamically once you've opened a PB Window... I am not sure. I wouldn't block such a patch, but it seems pretty overcomplicated. Remember that RFP (both RFP and RFP.pbmode) are not Mozilla-supported preferences for users, so we don't promise any particular level of usability for them.

Comment 8

[Daniel Holbert [:dholbert]]

Note: this bug here is specifically about the .pbmode pref introducing an unintended side effect, per comment 5.

I just spun off bug 1897251 on the related/more-direct issue that layout.frame_rate gets nerfed when privacy.resistFingerprinting is enabled in general [which is essentially things working-as-intended, but perhaps it's worth adding an escape hatch].

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #0)

1. If you're on Linux with wayland, run this in the terminal that you'll be launching Firefox from, to make sure you don't run in wayland mode

(also, following up on this^ caveat in the STR: I suspect this is bug 1771017.)