User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36

Steps to reproduce:

1. Open Service Worker Demo URL: https://mdn.github.io/sw-test/
2. Check registered Service Workers in about:debugging#/runtime/this-firefox
3. Service Worker for https://mdn.github.io/sw-test/sw.js is shown
4. Close Browser and start it again
5. Check registered Service Workers in about:debugging#/runtime/this-firefox
6. Service Worker for https://mdn.github.io/sw-test/sw.js is NOT listed anymore, Service Worker ist deleted.

When I downgrade to Firefox 79 the problem does not occur

Actual results:

Service Worker for https://mdn.github.io/sw-test/sw.js is not listed anymore, Service Worker ist deleted.

Expected results:

Service Worker for https://mdn.github.io/sw-test/sw.js should be shown still shown after restarting Firefox

I can also recreate this behaviour.
I used https://airhorner.com

The Service Worker is deleted when Firefox is restarted.

Hi,

Thanks for the details. I was able to reproduce on windows 10 pro, on the following versions

Firefox nightly 82.0a1 (2020-09-08) (64-bit)
Beta 81.0b7 (64-bit)
Release 80.0.

I will move this over to a component so developers can take a look over it. If is not the correct component please feel free to change it to an appropriate one.

Thanks for the report.

Best regards, Clara.

Hello,

thanks for confirming the problem.

Can somebody increase the priority on this bug? Because we have a customer which uses Service Workers for a critical business application and would need a solution for this soon.

Best regards,
Gerald

Hello!
Bisected with mozregression on Windows10x64 and here is the full pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f0ac79e1ed53bbdc5f0b470f6889ebfcc05fa550&tochange=efa2336315eda0aaf78c2e94d6c9c98106ea136b.

While bisecting furthermore I get this pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2b880e8d9143fee7badb103f965d461a4c1ceae8&tochange=fbcb0ee2d17a21e2065daf9b5186f3e51ab97613 with bug 1609920 as a possible regressor.

Attached the two pushlogs because the issue is intermittent sometimes.

It appears there is a rogue return in https://hg.mozilla.org/mozilla-central/rev/f567e48e5957#l6.56 in bug 1609920.

:rpl has a fix at https://phabricator.services.mozilla.com/D90189 but something went wrong so it's not showing up on this bug.

Hello,

I would ask for clarification: The bug will not be fixed in Firefox 80? Because tracking status "wontfix" ist set for "firefox80" - or am I misinterpreting something?

Is there some workaround for this bug?

Because I am not sure if I was clear enough in my bug description: The problem is not only that after closing Firefox the Service worker is not listed in about:debugging#/runtime/this-firefox anymore - furthermore it's completely deleted from Firefox. So the application DOES NOT work OFFLINE anymore. I used the demo application at https://mdn.github.io/sw-test/ because it is accessible for everybody - but I think every offine application using Services Workers will have stopped working starting from Firefox 80.

So I wonder, is there anybody out there who can use OFFLINE applications using Service Workers with Firefox 80?

