Make pinned tabs with ServiceWorker able to survive browser reload
Categories
(Core :: DOM: Service Workers, task)
Tracking
()
People
(Reporter: aiunusov, Unassigned)
References
Details
Attachments
(1 file)
According to https://bugzilla.mozilla.org/show_bug.cgi?id=1668743#c25:
At startup, when reading registrations:
Any registration that had been in the waiting state would be put into a special state such that the next functional event dispatched at the ServiceWorker will begin its process of activation. This will trigger explicit handling in "Handle Fetch" and "Fire Functional Event" to defer the events until activation completes which can result in some additional latency, but the spec issue already resulted in guidance being added that activation logic should endeavor to be minimal.
We could also use the above logic for retry attempts. If concerned about this causing an infinite browser crash loop, it would make sense to ensure the retry attempt count was incremented and flushed to disk prior to actually triggering the retry. The higher level logic that adds UI confirmation to session restore might moot the need for this, as would the need to trigger a fetch to trigger the problem. (And arguably anything the activate method might do, normal operation might also do. Although, push notifications I suppose do pose a separate problem for that... and I'm not sure we've seen problems like that?)
Any "old" Cache API script storage would be purged. We're always opting to move forward to the newly installed SW, so there's no point in keeping the old data around. Once purged, the registration would be updated to remove this old entry.
|
Reporter | |
Comment 1•19 days ago
|
||
|
|
Reporter | |
Comment 2•19 days ago
|
||
https://github.com/w3c/ServiceWorker/issues/1372#issuecomment-745438358
from the spec discussion back to 2020
|
|
Reporter | |
Comment 3•8 days ago
|
||
[asuth] So I think that’s all correct, but for specific impl thoughts, I think it’s: When we load the ServiceWorker registrations, if we have a registration with 0 attempted registrations, we put that SW in the waiting slot Then when we go to dispatch a functional event from the ServiceWorker, when we’re looking at the registration, we want to check: If there is a waiting ServiceWorker and there is an active ServiceWorker, and the active ServiceWorker is not running (and maybe we could add a flag that tracks whether we’ve ever dispatched a functional event at the registration since browser startup? Like mSpawnedSinceStartup)
Description
•