Handle unreliable timeouts/intervals
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 timeouts and intervals.
Note that the browser.alarms.*
API that is meant to be used for those cases may not be reliable enough for all use cases:
- https://bugs.chromium.org/p/chromium/issues/detail?id=471524
- https://bugs.chromium.org/p/chromium/issues/detail?id=1245934
Potential breakage:
- Ongoing icon animation doesn't finish.
- Local first-run page doesn't open after remote first-run page fails to open.
- Local first-run page opens after remote first-run page was opened.
- Icon text doesn't update when blocked counter is incremented.
- Day-1 notification isn't shown.
- Total blocked counter isn't saved persistently.
What to change
- Design: TBD
- Research: TBD
- Spec: TBD
- Legal: TBD
-
Development:
- Use
browser.alarms.*
API in the background page instead ofwindow.setInterval()
andwindow.setTimeout()
.- Intervals
- lib/devenvPoller:
doPoll()
(functionality can be removed altogether) -
lib/icon:(see #1190 (closed))animateIcon()
- lib/devenvPoller:
- Timeouts
-
lib/filterComposer:(only applies to Firefox)doInit()
- lib/init
listenForRemotePage()
-
(inconsequential and not possible due to closure)wait()
- lib/notifications:
initDay1Notification()
-
lib/prefs:(only applies to Firefox <66)customSave.set("blocked_total")
- lib/stats:
scheduleBadgeUpdate()
-
- Intervals
- Do not use
browser.alarms.*
API for intervals/timeouts that are less than 60s (see comment).
- Use
Hints for testers
See list of potential breakage under "Background".
Hints for translators
N/A