The tentative plan is indeed to use temporary disk storage that's encrypted so that in the event of a browser crash the data will remain unreadable. We're starting with IndexedDB support for this mode of operation and bug 1639542 is the meta-bug for that. This is a longer term effort.

Just chiming in with another motivating example: VS Code. On web, VS Code uses service workers sort of like virtual servers which power our webviews, so they are a core part of our product and not just a nice to have capability.

You can see this issue in VS Code for web by following these steps:

1. In a private window
2. Go to https://vscode-web-test-playground.azurewebsites.net
3. Open the image file in the explore (file.jpg) and see that nothing is shown. The root cause is that service workers are unavailable.

We don't believe there is a workaround for cases were service workers are unavailable, so we instead show an error message to users suggesting that they switch out of private/incognito mode

Adding another example, quite similar to the VSCode one in the previous comment.

For https://github.com/google/playground-elements (used at e.g. https://lit.dev/playground/) we use Service Workers to host a virtual server for live previews of code written by the user.

One of the advantages to using a Service Worker for this kind of use case, as opposed to a traditional backend, is that it doesn't require any of the user's input to leave the browser. It's unfortunate (and a bit ironic) that we may need to implement a fallback traditional server that would require sharing more user data, only for the incognito case.

Also note https://bugzilla.mozilla.org/show_bug.cgi?id=1601916 appears to be a duplicate of this issue.

This is possibly related to https://bugzilla.mozilla.org/show_bug.cgi?id=1755167

In non-private mode, when the "Delete cookies and site data when Firefox is closed" is checked, service workers also fail to register (though curiously, navigator.serviceWorker is still present).

This is an important feature: service workers are everywhere now, the lack of it in private mode makes firefox less relevant for browsing.

For OIDC authentication, service workers are a pretty secure solution (probably the most secure one), and this bug is really getting in the way.

Can the priority be raised?

FYI, there is now a "known issue" added for Firefox at https://caniuse.com/serviceworkers . This is a serious issue, SWs are used on a lot of sites.

Hello, my 2 cents, I want my users to use Cache API so they can store some personal data on their device instead of storing those informations on my server. (which means more privacy and control for them)

It works fine on Chrome/Edge/Safari private modes even if it less performant than in regular mode as the cache needs to be rebuild from scratch every time they close the site.
But with Firefox, it does not work at all and I don't want to use localstorage which is too limited.

So for now, I advise my users to use another browser if they want private mode (and explain them what private mode is about)

We will need bug 1837276 addressed in order to ensure that all ServiceWorkers are torn down promptly. And in fact, if we don't add coverage in that bug that verifies that the Service Workers have all been terminated (via non-public-WPT because of internal checks), we should add it here or in a specific SW PB bug to ensure that the globals have ben torn down as part of the process.

While there notionally exist a few content-space mechanisms for detecting the termination of a global (WebLocks, errors/closures propagated through streams), they aren't suitable for the PB case because in general we'd also be tearing down any other global in the PB OriginAttribute transitive closure graph, plus potentially explicitly tearing down the origin in the PBackground "daemons" that might coordinate (ex: WebLocks). Probably the most practical approach is to:

• create a system JS helper that can provide a defined contract but allows us to change the implementation later on to be more efficient
• The most comprehensive approach right now might be to cause system JS code to be run in every process that enumerates all the available nsIWorkerDebuggers and ensures that none exist with a PB principal.
• A more efficient thing we could do is rely on the RemoteWorker logic to confirm that there are no live RemoteWorkers with a PB OriginAttribute. However, that logic is authoritative on PBackground, not the main thread right now (although I think we largely do want to change this).
• But a proxy for both things could just be to assert that there are no content processes alive covering a PB originattribute. Because the RemoteWorker infrastructure keeps the content processes alive while it wants to keep a worker alive, verifying there are none of these processes effectively verifies that the RemoteWorker infrastructure did tear down all of the workers in question.
  • Note that this is orthogonal to the structural concern about race conditions related to nsIClearDataService and epochs I raise in https://bugzilla.mozilla.org/show_bug.cgi?id=1776271#c5 (and previously). StorageKey would continue to be our plan to address this in Workers & Storage space.

Not too important, but another use case is that this removes another vector used to detect private browsing and interfere with/based on user preferences.

Hello,
I need this feature to be able to run automated tests on Firefox.
Some features of our product won't work without it.

Thank you!