Add Unregister Service Workers algorithm for use by other specifications

[monica-ch]

Part of #1846.

This introduces a new exported algorithm — a stable public surface that external specifications can bind to.

Change

Adds an exported Unregister Service Workers algorithm so other specifications such as FedCM and Payment Handler can schedule unregistration of all service worker registrations for a storage key.

Algorithm

Input: storage key
Output: none

The algorithm:

1. collects the serialized scopes whose storage keys compare equal to the input;
2. parses each scope URL; and
3. creates and schedules an unregister job for each valid scope.

Collecting the scopes before scheduling avoids iterating the registration map while unregister jobs can modify it.

Completion contract

The algorithm is intentionally fire-and-forget. It does not wait for the unregister jobs to finish, so matching registration-map entries might still exist when it returns.

Waiting for the jobs would only guarantee removal from the registration map. It would not guarantee physical destruction: Clear Registration can remain delayed while a client uses the registration or the registration's workers have pending lifetime work.

This matches the current FedCM teardown model, which stops dispatching to the identity handler when its declaration is removed and allows the registration itself to be removed asynchronously. Clear-Site-Data similarly invokes service worker unregistration without waiting for its promise.

Adoption implications

• FedCM (Add initial Identity Handler SW Registration Tie In. w3c-fedid/FedCM#842) and Payment Handler can use this instead of depending on non-exported job algorithms.
• The operation applies to every registration whose storage key equals the input.
• Callers needing stronger coordination cannot treat return from this algorithm as confirmation of removal.

Related

• Export SW primitives needed by FedCM and Payment Handler for JIT registration #1846 — umbrella issue
• Add initial Identity Handler SW Registration Tie In. w3c-fedid/FedCM#842 — motivating PR
• Add Request Soft Update algorithm for use by other specifications #1847 — Request Soft Update
• Add Register a Service Worker algorithm for use by other specifications #1848 — Register a Service Worker

---

Preview | Diff

[monica-ch]

@yoshisatoyanagisawa CYTAL, thanks!

[yoshisatoyanagisawa]

The algorithm reminds me Clear-Site-Data: "storage" (https://w3c.github.io/webappsec-clear-site-data/#clear-dom). Overall looks good to me, but let me ask if we need to allow callers to ensure the removal or not.

[monica-ch]

Thanks @yoshisatoyanagisawa. I investigated the completion question and kept this fire-and-forget.
Ordinary unregistration completion only confirms that the registration is no longer available for matching; full clearing can remain delayed while clients or lifetime work still use it. Chromium similarly has a separate  DeleteForStorageKey  operation for callers such as storage clearing that require stronger deletion guarantees.

FedCM only needs to stop dispatching when the declaration disappears and permits cleanup to happen asynchronously, so ordinary bulk unregistration appears sufficient here.

@Brandr0id, could you confirm that this asynchronous contract works for the FedCM identity-handler teardown path?
If another caller needs durable storage-deletion semantics, I think that should be a separate exported algorithm rather than changing this ordinary unregister wrapper.