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) and visiting https://www.youtube.com/watch?v=P-iiN0c2uic ; observe that the new-tab animation and the youtube playback do indeed render at ~1 frame per second. 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](https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c6453931ce30e85a09f5568bd5fa0c93944906ea&tochange=ed3de2af4538a15a1f4e791e5eaf4eab9658f813) that contains the [commit that created this `privacy.resistFingerprinting.pbmode` pref in the first place](https://hg.mozilla.org/integration/autoland/rev/290427746e6ed7447efebb743b795d169c459471). 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).
Bug 1863853 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
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](https://www.youtube.com/watch?v=P-iiN0c2uic) 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](https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c6453931ce30e85a09f5568bd5fa0c93944906ea&tochange=ed3de2af4538a15a1f4e791e5eaf4eab9658f813) that contains the [commit that created this `privacy.resistFingerprinting.pbmode` pref in the first place](https://hg.mozilla.org/integration/autoland/rev/290427746e6ed7447efebb743b795d169c459471). 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).