Handle unreliable Messaging API communication ports for Manifest v3
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 need to make sure that we can handle unreliable connections to the background page that we use for listening to events.
Potential breakage:
- Changes (e.g. subscriptions, filters, preferences, blocked counter) are not reflected in the UI pages while they're open.
- Confirmation dialog isn't shown when clicking on a subscribe link.
- Requests and filter hits aren't included in issue reports.
- Blocked counter not updated in icon and icon popup.
Potential approaches:
- Listen to and broadcast all background page events to all UI pages and content scripts.
- Store and replay "*.listen" events, when service worker wakes up.
- Ask UI pages to reinitialize their listeners, when service worker wakes up.
- Automatically reconnect communication ports when service worker goes away.
Approaches (1), (2) and (3) all require keeping track of open UI pages via some session storage. However, the icon popup has no tab ID associated with it, with which we could reach out to it. Therefore approach (4) may be the simplest and most reliable approach left, even if it means that the service worker will continuously be woken up, as long as a UI page is open that listens to extension events.
What to change
- Design: N/A
- Research: N/A
- Spec: N/A
- Legal: N/A
-
Development:
- Attempt to automatically reconnect communication port in js/api.js whenever it gets disconnected.
- Automatically redispatch "*.listen" messages to restore event listeners.
- Replace
ext.onExtensionUnloaded
with an event that triggers only when the disconnect occurs due to the extension no longer being there.
- Attempt to automatically reconnect communication port in js/api.js whenever it gets disconnected.
Hints for testers
- Filter composer
- No obvious errors or breakage.
Only Manifest v3: Including after service worker shuts down. - No errors on page when extension gets unloaded.
- Filter composer cleans up when extension gets unloaded:
- Window closes
- Highlighted elements get unhighlighted
- If preview is active: Hidden elements reappear
- No obvious errors or breakage.
- UI pages: Changing extension settings (e.g. adding filters, removing filter lists, changing options) works and the new state is correctly shown in the UI.
Only Manifest v3: Including after service worker shuts down. - Issue reporter: Filter hits continue to be recorded in issue report data.
Only Manifest v3: Including after service worker shuts down. - Only Manifest v3: See list of potential breakage under "Background".
Note that "extension gets unloaded" refers to the extension being disabled or uninstalled. It does not refer to the service worker being suspended or terminated.
This change does not affect the communication between the developer tools panel and the extension, because it doesn't use the same communication channel as all our other UI pages. We're going to change that in #1086 (closed).
Hints for translators
N/A