Open Bug 1771203 Opened 8 months ago Updated 3 months ago

Tweak the lifetime and termination triggers of event pages / extension service workers

Categories

(WebExtensions :: General, enhancement, P3)

enhancement

Tracking

(Not tracked)

People

(Reporter: robwu, Unassigned)

References

(Depends on 2 open bugs, Blocks 2 open bugs)

Details

(Whiteboard: [addons-jira])

Event pages should be designed to account for sudden shutdown, to improve the user experience in cases where that's inevitable, e.g. process crashes by out-of-memory, the OS (Android), etc. (bug 1355239).

A time-bound lifetime forces the development of extensions that are resilient against terminations (which is positive), but being overly aggressive in terminating them degrades the user experience of extensions that lack alternatives, and of those where the startup is expensive. On the other hand, having an indefinite lifetime (or being able to extent the lifetime to that effect - bug 1748533) discourages the design of a resilient background script.

The current termination policy is (too) aggressive. We should tweak the lifetime and termination triggers/blockers.

As of writing, the termination of event pages/extension service workers in Firefox is as follows (with state transitions documented here):

  • After background startup, a timer is registered (default 30s, min 0.1s, max 300s)
    • This timer is reset when an extension event is received (source).
  • When the timer is reached, termination is requested (terminateBackground logic here)
    • If the devtools is open, the background is not suspended (source).
    • If there is an active StreamFilter, the background is not suspended (source).
  • runtime.onStartup is triggered, which may delay the shutdown by 5 seconds (source).
  • The background is terminated, and is reset for start up (when an extension event is triggered).

"This timer is reset when an extension event is received."

Are you planning to keep it this way? Chrome doesn't reset the timer when an event is received.

An extension can make Firefox generate events to stay alive indefinitely, for example:

browser.storage.onChanged.addListener((storage) => {});
function keepAlive() {
	browser.storage.local.set({keepAlive: true});
	setTimeout(() => keepAlive(), 15000);
}
keepAlive();

Chrome methods to keep a service worker alive indefinitely are far more inconvenient, like making a connection to a native application.

Many extensions need to have persistent background pages, event pages, or service workers because of performance and/or memory issues.
Allowing received events to reset the timer is very useful for extensions that aren't intended for Android. They can also still be
designed to be restarted (if there is a rare crash), even if they are never terminated.

Severity: -- → N/A
Priority: -- → P3

Last Friday, we discussed this bug.

Our primary objective behind suspensible/restartable background contexts (event pages / service workers) is to have extensions that are resilient against sudden termination. This is needed on Android, and to a lesser extent on desktop.

In Firefox's current implementation, the lifetime can easily be extended indefinitely (bug 1748533), which may interfere with the goal of having extensions that are resilient by design. I'm not against supporting extensions that really have these needs, but would like that to be more explicit, rather than through some wasteful work-arounds. For example, having stricter lifetime limits by default, plus an opt-in advisory entry in the manifest file (e.g. a permission as suggested at https://github.com/w3c/webextensions/issues/44).

Luca suggested to evaluate the possibility of moving the event page to the bfcache (instead of a full shutdown) to reduce the initialization overhead of event pages. While that doesn't help against sudden termination, it could reduce the cost/overhead of suspending/resuming event pages.

The next step here is for Luca to draft a document about the background's lifecycle / lifetime from where we can continue the discussion.

Depends on: 1800914
You need to log in before you can comment on or make changes to this bug.