1802545 - Enhancement: add runtime info that explains why an extensions event page or service worker started in Manifest v3

Status: RESOLVED INVALID

(WebExtensions :: Untriaged, enhancement)

Description

[anon]

Steps to reproduce:

An extension might want to perform a different set of tasks depending on how a service worker was started.

Currently, the following events can be helpful:

runtime.onInstalled (triggered on an install, update, or reload)
runtime.onStartup (triggered on a profile startup that has the extension installed)
management.onEnabled (triggered when an extension is enabled)

When storage.session is implemented, data can be saved in it to track if a service worker is resumed/awakened, as the stored data only lasts during the current session. If there is no data in storage.session, then one of onInstalled, onStartup, or onEnabled will fire or will have fired.

My main concern is management.onEnabled requires the "management" permission. Trying to determine if an extension was started though enabling it without using management.onEnabled requires checking for an event that might not happen (onInstalled or onStarted). I'm not sure the best way to determine if an event won't fire, especially on a slow profile startup.

Ideally, there would be a property similar to runtime.OnInstalledReason that would explain why the service worker was started. It could be named something like runtime.onStartedReason and could contain one of the following values in some form:

enable
install
profile start
resume
update

This would provide a simpler and faster way to understand why a service worker started. It wouldn't require waiting on any events or promises and would need less permissions. Alternatively, a runtime.onEnabled event could be added so the "management" permission would not be necessary.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Rob Wu [:robwu]]

What's the use case for the request here?

It sounds like an implementation of storage.session may cover your use case. We intend to implement that API relatively soon (bug 1687778).

Comment 3

[anon]

Sorry, I made a mistake submitting the enhancement request... The storage.session api will be adequate for my use case.