Re: [w3c/ServiceWorker] [Feature request] Allow keeping service worker alive (#1558)

I've [commented](https://github.com/w3c/ServiceWorker/issues/1556#issuecomment-748319193) in the initial issue that seems to be motivating the implementation reasons that lead to this request.

If your app needs a large amount of durable storage and the user understands that, please use [navigator.storage.persist](https://developer.mozilla.org/en-US/docs/Web/API/StorageManager/persist) and this will exempt you from storage limitations on Firefox to the maximum extent possible.  Across supported browsers it will help avoid incidental eviction of the data as well.

I hear you on the telemetry about storage stability and reliability.  Our number one focus on the Firefox Workers & Storage team is improving the reliability of storage and we've been refactoring much of the code-base to improve error handling and to generate telemetry data which can let us understand where things are failing in the field and address those problems.  This is something where improvements are actively happening and have been happening, so I don't think it makes sense to give up on storage.  Additionally, as @wanderview notes, Service Worker scripts themselves are stored in Cache API storage in Firefox, so you're pretty much already guaranteed to have working storage if you have a ServiceWorker in Firefox.  (And if you have a broken IDB database, if you delete it and then re-open it, the next one is guaranteed to be unbroken unless there are hardware problems.)

I'm in broad agreement that the right course of action is to explicitly store the data in storage.  Firefox is explicitly pursuing tab unloading like I believe some other browsers already do, and it is likely far better in the tab unloading accounting for your app's resources to be charged against disk quota rather than memory usage.

Also, I should note that the HTTP cache in Firefox I think tends to not bother storing large resources, so if you're using Blobs for everything and induce an OOM, the user will likely have to re-download everything again when the reopen the tab, which may lead to another OOM, etc.  These kinds of crashes are usually not actionable when we look at crash reports, whereas we can and do respond to bugs reported against Firefox's storage implementations, etc.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1558#issuecomment-748330373

Received on Friday, 18 December 2020 21:34:49 UTC