[This is a deep, interesting stack.](https://treeherder.mozilla.org/logviewer?job_id=404736476&repo=try) - `nsAppStartup::Quit` is notifiying `quit-application-granted` - Some observer (yet to be identified) is doing a `nsThreadPool::ShutdownWithTimeout` that spins an event loop, waiting for a pool - While in that loop, we get a `CanonicalBrowsingContext::ChangeRemoteness` event that will ask for a `nsFrameLoader::EnsureRemoteBrowser` that will make `ContentParent::GetNewOrUsedLaunchingBrowserProcess` fail So we actually started parent shutdown and apparently we already notified `ShutdownPhase::AppShutdown` while on top of the nested event loop, which caused our child processes to start shutdown. Several things come to my mind: 1. We might want to check the path that starts from `CanonicalBrowsingContext::ChangeRemoteness` if we miss some shutdown check. 2. We probably want to find the cause for `nsThreadPool::ShutdownWithTimeout` during `quit-application-granted` and avoid it (moving it probably to the next phase). To help diagnose the cause, we could add the pool's name to the `SpinEventLoopUntil` annotation inside `nsThreadPool::ShutdownWithTimeout`.
Bug 1815261 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
[This is a deep, interesting stack.](https://treeherder.mozilla.org/logviewer?job_id=404736476&repo=try) - `nsAppStartup::Quit` is notifiying `quit-application-granted` - Some observer (yet to be identified) is doing a `nsThreadPool::ShutdownWithTimeout` that spins an event loop, waiting for a pool - While in that loop, we get a `CanonicalBrowsingContext::ChangeRemoteness` event that will ask for a `nsFrameLoader::EnsureRemoteBrowser` that will make `ContentParent::GetNewOrUsedLaunchingBrowserProcess` fail So we actually started parent shutdown and apparently we already notified `ShutdownPhase::AppShutdown` while on top of the nested event loop, which caused our child processes to start shutdown. Several things come to my mind: 1. We might want to check the path that starts from `CanonicalBrowsingContext::ChangeRemoteness` if we miss some shutdown check. 2. We probably want to find the cause for `nsThreadPool::ShutdownWithTimeout` during `quit-application-granted` and avoid it (moving it probably to the next phase). To help diagnose the cause, we could add the pool's name to the `SpinEventLoopUntil` annotation inside `nsThreadPool::ShutdownWithTimeout` (which would be nice to have in any case, I'd say).
[This is a deep, interesting stack.](https://treeherder.mozilla.org/logviewer?job_id=404736476&repo=try) - `nsAppStartup::Quit` is notifiying `quit-application-granted` - Some observer of `quit-application-granted` (aka `ShutdownPhase::AppShutdownConfirmed`) (yet to be identified) is doing a `nsThreadPool::ShutdownWithTimeout` that spins an event loop, waiting for a pool - While in that loop, we get a `CanonicalBrowsingContext::ChangeRemoteness` event that will ask for a `nsFrameLoader::EnsureRemoteBrowser` that will make `ContentParent::GetNewOrUsedLaunchingBrowserProcess` fail So we actually started parent shutdown and apparently we already notified `ShutdownPhase::AppShutdown` while on top of the nested event loop, which caused our child processes to start shutdown. Several things come to my mind: 1. We might want to check the path that starts from `CanonicalBrowsingContext::ChangeRemoteness` if we miss some shutdown check. 2. We probably want to find the cause for `nsThreadPool::ShutdownWithTimeout` during `quit-application-granted` and avoid it (moving it probably to the next phase). To help diagnose the cause, we could add the pool's name to the `SpinEventLoopUntil` annotation inside `nsThreadPool::ShutdownWithTimeout` (which would be nice to have in any case, I'd say).