Some of the recent intermittent reports in bug 1358898 point to CompositorThreadHolder::Shutdown:

[task 2021-11-08T17:22:38.397Z] 17:22:38     INFO - GECKO(1905) | RunWatchdog: Mainthread nested event loops during hang:
[task 2021-11-08T17:22:38.398Z] 17:22:38     INFO - GECKO(1905) |  --- CompositorThreadHolder::Shutdown
[task 2021-11-08T17:22:39.402Z] 17:22:39     INFO - GECKO(1905) | Hit MOZ_CRASH(Shutdown hanging after all known phases and workers finished.) at /builds/worker/checkouts/gecko/toolkit/components/terminator/nsTerminator.cpp:256
[task 2021-11-08T17:22:39.403Z] 17:22:39     INFO - GECKO(1905) | #01: mozilla::(anonymous namespace)::RunWatchdog(void*) [toolkit/components/terminator/nsTerminator.cpp:256]

The breaking condition in the destructor of sCompositeThreadHolder will trigger only if all holders of a CompositorThreadHolder reference have died.

We cannot really see from the current instrumentation, who is keeping the reference alive.

I was able to locally reproduce a hang with CompositorThreadHolder, maybe in that same signature, with this, on my Windows machine:

mach test --headless --enable-fission --verify browser/components/extensions/test/browser/browser_ext_tabs_move_window.js

It might be irrelevant, but from [this search] it seems that the canvas thread may hold the CompositorThreadHolder alive and we did not explicitly shut it down until bug 1798298.

In any case in the latest reports I did not see this flavor. :mccr8, can you still reproduce?

My Windows machine stopped working a few months ago, sorry.

We seem to have a few real world reports here (not too much compared with other hangs, but still).