[Looking at the call paths to `BeginSubprocessLaunch`](https://searchfox.org/mozilla-central/query/default?q=calls-to%3A%27mozilla%3A%3Adom%3A%3AContentParent%3A%3ABeginSubprocessLaunch%27+depth%3A5) we should probably have regular checks also at: - `SharedWorkerManager::MaybeCreateRemoteWorker` and `BackgroundParentImpl::AllocPRemoteWorkerControllerParent` - `ContentParent::RecvCloneDocumentTreeInto` - `nsFrameLoader::EnsureRemoteBrowser` and/or [some of its callers](https://searchfox.org/mozilla-central/query/default?q=calls-to%3A%27nsFrameLoader%3A%3AEnsureRemoteBrowser%27%20depth%3A4) - `the `PreallocatedProcessManager`should stop to serve processes, too, which has been already addressed by bug 1795964. I assume that `XRE_SendTestShellCommand` and `nsIXULRuntime::EnsureContentProcess` should not check anything but just let the launching code assert at lower levels in case. These checks can probably go away (leaving just the assert in `AssertAlive`): - [`ContentParent::BeginSubprocessLaunch`](https://searchfox.org/mozilla-central/rev/270f0ed2146821e239232728adac41a3de41131b/dom/ipc/ContentParent.cpp#2594) but only in or beyond `AppShutdown` - [`ContentParent::CreateBrowser`](https://searchfox.org/mozilla-central/rev/270f0ed2146821e239232728adac41a3de41131b/dom/ipc/ContentParent.cpp#1469) but only in or beyond `AppShutdown` Remains the question if `ContentParent::GetNewOrUsedLaunchingBrowserProcess` should bail out, too, or just rely on the callers (and the `AssertAlive`). Note that there is a [shortcut that hands out a used process](https://searchfox.org/mozilla-central/rev/270f0ed2146821e239232728adac41a3de41131b/dom/ipc/ContentParent.cpp#1056-1067) there, too.
Bug 1811195 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
[Looking at the call paths to `BeginSubprocessLaunch`](https://searchfox.org/mozilla-central/query/default?q=calls-to%3A%27mozilla%3A%3Adom%3A%3AContentParent%3A%3ABeginSubprocessLaunch%27+depth%3A5) we should probably have regular checks also at: - `SharedWorkerManager::MaybeCreateRemoteWorker` and `BackgroundParentImpl::AllocPRemoteWorkerControllerParent` - `ContentParent::RecvCloneDocumentTreeInto` - `nsFrameLoader::EnsureRemoteBrowser` and/or [some of its callers](https://searchfox.org/mozilla-central/query/default?q=calls-to%3A%27nsFrameLoader%3A%3AEnsureRemoteBrowser%27%20depth%3A4) - the `PreallocatedProcessManager` should stop to serve processes, too, which has been already addressed by bug 1795964. I assume that `XRE_SendTestShellCommand` and `nsIXULRuntime::EnsureContentProcess` should not check anything but just let the launching code assert at lower levels in case. These checks can probably go away (leaving just the assert in `AssertAlive`): - [`ContentParent::BeginSubprocessLaunch`](https://searchfox.org/mozilla-central/rev/270f0ed2146821e239232728adac41a3de41131b/dom/ipc/ContentParent.cpp#2594) but only in or beyond `AppShutdown` - [`ContentParent::CreateBrowser`](https://searchfox.org/mozilla-central/rev/270f0ed2146821e239232728adac41a3de41131b/dom/ipc/ContentParent.cpp#1469) but only in or beyond `AppShutdown` Remains the question if `ContentParent::GetNewOrUsedLaunchingBrowserProcess` should bail out, too, or just rely on the callers (and the `AssertAlive`). Note that there is a [shortcut that hands out a used process](https://searchfox.org/mozilla-central/rev/270f0ed2146821e239232728adac41a3de41131b/dom/ipc/ContentParent.cpp#1056-1067) there, too.
[Looking at the call paths to `BeginSubprocessLaunch`](https://searchfox.org/mozilla-central/query/default?q=calls-to%3A%27mozilla%3A%3Adom%3A%3AContentParent%3A%3ABeginSubprocessLaunch%27+depth%3A5) we should probably have regular checks also at: - `SharedWorkerManager::MaybeCreateRemoteWorker` and `BackgroundParentImpl::AllocPRemoteWorkerControllerParent` - `ContentParent::RecvCloneDocumentTreeInto` - `nsFrameLoader::EnsureRemoteBrowser` and/or [some of its callers](https://searchfox.org/mozilla-central/query/default?q=calls-to%3A%27nsFrameLoader%3A%3AEnsureRemoteBrowser%27%20depth%3A4) - the `PreallocatedProcessManager` should stop to serve processes, too, which has been already addressed by bug 1795964. I assume that `XRE_SendTestShellCommand` and `nsIXULRuntime::EnsureContentProcess` should not check anything but just let the launching code assert at lower levels in case. These checks can probably go away (leaving just the assert in `AssertAlive`): - [`ContentParent::BeginSubprocessLaunch`](https://searchfox.org/mozilla-central/rev/270f0ed2146821e239232728adac41a3de41131b/dom/ipc/ContentParent.cpp#2594) - [`ContentParent::CreateBrowser`](https://searchfox.org/mozilla-central/rev/270f0ed2146821e239232728adac41a3de41131b/dom/ipc/ContentParent.cpp#1469) Remains the question if `ContentParent::GetNewOrUsedLaunchingBrowserProcess` should bail out, too, or just rely on the callers (and the `AssertAlive`). Note that there is a [shortcut that hands out a used process](https://searchfox.org/mozilla-central/rev/270f0ed2146821e239232728adac41a3de41131b/dom/ipc/ContentParent.cpp#1056-1067) there, too.
[Looking at the call paths to `BeginSubprocessLaunch`](https://searchfox.org/mozilla-central/query/default?q=calls-to%3A%27mozilla%3A%3Adom%3A%3AContentParent%3A%3ABeginSubprocessLaunch%27+depth%3A5) we should probably have regular checks also at: - `SharedWorkerManager::MaybeCreateRemoteWorker` and `BackgroundParentImpl::AllocPRemoteWorkerControllerParent` - `ContentParent::RecvCloneDocumentTreeInto` - `nsFrameLoader::EnsureRemoteBrowser` and/or [some of its callers](https://searchfox.org/mozilla-central/query/default?q=calls-to%3A%27nsFrameLoader%3A%3AEnsureRemoteBrowser%27%20depth%3A4) - the `PreallocatedProcessManager` should stop to serve processes, too, which has been already addressed by bug 1795964. I assume that `XRE_SendTestShellCommand` and `nsIXULRuntime::EnsureContentProcess` should not check anything but just let the launching code assert at lower levels in case. These checks can probably go away (leaving just the assert in `AssertAlive`): - [`ContentParent::BeginSubprocessLaunch`](https://searchfox.org/mozilla-central/rev/270f0ed2146821e239232728adac41a3de41131b/dom/ipc/ContentParent.cpp#2594) - [`ContentParent::CreateBrowser`](https://searchfox.org/mozilla-central/rev/270f0ed2146821e239232728adac41a3de41131b/dom/ipc/ContentParent.cpp#1469) Remains the question if `ContentParent::GetNewOrUsedLaunchingBrowserProcess` should bail out, too, or just rely on the callers (and the `AssertAlive`). Note that there is a [shortcut that hands out a used process](https://searchfox.org/mozilla-central/rev/270f0ed2146821e239232728adac41a3de41131b/dom/ipc/ContentParent.cpp#1056-1067) there, too, and bug 1811746 shows this happens in the wild.
[Looking at the call paths to `BeginSubprocessLaunch`](https://searchfox.org/mozilla-central/query/default?q=calls-to%3A%27mozilla%3A%3Adom%3A%3AContentParent%3A%3ABeginSubprocessLaunch%27+depth%3A5) we should probably have regular checks also at: - ~~`SharedWorkerManager::MaybeCreateRemoteWorker` and `BackgroundParentImpl::AllocPRemoteWorkerControllerParent`~~ probably better catched inside `RemoteWorkerController::Create`, though I fear we lack a bit of error handling here, too - `ContentParent::RecvCloneDocumentTreeInto` - `nsFrameLoader::EnsureRemoteBrowser` and/or [some of its callers](https://searchfox.org/mozilla-central/query/default?q=calls-to%3A%27nsFrameLoader%3A%3AEnsureRemoteBrowser%27%20depth%3A4) - the `PreallocatedProcessManager` should stop to serve processes, too, which has been already addressed by bug 1795964. I assume that `XRE_SendTestShellCommand` and `nsIXULRuntime::EnsureContentProcess` should not check anything but just let the launching code assert at lower levels in case. These checks can probably go away (leaving just the assert in `AssertAlive`): - [`ContentParent::BeginSubprocessLaunch`](https://searchfox.org/mozilla-central/rev/270f0ed2146821e239232728adac41a3de41131b/dom/ipc/ContentParent.cpp#2594) - [`ContentParent::CreateBrowser`](https://searchfox.org/mozilla-central/rev/270f0ed2146821e239232728adac41a3de41131b/dom/ipc/ContentParent.cpp#1469) Remains the question if `ContentParent::GetNewOrUsedLaunchingBrowserProcess` should bail out, too, or just rely on the callers (and the `AssertAlive`). Note that there is a [shortcut that hands out a used process](https://searchfox.org/mozilla-central/rev/270f0ed2146821e239232728adac41a3de41131b/dom/ipc/ContentParent.cpp#1056-1067) there, too, and bug 1811746 shows this happens in the wild.
[Looking at the call paths to `BeginSubprocessLaunch`](https://searchfox.org/mozilla-central/query/default?q=calls-to%3A%27mozilla%3A%3Adom%3A%3AContentParent%3A%3ABeginSubprocessLaunch%27+depth%3A5) we should probably have regular checks also at: - ~~`SharedWorkerManager::MaybeCreateRemoteWorker` and `BackgroundParentImpl::AllocPRemoteWorkerControllerParent`~~ probably better catched inside `RemoteWorkerController::Create` - `ContentParent::RecvCloneDocumentTreeInto` - `nsFrameLoader::EnsureRemoteBrowser` and/or [some of its callers](https://searchfox.org/mozilla-central/query/default?q=calls-to%3A%27nsFrameLoader%3A%3AEnsureRemoteBrowser%27%20depth%3A4) - the `PreallocatedProcessManager` should stop to serve processes, too, which has been already addressed by bug 1795964. I assume that `XRE_SendTestShellCommand` and `nsIXULRuntime::EnsureContentProcess` should not check anything but just let the launching code assert at lower levels in case. These checks can probably go away (leaving just the assert in `AssertAlive`): - [`ContentParent::BeginSubprocessLaunch`](https://searchfox.org/mozilla-central/rev/270f0ed2146821e239232728adac41a3de41131b/dom/ipc/ContentParent.cpp#2594) - [`ContentParent::CreateBrowser`](https://searchfox.org/mozilla-central/rev/270f0ed2146821e239232728adac41a3de41131b/dom/ipc/ContentParent.cpp#1469) Remains the question if `ContentParent::GetNewOrUsedLaunchingBrowserProcess` should bail out, too, or just rely on the callers (and the `AssertAlive`). Note that there is a [shortcut that hands out a used process](https://searchfox.org/mozilla-central/rev/270f0ed2146821e239232728adac41a3de41131b/dom/ipc/ContentParent.cpp#1056-1067) there, too, and bug 1811746 shows this happens in the wild.