Proposal: let content scripts listen for event chrome.runtime.onUninstalled

[bershanskiy]

Problem

Context scripts continue running even after their extension is uninstalled or disabled, and they have no convenient way to be notified of these events to start their cleanup. I contribute to multiple extensions which need this functionality to prevent old context scripts from interfering with new context scripts after extension update.

Current workarounds

Right now, an extension content script can detect extension uninstall/shutdown by:

• registering a persistent port and waiting for its shutdown (port can be closed by either crash, extension uninstall or periodic shutdown)
• try to send a message from content script to background and get error that receiving end (background context) does not exist
• listen for chrome.runtime.onUpdateAvailable event (extension listens for this event, asks content scripts to clean themselves up, then installs update)

Workarounds 1 and 3 can be combined into one to achieve very precise notification timings if needed.

Proposal

Let content pages listen for a new event, chrome.runtime.onUninstalled. If we want to be very helpful, we can even supply a reason attribute, which can be disabled (extension was disabled), uninstalled (user completely uninstalled extension), or update (old version was uninstalled and a new version was installed in its place).

Response to security concerns

This problem was raised multiple times in the past and received responses like "notifying content scripts about extension shutdown is dangerous because the content script can retaliate against uninstalling and do something bad". I don't understand this argument, since clearly continuing to run an orphaned content script might be even worse.

[tophf]

Another workaround that doesn't depend on timing and seems reliable in my practice is to send a synchronous DOM message from the newly injected content script to the old orphaned one so it performs the cleanup, and then the new content script initializes. It's used in Stylus extension (search for orphan, there's just a few lines).

[bershanskiy]

Another workaround that doesn't depend on timing and seems reliable in my practice is to send a synchronous DOM message from the newly injected content script to the old orphaned one so it performs the cleanup, and then the new content script initializes. It's used in Stylus extension (search for orphan, there's just a few lines).

Yes, that is yet another workaround. I believe some closed-source extensions like Grammarly use it too.

[bershanskiy]

Relevant Chromium bug: 414213 created in 2014.

[rdcronin]

We discussed this at the WECG Meet-Up.

We agree this makes sense from a functionality point of view and are interested in exploring it more. The next steps here will be to write a concrete proposal, following the new steps outlined in the proposal process.

One note we highlighted during discussion is that we probably want to call this something other than runtime.onUninstalled, since the extension will likely want to know about other cases in which the extension is no longer active (disable, reload, etc).

[fregante]

we probably want to call this something other than runtime.onUninstalled

Linking a related proposal, the name might be onDisabled:

• Support onEnabled event when the extension from disabled state to enabled state #353