Don't add event listeners asynchronously
Background / User story
Manifest v3 forces us to run our background scripts in a service worker, which can be suspended/terminated at any time. Therefore we have to make sure that we add all event listeners synchronously, or they may not be called when the service worker activates.
Potential breakage:
-
Icon changes not applied (incl. when switching tabs during ongoing icon animation).(see #1276 (closed)) - Developer tools panel becomes unreactive.
-
Filter composer window is not being initialized.(see #1275 (closed)) -
Filter composer window doesn't close when the tab closes.(see #1275 (closed)) -
Unable to determine whether remote first-run page has failed or successfully loaded, in order to fall back to local first-run page.(see #1217) -
No new tab is created in response to "newtab"-type notification, even after opening a new empty tab.(see #1190 (closed)) -
Clicking on notification or a button in the notification has no effect.(see #1190 (closed)) -
Notification is not being dismissed when it's being closed.(see #1190 (closed)) -
Settings page opens in a new tab, despite it already being open in a different tab.(see #1277 (closed)) -
Confirmation dialog isn't shown in settings page after clicking on a subscribe link.(see #1277 (closed)) -
"Show useful notifications" option in settings page isn't highlighted when clicking on "Configure notification settings" button in notification.(see #1277 (closed)) - Changes to stored preferences (incl. "notifications_ignoredcategories" preference) aren't propagated throughout the extension.
-
Language recommendation feature doesn't show any notifications.(see #1190 (closed))
Identifying problematic event listeners:
- Where are
browser.*.addListener()
APIs used? - Where are
ewe.*.addListener()
APIs used? - Does the browser run code in those places again when the service worker wakes up? (see further information below)
- Are those short-lived listeners?
- Is it listening to an event that is expected to occur in response to an action that immediately follows the creation of the listener (incl. doesn't wait for a user action)?
e.g. creating a new tab and waiting for it to finish loading - Does it remove itself after it was called?
- Is it listening to an event that is expected to occur in response to an action that immediately follows the creation of the listener (incl. doesn't wait for a user action)?
What to change
- Design: TBD
- Research: TBD
- Spec: TBD
- Legal: TBD
-
Development: Adjust code to add all event listeners synchronously:
-
browser.*.addListener()
-
lib/pages/options:(see #1277 (closed))showOptions()
determine whether settings page has loadedruntime.onConnect
tabs.onRemoved
tabs.onUpdated
-
lib/browserAction(see #1276 (closed)):setBadge()
/setIconImageData()
/setIconPath()
/toggleBadge()
-
tabs.onReplaced
fallback for prerendered tabs
-
-
lib/devtools: "requests.listen:reset"(auto-reinitialized by messaging API)webRequest.onBeforeRequest
-
lib/filterComposer(see #1275 (closed)): "composer.openDialog"-
tabs.onRemoved
notify composer window that tab was closed -
tabs.onUpdated
determine whether composer window has loaded
-
-
lib/init:(see #1217)openFirstRunPage()
determine whether remote first-run page has loadedwebNavigation.onDOMContentLoaded
webNavigation.onErrorOccurred
webRequest.onCompleted
-
lib/notificationHelper:(see #1190 (closed))openNotificationInNewTab()
determine whether empty tab was openedtabs.onCreated
tabs.onRemoved
tabs.onUpdated
-
-
ewe.*.addListener()
(assuming that EWE doesn't remember listeners that were registered asynchronously)- lib/devtools
-
"requests.listen:hits":(auto-reinitialized by messaging API)reporting.onBlockableItem
-
- lib/filterConfiguration
-
"filters.listen:added":(auto-reinitialized by messaging API)filters.onAdded
-
"filters.listen:changed":(auto-reinitialized by messaging API)filters.onChanged
-
"filters.listen:removed":(auto-reinitialized by messaging API)filters.onRemoved
-
"subscriptions.listen:added":(auto-reinitialized by messaging API)subscriptions.onAdded
-
"subscriptions.listen:changed":(auto-reinitialized by messaging API)subscriptions.onChanged
-
"subscriptions.listen:removed":(auto-reinitialized by messaging API)subscriptions.onRemoved
-
- lib/devtools
-
Hints for testers
See list of potential breakage under "Background".
Hints for translators
N/A
Further information
See also ui#1070 for information on which code is run on service worker activation.
Edited by Thomas Greiner