Ability to unload the background script from SW code [regression from MV2]

[tophf]

In MV2 it was possible to use window.close() in the background script of an event page ("persistent": false in manifest.json) to immediately unload the background page.

It allows freeing up memory when you are absolutely sure that there's no point in keeping the background context alive e.g. if the extension only uses chrome.alarms and doesn't listen to any other unpredictably occurring events. These are simple timer or scheduler extensions that wake up every X minutes to spend just a few milliseconds in the background script to do things like updating the badge/icon/title of the extension action icon or pinging a remote server or other maintenance.

The problem is that service workers don't have a terminate method available for normal dedicated/shared workers because SW is a special kind of worker for a web site, but since it doesn't serve this purpose in an extension this restriction is inappropriate [1]. If an extension wakes up every minute then a half of every minute will be wasted on keeping 20MB of an unused worker.

A possible solution would be to add something like chrome.runtime.terminateBackgroundScript().

P.S. I don't suggest reinstating terminate method inside ServiceWorker object because Chromium team has been against altering the web platform behavior for extensions, exemplified in its decision to add chrome.dom API.

Note [1]: It's inappropriate because extensions don't need specifically an SW to do their job, which is to process chrome API events (completely unrelated to SW specifics) or to show their chrome-extension:// pages (already local). It's one of the many inherent restrictions of the SW technology that's not suited for what extensions do, as we can see from #72 that lists a lot of similarly inappropriate restrictions.

[oliverdunk]

Beyond the use case of freeing up resources when your work is done, one thing we'd be really excited about at 1Password is the ability to reliably terminate our execution context when a user tries to "lock" our extension. We store lots of sensitive user data in memory and this would give us additional confidence that when a user is finished using the extension that data has been cleared.

[Rob--W]

@dotproto Please link the new issue in the SW repo or the thread/response once you've reached out to the spec or your platform folks.

[rdcronin]

I'm supportive of adding this functionality, but I think ideally we'd add it to the service worker spec instead of just for extension service workers.

We'll take an action item to talk to the service worker folks and see if there's appetite, but for triage, I'm removing the follow-up:chrome (which is mostly used for flagging issues that we haven't determined if we're supportive of).

[JWorthe]

Another use case that would be served by an extension API to unload the service worker is testing that an extension continues to work correctly in MV3 after the service worker stops and starts up again.

It would be nice to have an easy path to write a unit test which does the following:

1. The service worker starts up, adds event listeners, and does some work.
2. The service worker is suspended. <- This is currently difficult, and would be easier with some sort of terminate API.
3. The service worker is sent an event, and responds correctly.

See https://github.com/w3c/webextensions/issues/140 for a more full explanation of this use case.

[oliverdunk]

I've just filed an issue in the w3c/ServiceWorker repository to discuss this further: https://github.com/w3c/ServiceWorker/issues/1696