Bugzilla

Extensions start to shutdown at "quit-application-granted" but their shutdown is not bound to a single phase and [can last until "profile-change-teardown"](https://searchfox.org/mozilla-central/rev/284187d0a7130d21042beeff0af0627c8e68cacc/toolkit/mozapps/extensions/internal/XPIProvider.jsm#2588,2624). Extensions [broadcast shutdown messages to all children]( https://searchfox.org/mozilla-central/rev/3e1a721bce1da3ae04675539b39a4e95b25a046d/toolkit/components/extensions/Extension.jsm#3249-3252) that the extension is going away and then [waits for all of them to acknowledge the message](https://searchfox.org/mozilla-central/rev/3e1a721bce1da3ae04675539b39a4e95b25a046d/toolkit/components/extensions/Extension.jsm#2717-2749). 
Due to this and before bug 1777198 will land and be enabled on all channels, a blocking JS in a content process will make timeout extensions shutdown.
While that will mitigate the timeouts, there seems to be no strong reason to shutdown the extensions before we shutdown the content children, as they want to communicate with each of them to tell them they are going away. This seems to be unnecessary noise during shutdown that could be better avoided. Inverting that order might not be trivial, though, given how the extensions shutdown spans over several shutdown phases currently (which might worth rethinking, too).

Extensions start to shutdown at "quit-application-granted" but their shutdown is not bound to a single phase and [can last until "profile-change-teardown"](https://searchfox.org/mozilla-central/rev/284187d0a7130d21042beeff0af0627c8e68cacc/toolkit/mozapps/extensions/internal/XPIProvider.jsm#2588,2624). Extensions [broadcast shutdown messages to all children]( https://searchfox.org/mozilla-central/rev/3e1a721bce1da3ae04675539b39a4e95b25a046d/toolkit/components/extensions/Extension.jsm#3249-3252) that the extension is going away and then [waits for all of them to acknowledge the message](https://searchfox.org/mozilla-central/rev/3e1a721bce1da3ae04675539b39a4e95b25a046d/toolkit/components/extensions/Extension.jsm#2717-2749). 
Due to this and before bug 1777198 will land and be enabled on all channels, a blocking JS in a content process will make timeout extensions shutdown.
While that will mitigate the timeouts, there seems to be no strong reason to shutdown the extensions before we shutdown the content children, as they want to communicate with each of them to tell them they are going away. This seems to be unnecessary noise during shutdown that could be better avoided. Inverting that order might not be trivial, though, given how the extensions shutdown spans over several shutdown phases currently (which might be worth rethinking, too).

Extensions start to shutdown at "quit-application-granted" but their shutdown is not bound to a single phase and [can last until "profile-change-teardown"](https://searchfox.org/mozilla-central/rev/284187d0a7130d21042beeff0af0627c8e68cacc/toolkit/mozapps/extensions/internal/XPIProvider.jsm#2588,2624). Extensions [broadcast shutdown messages to all children]( https://searchfox.org/mozilla-central/rev/3e1a721bce1da3ae04675539b39a4e95b25a046d/toolkit/components/extensions/Extension.jsm#3249-3252) that the extension is going away and then [waits for all of them to acknowledge the message](https://searchfox.org/mozilla-central/rev/3e1a721bce1da3ae04675539b39a4e95b25a046d/toolkit/components/extensions/Extension.jsm#2717-2749). 
Due to this and before bug 1777198 will land and be enabled on all channels, a blocking JS in a content process will make timeout extensions shutdown.
While bug 1777198 will mitigate the timeouts, there seems to be no strong reason to shutdown the extensions before we shutdown the content children, as they want to communicate with each of them to tell them they are going away. This seems to be unnecessary noise during shutdown that could be better avoided. Inverting that order might not be trivial, though, given how the extensions shutdown spans over several shutdown phases currently (which might be worth rethinking, too).