> However, re-reading the `ContentParent::MaybeBeginShutDown` code it seems to me, that if `aSendShutDown` is `false` we can end up starting our timer without having sent the `ContentParent::SendShutdown` at all ( [at least here in this function](https://searchfox.org/mozilla-central/rev/962a843f6d96283c45162c788dc72bf217fca7df/dom/ipc/ContentParent.cpp#1769) ) which would obviously perfectly explain what is going on.
I think we are always calling `NotifyTabDestroyed` (where `aSendShutdown` is true) after we called `NotifyTabDestroying`, so this seems to be ok, in principle.
However, as `ContentParent::MaybeAsyncSendShutDownMessage` dispatches an event to the parent's queue and only that event will then ask the child to shutdown, we might just see cases where the parent's main thread is so busy that we never execute the send before the timer kills the child. I think we should move the `StartForceKillTimer` very close to when we actually call `SendShutdown`.
Note that we will still `SignalImpendingShutdownToContentJS` early, such that the child process will hopefully stop to be (too) busy while waiting for the shutdown message. For that reason I'd propose to promote `dom.abort_script_on_child_shutdown` to be enabled everywhere.
Bug 1837467 Comment 9 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
> However, re-reading the `ContentParent::MaybeBeginShutDown` code it seems to me, that if `aSendShutDown` is `false` we can end up starting our timer without having sent the `ContentParent::SendShutdown` at all ( [at least here in this function](https://searchfox.org/mozilla-central/rev/962a843f6d96283c45162c788dc72bf217fca7df/dom/ipc/ContentParent.cpp#1769) ) which would obviously perfectly explain what is going on.
I think we are always calling `NotifyTabDestroyed` (where `aSendShutdown` is true) after we called `NotifyTabDestroying`, so this seems to be ok, in principle.
However, as `ContentParent::MaybeAsyncSendShutDownMessage` dispatches an event to the parent's MT queue and only that event will then ask the child to shutdown, we might just see cases where the parent's main thread is so busy that we never execute the send before the timer kills the child. I think we should move the `StartForceKillTimer` very close to when we actually call `SendShutdown`.
Note that we will still `SignalImpendingShutdownToContentJS` early, such that the child process will hopefully stop to be (too) busy while waiting for the shutdown message. For that reason I'd propose to promote `dom.abort_script_on_child_shutdown` to be enabled everywhere.