1779969 - Verify if the extensions shutdown could better happen after content processes' shutdown

Status: NEW

(Toolkit :: Add-ons Manager, task, P3)

Description

[Jens Stutte [:jstutte]]

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". Extensions broadcast shutdown messages to all children that the extension is going away and then waits for all of them to acknowledge the message.
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).

Comment 1

[Rob Wu [:robwu]]

(In reply to Jens Stutte [:jstutte] from comment #0)

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.

What do you mean by timeout? The broadcast implementation awaits the message OR the disconnecting message manager: https://searchfox.org/mozilla-central/rev/3e1a721bce1da3ae04675539b39a4e95b25a046d/toolkit/components/extensions/Extension.jsm#2717,2720-2722,2730-2732,2735-2736,2738-2740,2744-2745

... so the timeout logic here is not expected to kick in.

Comment 2

[Jens Stutte [:jstutte]]

(In reply to Rob Wu [:robwu] from comment #1)

(In reply to Jens Stutte [:jstutte] from comment #0)

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.

What do you mean by timeout? The broadcast implementation awaits the message OR the disconnecting message manager: https://searchfox.org/mozilla-central/rev/3e1a721bce1da3ae04675539b39a4e95b25a046d/toolkit/components/extensions/Extension.jsm#2717,2720-2722,2730-2732,2735-2736,2738-2740,2744-2745

... so the timeout logic here is not expected to kick in.

I find this message in my logs if I run the endless content JS test without the patch from bug 1777198 for each active extension.