I don't really understand why this happens, but it does, so filing.

STR:

1. open new profile on mac/windows (haven't tested linux, wouldn't be surprised if it happened there too)
2. open about:config
3. toggle layout.frame_rate to some positive number like 30 or 60.
   (now responsiveness is fine, you can see when hovering over the column headers or various other browser elements)
4. right click it, click 'reset'

ER:
responsiveness should still be fine

AR:
no painting (or something?) until you switch tabs, resize the window, or do something else that somehow gives the whole thing a proverbial kick to "make it work" again.

From the profile, it seems the compositor and painting stops: https://perfht.ml/2QC8I5G .

:kats, do these symptoms give you any clue as to what's going on here?

Offhand I don't have any theories as to why this might be.

I confirmed the problem on Win10 and linux.

When VsyncSource::Display is relplaced by new one in gfxPlatform::ReInitFrameRate(), new display did not enable vsync since VsyncSource::Display::UpdateVsyncStatus() did not called.

(In reply to Sotaro Ikeda [:sotaro] from comment #3)

When VsyncSource::Display is relplaced by new one in gfxPlatform::ReInitFrameRate(), new display did not enable vsync since VsyncSource::Display::UpdateVsyncStatus() did not called.

Right, but even calling it from MoveListenersToNewSource (and making sure we're no longer in the lock) doesn't seem to be enough, from what I can tell from local testing. I suspect this is because when we hit https://searchfox.org/mozilla-central/rev/39265dd58298c40bed029617ad408bf806cce761/gfx/thebes/VsyncSource.cpp#131-132 , there might not be compositor listeners, and mRefreshTimerNeedsVsync is initialized to false. The widget code in VsyncDispatcher that normally calls into here and can enable/disable vsync doesn't seem to expose a way of doing this publicly. Not sure if it'd be kosher to add one, or if there's some other way of accomplishing this that would be preferable?