Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce runtime.waitUntil API to keep background service worker / event page active during a specific task #416

Open
Rob--W opened this issue Jul 5, 2023 · 2 comments
Assignees
Labels
proposal Proposal for a change or new feature supportive: chrome Supportive from Chrome supportive: firefox Supportive from Firefox supportive: safari Supportive from Safari topic: service worker Related to service worker background scripts

Comments

@Rob--W
Copy link
Member

Rob--W commented Jul 5, 2023

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:

@Rob--W Rob--W added topic: service worker Related to service worker background scripts proposal Proposal for a change or new feature labels Jul 5, 2023
@xeenon xeenon added the supportive: safari Supportive from Safari label Jul 6, 2023
@Rob--W Rob--W added follow-up: chrome Needs a response from a Chrome representative supportive: firefox Supportive from Firefox labels Jul 6, 2023
@tophf
Copy link

tophf commented Jun 14, 2024

See also how the upcoming Progress Notification API deals with a similar concept (the first implementation won't have it though).

@Rob--W Rob--W self-assigned this Sep 28, 2024
@Rob--W Rob--W added supportive: chrome Supportive from Chrome and removed follow-up: chrome Needs a response from a Chrome representative labels Sep 28, 2024
@Rob--W
Copy link
Member Author

Rob--W commented Sep 28, 2024

There is consensus on capability of extending lifetime, with mitigations. I've taken the task to come up with a concrete proposal here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal Proposal for a change or new feature supportive: chrome Supportive from Chrome supportive: firefox Supportive from Firefox supportive: safari Supportive from Safari topic: service worker Related to service worker background scripts
Projects
None yet
Development

No branches or pull requests

3 participants