(In reply to Gerald Spitzer from comment #7)

Hello,

I would ask for clarification: The bug will not be fixed in Firefox 80? Because tracking status "wontfix" ist set for "firefox80" - or am I misinterpreting something?

Is there some workaround for this bug?

Hi Gerald, just a word on our release process: We do approx. 4-weekly releases of the normal firefox. During these few weeks of lifetime of a release we only make so-called dot-releases if something very bad happened (usually rated by our bug triage as S1). Thus "wontfix for FF 80" just means, it will appear in one of the next releases. The only versions that get longer support are the versions marked as ESR. But as this is a regression that appeared first in FF 80 and our current 78 ESR is not affected. Until the bug is fixed, a local workaround could be to install ESR (which I totally understand is not a good one for most normal users, of course).

Thanks for your support

Per discussion with Andrew, let's make sure this gets into the RC2 build of 81.0.

(In reply to Gerald Spitzer from comment #7)

So I wonder, is there anybody out there who can use OFFLINE applications using Service Workers with Firefox 80?

Firefox 81 ships next week. Our plan is to include this fix in it.

Analysis

tl;dr: Bug 1665197 tracks implementing cleanup logic that will address all fallout from this bug (and correct storage leaks that profiles might have previously encountered due to profile downgrades and inopportune crashes).

Context:

• The authoritative list of ServiceWorker registrations is maintained in the ServiceWorkerRegistrar which is responsible for loading the contents of PROFILE/serviceworker.txt at startup and re-writing it whenever the list of registrations is changed at runtime.
• ServiceWorkerManager receives the list of registration at startup, populating its own internal state representation.
  • This representation serves as the source-of-truth for about:serviceworkers, about:debugging, and ServiceWorker interception.
• Changes happen as individual deltas sent from the singleton parent-process main-thread ServiceWorkerManager over the PBackground-managed PServiceWorkerManager.
• Privacy clearing of registrations happens via ServiceWorkerCleanUp.jsm which operates based on the exposed list of registrations via nsIServiceWorkerManager. (Bug 1407621 tracks moving the registration storage into QuotaManager which will obsolete this mechanism.)
• Origin usage as tracked by QuotaManager and reported to privacy and site data APIs does not operate based on the ServiceWorker registrations but instead based on QuotaManager usage. (And it's inherently the case that valid ServiceWorker registrations consist of a registration stored by the ServiceWorkerRegistrar plus Cache API storage backed by QuotaManager.)
• ServiceWorkers are not allowed to be registered when an origin's persistence is set to session.

Concerns:

• Effectively leaked storage usage: Is storage related to a ServiceWorker that is no longer associated with a usable ServiceWorker registration still taking up disk space in the user's profile that will remain until explicitly handled by new logic or cleared by origin clearing for storage pressure or privacy reasons?
• Privacy: Did user actions to clear an origin that appeared to fully succeed not fully succeed? If so, what is the level of data that remains that should not remain and what options are available to mitigate.
• What works?:
  • Will ServiceWorkers that previously worked prior to bug 1609920 in Firefox 80 still work?
  • Will ServiceWorkers installed during use of bug 1609920 impacted builds in Firefox 80 still be installed and work in the fixed Firefox 81?

Core Analysis:

• The bug resulted in the ServiceWorkerRegistrar loading all existing registrations from disk but ServiceWorkerManager not loading the registrations into its internal state.
• If a user browsed to an origin that should have had a ServiceWorker registered, it would be as-if the ServiceWorker had never been registered.
  • The site could successfully re-register a ServiceWorker so offline behavior would work for the rest of the session, but an attempt to use a ServiceWorker in an offline fashion after restart wouldn't work. However, any storage used by the ServiceWorker would still be there, so as long as the ServiceWorker's "install" step doesn't clear pre-existing offline data, any other offline data would be retained.
  • The logic in ServiceWorkerRegistrar::RegisterServiceWorkerInternal would end up replacing the previously existing registration when the registration is called.
    • This will result in the previous Cache API storage for the old registration's ServiceWorker to continue to exist but no longer have a registration.
• The net result is that the set of ServiceWorkers listed in serviceworker.txt will be the union of its state from Firefox LastGood=79 plus all subsequent runs under Firefox FirstBroken=80 and these will be visible and operable in Firefox FirstFixed=81.

Concerns Analysis:

• Storage Leaks: Yes, for any redundantly installed ServiceWorkers, we expect each new install to clobber the last and use storage. Bug 1665197 covers fixing this. Until that is fixed, existing mechanisms for origin clearing upon storage pressure will work.
• Privacy:
  • ServiceWorker registrations that should have been cleared by data clearing operations will not have been cleared. Bug 1665197 will correct this by removing the registrations. Any data clearing operations that happens going forward will properly clear the registrations. Any attempt to use the registration that results in spawning the ServiceWorker will fail and automatically clear the registration.
    • The registrations will be visible in about:serviceworkers and about:debugging, but won't cause the origin to show up in the origin UI.
  • Because the registration includes the origin and installation timestamp, it potentially acts as something analogous to a history entry, but does not convey user-intent because ServiceWorker installation can occur due to 3rd party iframes.
• What Works: Any ServiceWorker that previously worked should continue to work. The exception is cleared origins which may continue to have a registration which will self-heal by removing itself after a single failed interception. (Which, at the current time will result in a corrupt content UI but will be fixed by refreshing the page.)

https://hg.mozilla.org/mozilla-central/rev/478e4e145ab3

Is this ready for a release approval request? Please do so ASAP.

Comment on attachment 9175724 [details]
Bug 1663125 - Fix registered service workers missing after restart and cover it with a marionette test. r?asuth!,whimboo!

Beta/Release Uplift Approval Request

• User impact if declined: ServiceWorker registrations won't load from disk at startup. See comment 13 for in-depth analysis.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: Bug 1665184
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is a minor-control flow fix, see comment 13 for in-depth analysis.

Note that as discussed with :RyanVM previously, there was some expected risk around the automated test's stability and that has been addressed in bug 1665184 which also needs its fix to land, but the Gecko logic fix itself is very low risk.

• String changes made/needed: none

(I was slated to make the uplift request but the plan was to wait for the test fix to hit central. Clearing Luca's needinfo.)

I verified that the fix corrects the problem in my local nightly. Specifically, about:serviceworkers included a limited subset of ServiceWorkers prior to applying the update. After applying the update and restarting Firefox, all the missing ServiceWorkers were back.

Comment on attachment 9175724 [details]
Bug 1663125 - Fix registered service workers missing after restart and cover it with a marionette test. r?asuth!,whimboo!

Approved for 81.0rc2.

https://hg.mozilla.org/releases/mozilla-release/rev/bd2f6e100a21