Spec how extendable events are given time to execute

[jakearchibald]

Certain events allow the service worker time to execute, after which it should be shut down, even if there's work pending (to preserve ram, battery, and privacy).

The service worker shouldn't be able to give itself extra time to run, as it would be able to keep itself open indefinitely.

To solve this, we should spec something like:

---

A ServiceWorkerGlobalScope has a set of keepalive handles, each has:

• An expiry time.
• A no-clients expiry time.

These handles are added as an optional part of dispatching an ExtendableEvent. They'd only be added by event dispatches that should give the service worker time, such as a fetch/postMessage from a page or a client that depends on a page to be alive (worker, shared worker, worklet etc etc), or a background activity event.

The service worker checks the keepalive handles periodically, and compares the current time to the expiry time (if there are open clients) or the no-clients expiry time (if there are no clients). If the current time has passed that time, the handle is removed.

All items in keepalive handles can be removed if all lifetime promises in every ExtendableEvent in the global have become settled.

If the keepalive handles set becomes empty, the service worker is terminated regardless of ongoing work.

The keepalive handle state can be mutated, for situations where the expiry times need to be changed during the life of the handle. Eg, we might reduce the expiry time of a handle associated with a fetch once the fetch is complete.

In this model, if the service worker postMessages itself, it won't create a new keepalive handle. This event can add lifetime promises, but it doesn't extend the expiry time of any handles.

[shaun-wild]

@jakearchibald It would be nice if it were possible to add custom keep-alive handles, for long-running tasks triggered on a service worker.

[jakearchibald]

What's your use-case for this? We deliberately don't want the service worker to stay alive long term, and absolutely not if there are no pages open to the origin.

[navels]

My use case: I have a personal Chrome extension (loaded locally only) that, when clicked, queries DynamoDB for a list of URLs and then opens each URL in a new tab in turn (up to some limit of total open tabs). Into each tab is injected a content script that scans the page and most likely closes the tab. Tabs that are left open I visually inspect when I get around to it.

This works great in Chrome Manifest Version 2, where I can make the extension's background script persistent and so run exactly as long as I need it to (until it has handled each URL). Sometimes this is less than 5 minutes, great. Otherwise, it's pretty annoying.

[asakusuma]

Here's another use case for providing a way around limiting time: #1182

I am definitely in favor of speccing a mechanism for preventing runaway service worker events/tasks, though more as a safety net for a bug.

[dotproto]

The specific issue @navels raises is, arguably, an issue with Chrome's extensions platform rather than the service worker spec. That said, as other browser vendors consider adopting Manifest V3 changes (e.g. Firefox blog, issue) and the WECG attempts to specify a common extensions platform, this begins to seem like more a of a web platform issue.

At first blush, the model @jakearchibald sketched out in his original post seems like it could be flexible enough for extensions implementers. In particular, the suggestion that …

All items in keepalive handles can be removed if all lifetime promises in every ExtendableEvent in the global have become settled.

If the keepalive handles set becomes empty, the service worker is terminated regardless of ongoing work.

… may provide the tools necessary to address the sharp edge created by the forceful termination of service workers in Chrome's current implementation.