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

Steps to reproduce:

FireFox doesn't load all page elements if to set high refresh rate. I've been experiencing this problem quite long time. I tested it and recorded even on clean latest nightly 101.0a1 (2022-04-13) (64-bit), there is Bug 1763451 but it is fixed for now so there seem no connection with it.
I did mozregression (after narrowing wide time date spread I chose dates between 2020-12-25 and 2020-12-28) and it showed me that:
86.0a1 (2020-12-26) (64-bit) last not affected build (all is OK)
86.0a1 (2020-12-27) (64-bit) affected
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=555a05fe5330511dd715fdd6a39dc9d55baacd91&tochange=74c33e8ce86d9ff26e2bcf402039b436556f97ed

The test URL in my case was (the problem is taking place on almost every youtube URL):
https://www.youtube.com/watch?v=Kx258Y8HnqE

I recorded videos to help you see how it works:

1. 144HZ - OK
   https://youtu.be/KBaxpQ3_lJk
2. 280HZ - NOT OK
   https://youtu.be/40DVtBLwApk

Firefox Profiler logs:
144Hz
https://share.firefox.dev/3KGi9y4

280Hz
https://share.firefox.dev/3xpVbHF

I tried consequentially to lower refresh rate from 280Hz to 240, 220, 200 etc. and it looks like the lower your refresh rate the lower is the time gap delay.

Steps to reproduce:

1. Open any youtube video page.
2. Click on red play button as soon as you can.
3. Wait for all page layout is loaded.
4. Refresh the page.
5. Repeat steps 2-4.

Actual results:

Firefox loads only video rectangle area then after few seconds delay loads rest elements.

Expected results:

Firefox instantly loads all elements of page.

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Taking a stab at a guess on the regression, since the range was provided.

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

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

bug 1684215 is not a functional change. You need to find a different regressing bug.

More important info here.

I've just found out that layout is stuck while you move mouse cursor strictly within rectangle area of video. Even with 144Hz it is stuck but not always, so I tested it with 85Hz and no stuck is present. You even don't have to start video playing.
I recorded 3 new videos:
Testcase video 1. https://youtu.be/we1x4VIN54M
280Hz, there are two cases in this video:

1. The layout is loading when I move mouse cursor out of the borders of video area.
2. When I stop moving mouse cursor (but left the cursor in the video area) and video control layer is disappearing then the layout is loading.

Testcase video 2. https://youtu.be/9QGF4Hlh8Kk
85Hz, can't catch this stuck, all seem fine.

Testcase video 3. https://youtu.be/RSnYoS8NYeA
280Hz, similar to video 1, but I don't press on play button.

And firefox profiler for testcase video 3:
https://share.firefox.dev/3KMnQur

Fresh video of mozregression process, same outcome like in the first my comment.
https://youtu.be/qfulTLM779Y

Does this happen only in YouTube? Maybe they rely on some timing wrt requestAnimationFrame and so on?

Olli, do the profiles and so in comment 6 hint at something?

Yes, I got such behavior in YouTube. Haven't seen on other sites so far.

(Bug 1763451 was a regression fix and affected only parent process, so not surprising it didn't affect this one.)

Bug 1681030 seems like the most likely bug to cause this in the range provided in comment 0.
But I wonder if this was broken even earlier, this just accidentally worked ok for while.
Was this an issue also before https://hg.mozilla.org/mozilla-central/rev/e4dc75be2d56 ?
Seems like bug 1681030 did fix a rather major issue in idle handling, so if youtube is using requestIdleCallback a lot, the behavior could have changed.

So, could you test also using a bit older build?

Yes, the issue seemed to have place long before (tested june and august 2020 builds, same effect).
Mozregression showed last "bad" build with the issue:
build_date: 2020-12-01
build_url: https://archive.mozilla.org/pub/firefox/nightly/2020/12/2020-12-01-21-53-01-mozilla-central/firefox-85.0a1.en-US.win64.zip

And next "good" build came then:
build_date: 2020-12-02
build_url: https://archive.mozilla.org/pub/firefox/nightly/2020/12/2020-12-02-22-50-27-mozilla-central/firefox-85.0a1.en-US.win64.zip

Then I downloaded builds from your link https://hg.mozilla.org/mozilla-central/rev/e4dc75be2d56
First release with 85.0a1 / 20201202214250 - Good, ALL is OK
Last release without 85.0a1 / 20201202091636 - Issue is present, NOT OK.

Hmm, just a thought...
Could you try decreasing idle_period.min in about:config
It should be 3 by default, but try 2.

It looks like it helped by half. Sometimes it's still stuck, sometimes not. Tested in final 99.0.1 and latest nightly 101.0a1.

The severity field is not set for this bug.
:boris, could you have a look please?

For more information, please visit auto_nag documentation.

Mark S2 for now because it seems there is no workaround way to avoid the slow with high monitor refresh rate.

(In reply to dj2000al from comment #11)

First release with 85.0a1 / 20201202214250 - Good, ALL is OK
Last release without 85.0a1 / 20201202091636 - Issue is present, NOT OK.

Regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f4001dfef5bc&tochange=575b67d9c9b66197fdb848d9b8a660ca387a7519

Possibly related to bug 1645528?

bug 1645528 is definitely a hot candidate since it deals with screen refresh rates etc. and triggered subtle regressions before (had several backouts).
Though I'm having troubles imagining what exactly could cause the behavior here.

I found the easier way to reproduce the issue. You have to open any upcoming live stream which hasn't started yet.
Upcoming live streams here:
https://www.youtube.com/playlist?list=PLU12uITxBEPGnB_U6gM0VtL9De0wUiCiM

I have recorded 2 videos with idle_period.min values "2" and "3":

idle_period.min 3
https://youtu.be/ixhDwXflX-s

idle_period.min 2
https://youtu.be/9ED2I_7h3Ew

With idle_period.min 2 it works a bit better (e.g. the moment after 40 seconds of video) but still isn't stable.

Profiler with idle_period.min 3
https://share.firefox.dev/3sGLMbw

Tested on latest nightly 102.0a1 (2022-05-17) (64-bit).

Unfortunately I have little time atm to investigate this - Markus, I think you've been doing a lot of work in that area lately, do you have an idea or will you have a look?

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

We've made some changes to idle scheduling in bug 1771718. Could you test a recent Nightly and see if the experience has improved?

Yes, now it works fine and the same speed at high or at low refresh rates. Thank you, guys!

Thanks for testing.
Marking this a dup of bug 1771718. Please reopen if needed, or file new bugs if there are other issues.