How do we reload a broken extension service worker internally?

[Red ross]

Was looking into some workarounds for the ongoing issues with MV3 on Chrome where the worker stops receiving any events and remains stuck in a running state.

Issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1316588#c96

The workaround referenced in the issue works, i.e., detect and call chrome.runtime.reload and we have been seeing reports that the issue is occurring for users with the workaround reloading the extension behind the scenes.

However, using chrome.runtime.reload can lead to other issues such as content scripts getting disconnected, so i'm on the lookout for a safer way to reload the service worker.

Summarising the options:
- Use an infinite loop to force the worker to be killed and restart (From the workaround above).
- Use chrome.runtime.reload and unregister and re-register the content scripts / make them resilient.

A third option i'm exploring with the release of Offscreen documents is to inject an offscreen document that can then unregister and re-register the service worker combined with skipWaiting (so that it takes over immediately and doesn't get caught up in the other issue in MV3).

Questions:
- Are there any caveats I'm missing or new issues that would arise due to unregistering and re-registering the extension service worker?
- Are there other options that folks have explored and that have worked for them w.r.t the bug mentioned above.

[Cuyler Stuwe]

I honestly just wish that chrome.runtime.reload had more useful behavior w/r/t content scripts.

Why, for example, can’t we just automatically unregister Chrome API event listeners on orphaned content scripts? It’s not useful to me to see a barrage of error messages saying that I can’t connect to the extension; I get it.

Since the Chrome team is making such dramatic changes to extensions in general as part of the MV3 push, maybe we could add a key in the manifest that allows us to specify automatic re-injection of declarative content scripts on extension reload (rather than needing to reinit from the background programatically)?

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/31a39820-d757-4b2f-bf0a-28def1581ea1n%40chromium.org.

[Oliver Dunk]

Hi Red,

In general I wouldn't recommend against manual registration/unregistration of the extension service worker. I'm not sure that this is something which is intentionally supported and I suspect it may allow you to get in to bad, potentially hard to recover from states.

I definitely appreciate the hard spot you're in though. I don't have anything particular to recommend right now but I hope we can pin down this issue and get it fixed. I'll bring it up with the team again although I suspect we may be blocked on being able to reproduce it/the general elusiveness of the issue right now.

Sorry to not have more to share.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Red ross]

Thanks for the inputs! 

> In general I wouldn't recommend against manual registration/unregistration of the extension service worker. I'm not sure that this is something which is intentionally supported and I suspect it may allow you to get in to bad, potentially hard to recover from states.

True. Although, considering we've also observed cases where the service worker itself gets unregistered where there's no option but to re-register it.
That said, I realise that its a bit different when we unregister and re-register it manually.

Would really appreciate it if the Chrome team can revert on if this approach can be safely used or a way to reload the worker without chrome.runtime.reload in the interim until the fix for the core issue is out.
Thanks!

[wOxxOm]

> However, using chrome.runtime.reload can lead to other issues such as content scripts getting disconnected

FWIW, you can explicitly handle the orphaned content scripts, here's an example: https://stackoverflow.com/a/57471345. One inconvenience that remains is passing the internal variables from the orphaned content script to the new one in a safe way that cannot be intercepted by the web page or other extensions. You can generate a random id in the background script, store it in chrome.storage, read it in the content script at its start and save in a variable, then use it as an event name to pass data via CustomEvent messaging.

> In general I wouldn't recommend against manual registration/unregistration of the extension service worker. I'm not sure that this is something which is intentionally supported and I suspect it may allow you to get in to bad, potentially hard to recover from states

The internal registration mechanism is the same, so there shouldn't be any problems and so far this method seems to be the only one that actually solves the problem. While I guess your actual intention was to remind that workarounds sometimes may be worse than the problems they solve, but in general I wouldn't recommend making technical recommendations not based on technical knowledge or observable evidence, it only devaluates your credibility and further worsens the image of Chrome team for pushing ManifestV3 onto everyone despite its background script registration being randomly broken for more than a year with no proper fix in sight. I wonder what will happen if the team can't fix the bug, will they be able to re-enable the event pages just like the previous team did in the same situation in 2014?