If a ServiceWorker registration is no longer tracked by the ServiceWorkerRegistrar (as persisted in PROFILE/serviceworker.txt) but the underlying Cache API storage wasn't also cleared, the storage will be effectively leaked. This doesn't impact privacy-related data clearing because the storage is still reported as used to all storage usage enumerations and is still cleared via all clearing APIs.

Until bug 1407621 is implemented, this operation ends up being conceptually rather high-level and somewhat complex to coordinate between QuotaManager space and ServiceWorker space. To this end it likely makes sense to implement this in JS in a class that can be reused by about:serviceworkers and unit tests to run self-consistency checks on demand.

In order to do this once per-profile using existing mechanisms most properly we'd likely want to bump either the serviceworker.txt (schema) version or introduce a QM minor version upgrade. Alternately, QuotaManager could be enhanced to store metadata for the ServiceWorkerManager in storage.sqlite, but that itself would entail a schema upgrade. The txt schema bump is most targeted but the registrar txt scheme doesn't support downgrades. The good news is this bug would fix the fallout of that.

We would want to do this due to situations where registrations can get dropped. This has historically been able to happen due to:

• User downgrades across schema version changes in serviceworker.txt dropping all registrations.
• Corruption of serviceworker.txt
• Maybe due to crashes during a ServiceWorker installation? There's no multi-phase commit across the registrar and the Cache API doesn't have built-in transactional semantics beyond addAll.
• Bug 1663125 (recent)

Note: At the team meeting I raised IndexedDB's conceptually similar Blob/File leaks we've witnessed for about:newtab in the past. IDB actually self-corrects for orphaned Blobs/Files in FileManager::InitDirectory by cross-correlating blobs at initialization time when getting origin usage. But we don't get usage for system-principaled origins like about:newtab that are inherently "permanent"

In bug 1678795 it appears that for origins like slack that have a large installed SW size could be running into quota limits that could be breaking things. Inclusive of Cache API usage rather than just the SW scripts and direct dependencies; per my analysis in https://bugzilla.mozilla.org/show_bug.cgi?id=1678795#c54 slack potentially has an aggregate quota usage of 4 * ~210 MB for usage of 800 - 900 MiB and will not self-heal on its own or realize the quota problem.

To this end the mitigation here and/or on bug 1668743 may need to consider automatic clearing of the origin for QuotaManager purposes in the event that there are orphaned ServiceWorkers and any indications of QM usage being near its limit. (And in general bug 1668743 or follow-ons may want heuristics that indicate when an installation fails due to quota exceeded reasons and clears the QM origin. Although it could also make sense for this to potentially also be a QM heuristic itself...)

Probably not a S2 (or P2)
Reminder, S2 means: (Serious) Major functionality/product severely impaired or a high impact issue and a satisfactory workaround does not exist