Re: [w3c/ServiceWorker] Add Unregister Service Workers algorithm for use by other specifications (PR #1849)

@monica-ch commented on this pull request.



> +  <section algorithm>
+    <h3 id="unregister-service-workers-algorithm"><dfn export>Unregister Service Workers</dfn></h3>
+
+      : Input
+      :: |storageKey|, a [=/storage key=]
+      : Output
+      :: None
+
+      1. Let |scopes| be a new [=list=].
+      1. [=list/For each=] (|entryStorageKey|, |serializedScope|) of [=registration map=]'s [=map/keys=]:
+          1. If |entryStorageKey| is not |storageKey|, [=continue=].
+          1. Let |scopeURL| be the result of <a lt="URL parser">parsing</a> |serializedScope|.
+          1. If |scopeURL| is failure, [=continue=].
+          1. [=list/Append=] |scopeURL| to |scopes|.
+      1. [=list/For each=] |scope| of |scopes|:
+          1. Let |job| be the result of running <a>Create Job</a> with *unregister*, |storageKey|, |scope|, null, null, and null.

I investigated this in 55d9288 and kept the algorithm fire-and-forget. With a null client, the existing job-promise machinery cannot settle a supplied promise. More importantly, even the web-facing unregister promise resolves after removal from the registration map, before `Clear Registration`, which can remain delayed while clients or lifetime work use the registration.

The algorithm now explicitly documents that distinction. It also uses structural storage-key equality rather than identity comparison.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1849#discussion_r3971594659
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1849/review/5158143599@github.com>