[meta] Adapt WebExtensions APIs to support suspendible extension contexts
Categories
(WebExtensions :: Frontend, task)
Tracking
(Not tracked)
People
(Reporter: rpl, Unassigned)
References
(Depends on 3 open bugs, Blocks 2 open bugs)
Details
(Keywords: meta)
Under this meta issue are going to be grouped the sub-tasks needed to adapt the existing WebExtensions APIs to extension contexts that can be "suspended" while the extension is enabled (like the manifest v3 background service worker, or the manifest v2 non-persistent background page, known on chrome as "event page").
As an example of the kind of work needed on the existing APIs, the menus/contextMenus API would need at least the following changes:
-
in the menus.create API method, which takes an id parameter, this parameter is currently optional, but it should be mandatory for suspendible extension contexts (as it is what makes the API able to recognize when a certain menu item was already created before the extension context is being suspended and then wake up in response of a received event).
-
the menus API events should be persisted and replaced with "primed listeners" when the extension context has been suspended (so that the "primed listener" will be able to receive the events while the extension context is gone, and then wake up the context and fire the pending events received in the meantime).
Reporter | ||
Updated•6 years ago
|
Reporter | ||
Updated•6 years ago
|
Comment 1•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Updated•3 years ago
|
Description
•