Steps to reproduce:

After Nightly Firefox Android auto updated to 2022-06-04, scrolling on all pages became janky.

Test with gfx.webrender.debug.profiler-ui and testufo.com revealed browser fps was being limited to 60 while Android dev overlay reports 120 FPS.

I verified this also happens on PC (Windows x86_x64 version of the same 2022-06-04 Nightly). Monitor is 144hz but Firefox is limited to 60 FPS.

Turns out the culprit was enabled privacy.resistFingerprinting
Disabling it removes the fps cap.
(https://bugzilla.mozilla.org/show_bug.cgi?id=1692609 is possibly related?)

Actual results:

about:support reports Target Frame Rate is 60 when it used to be 120

Jank everywhere

Expected results:

Smooth scrolling

Ability to opt-out from 60 fps limit without losing other benefits of resistFingerprinting

Hm.

So before, we had the timer precision at 100ms which messed up frame rates for web games because their (JS) programming had a frame rate influenced by the timers. We increased that precision; but at the same time capped the frame rate of the browser entirely AIUI.

If we did not cap the frame rate; I believe requestAnimationFrame could be used to discern that your hardware is going faster than 60 FPS: The number of callbacks is usually 60 times per second, but will generally match the display refresh rate in most web browsers as per W3C recommendation

(Ignoring that this regression affects all static content)

RaF that lies about frame pacing is worthless for games. At best you get micro stuttering. Actual fix would be to lock RaF behind a permission similarly to Fullscreen API.

requestAnimationFrame could be used to discern that your hardware is going faster than 60 FPS

That is true. Plenty of cheap or old devices struggle to render static content at 30fps. RaF can detect that too.

With VRR displays becoming increasingly more common, pretending that web is 60fps sounds like a very bad idea from UX standpoint.

Hi @throwaway.m62487sjyr47 Its possible that the issue you mentioned in the Description is related to this issue but that issue has been fixed with our later versions, does it still occur on your end ? Unfortunately I dont have a 144Hz monitor to test this issue on my side, please let us know and if it no longer occurs on your end we can close this issue.

Tested today's 109 Nightly on Android and same thing happens.

Maybe caused by https://hg.mozilla.org/mozilla-central/file/f518d5630dee70e46477bd8a61407a6438adf154/gfx/thebes/gfxPlatform.cpp#l3159

This is a dupe of Bug 1772711 edit, that was clever - I meant Bug 1774247 ?

(In reply to Simon Mainey from comment #5)

This is a dupe of Bug 1772711 edit, that was clever - I meant Bug 1774247 ?

This report is 10 days older, so technically 1774247 is the duplicate...

True, but the other one has more information/examples