While working on bug 1742842, I had a try run that shows the browser/base/content/test/general/browser_beforeunload_duplicate_dialogs.js test causing vsync to remain enabled at the end of the test on Mac (but not other platforms).

I can reproduce locally. Here is a profile of the test: https://share.firefox.dev/3810nHi

I tried to reduce the test case and noticed that the 60Hz composite stops if I delay the click that accepts the before unload prompt, ie. if I replace dialog.ui.button0.click(); at this line with setTimeout(() => {dialog.ui.button0.click();}, 350);.

I noticed that there is a tab-burst-animation CSS compositor animation that has a suspiciously close duration of 375ms.

If I reduce the 375ms duration of the CSS animation to 75ms, then I can make the test pass with a much shorter timer of 100ms before the click that closes the before unload dialog. This makes me think the bug is related to this CSS animation.

Hiro, here's another case where a closed window keeps the compositor running. What would be the right component for this?

This is somewhat similar to the first issue I mentioned in bug 1782134 comment 5. From the main-thread we try to send AddCompositorAnimationsIdForDiscard, but it's never processed since there's no EndTransactionWithoutLayer call for some reasons.

That's said, there's an unclear thing for me, that is that the animation in question is on the browser window, how is it affected by the dialog close?

Despite the workaround landed in bug 1742842, this is still failing in bug 1783214 at a relatively low frequency.

It's likely that fixing bug 1803387 would also fix this. But unlike in bug 1782825, forcing a GC is not enough to stop the animation, likely because the dialog somehow leaks a reference to the browser window.

I think this is fixed by bug 1803387.