Open Bug 1426401 Opened 3 years ago Updated 3 years ago
Consider persisting waiting worker state to disk and triggering an activate event on/after next browser start
per discussion on IRC with bkelly relating to the phenomenon in bug 1426397, it can be the case that a ServiceWorker is installed and reaches the waiting state, but never makes it to the active state (before browser shutdown/crash-time). In such a scenario, we could fire an activation event at the worker sometime at/after next browser startup, although there are performance implications to worry about. And also perhaps some privacy concerns if an origin intentionally arranged to trigger this behavior. This could allow a tab to defeat Firefox's lazy tab-loading, for example. However, push notifications can also accomplish that, although at the cost of having to undertake active actions that could be detected.
Maybe the right thing to do here is: 1. Track waiting workers in the registrar file 2. On startup we mark these workers as "pre-activating" 3. If anything touches the registration (like navigating to the site or a push message, etc) then we move the worker to activating and fire the activate event. 4. We let our existing logic delay the functional event in (3) until activation is complete This would let us fire activation events properly without any startup performance penalty. The site would just have the small activation delay on first interaction after startup.
I noticed we have empty worker URL entries in serviceworker.txt and started looking at this issue as a result. This patch mostly does what we need. I don't think its safe, though, because with our current propagation we could end up firing the activation event in multiple processes or the parent process. We probably need e10s to be fixed first.
You need to log in before you can comment on or make changes to this bug.