Extension Service workers and (limited) event pages are terminated when they are idle for a period of time. The mechanisms for determining the termination triggers vary by browser version *, and extensions do currently not have an explicit mechanism to extend the lifetime until the completion of a specific task. This is a proposal for the runtime.waitUntil method to do so.
* Chrome used to terminate service workers after 5 minutes, until recently when that restriction was lifted : extensions can extend their service worker's lifetime when they are actively calling extension APIs or handling events, and even some web platform APIs (see history of changes by Chrome version). The advantage of integrating the lifetime in specific web platform APIs is greater control by the browser. The downside is that the set of lifetime-extending APIs is seemingly arbitrary and the expected behavior cannot easily be determined (e.g. by developers or code reviewers).
On to the proposal:
- Add a
runtime.waitUntil method, modeled after the ExtendableEvent's waitUntil method.
- It extends the lifetime of the background context until the completion of the task, observed through settling the promise.
- We can consider additional restrictions to avoid accidental or intentional long-lived contexts. For example:
- a (default) deadline after which
waitUntil stops blocking termination.
- restricting the API to specific control flows, e.g. from an extension event.
- requiring justification in the API call for keeping the background alive. This could be embedded in a profiler annotation or the developer console to help with diagnosing unnecessarily long-running tasks.
Related discussions / bugs:
- Firefox: Bug 1781265 - Consider introducing a new WebExtensions waitUntil API method
- Comment on a Chromium issue at https://bugs.chromium.org/p/chromium/issues/detail?id=1446810#c3
- Earlier WECG discussion:
|
* [simeon] [Addition to known issues page](https://developer.chrome.com/docs/extensions/mv3/known-issues/#sw-fixed-lifetime): comment indicating that we're looking at the SW lifetime and considering an event-based approach rather than a fixed time. There is a lack of a event.waitUntil method to extend lifetimes. |
|
* [rob] FYI: Firefox was exploring a `brower.runtime.waitUntil` method - https://bugzilla.mozilla.org/show_bug.cgi?id=1781265 |
|
* [rob] In Firefox we're already taking an event-based approach. As long as there's useful activity, we'll keep the background alive. |
|
* [timothy] Also supportive of exploring waitUntil in extensions. |
Extension Service workers and (limited) event pages are terminated when they are idle for a period of time. The mechanisms for determining the termination triggers vary by browser version *, and extensions do currently not have an explicit mechanism to extend the lifetime until the completion of a specific task. This is a proposal for the
runtime.waitUntilmethod to do so.* Chrome used to terminate service workers after 5 minutes, until recently when that restriction was lifted : extensions can extend their service worker's lifetime when they are actively calling extension APIs or handling events, and even some web platform APIs (see history of changes by Chrome version). The advantage of integrating the lifetime in specific web platform APIs is greater control by the browser. The downside is that the set of lifetime-extending APIs is seemingly arbitrary and the expected behavior cannot easily be determined (e.g. by developers or code reviewers).
On to the proposal:
runtime.waitUntilmethod, modeled after the ExtendableEvent's waitUntil method.waitUntilstops blocking termination.Related discussions / bugs:
webextensions/_minutes/2022-12-08-wecg.md
Lines 98 to 101 in 18c60c2