Re: [w3c/ServiceWorker] Clean up prose about waitUntil on install and activate events (#1248)

jungkees commented on this pull request.



> @@ -1350,10 +1350,7 @@ spec: webappsec-referrer-policy; urlPrefix: https://w3c.github.io/webappsec-refe
 
     [=/Service workers=] and <a href="#extensibility">extensions</a> that <a href="#extension-to-service-worker-global-scope">define event handlers</a> *may* define their own behaviors, allowing the [=ExtendableEvent/extend lifetime promises=] to suggest operation length, and the rejected state of any of the <a>promise</a> in [=ExtendableEvent/extend lifetime promises=] to suggest operation failure.
 
-    [=/Service workers=] define the following behaviors for <code><a>install</a></code> event and <code><a>activate</a></code> event, respectively:
-
-      * Adding a <a>promise</a> |f| to the event's <a>extend lifetime promises</a> delays treating the <a>installing worker</a> as *installed* (i.e. a <a>waiting worker</a>) until all the <a>promises</a> in the <a>extend lifetime promises</a> resolve successfully. (See step 11.3.1 of <a>Install</a> algorithm.) If |f| rejects, the installation fails. This is primarily used to ensure that a [=/service worker=] is not considered *installed* (i.e. a <a>waiting worker</a>) until all of the core caches it depends on are populated.
-      * Adding a <a>promise</a> to the event's <a>extend lifetime promises</a> delays treating the <a>active worker</a> as *activated* until all the <a>promises</a> in the <a>extend lifetime promises</a> settle. (See step 12.3 of <a>Activate</a> algorithm.) This is primarily used to ensure that any <a>functional events</a> are not dispatched to the {{ServiceWorkerGlobalScope}} object that represents the [=/service worker=] until it upgrades database schemas and deletes the outdated cache entries.
+    Note: [=/Service workers=] delay treating the [=installing worker=] as *installed* until all the [=promises=] in the {{install!!event}} event's [=extend lifetime promises=] resolve successfully. (See [=Install=] algorithm step 10.4.1.) If any of the promises rejects, the installation fails. This is primarily used to ensure that a [=/service worker=] is not considered *installed* until all of the core caches it depends on are populated. Likewise, [=/service workers=] delay treating the [=active worker=] as *activated* until all the [=promises=] in the {{activate!!event}} event's [=extend lifetime promises=] settle. (See [=Activate=] algorithm step 10.4.) This is primarily used to ensure that any [=functional events=] are not dispatched to the [=/service worker=] until it upgrades database schemas and deletes the outdated cache entries.

Thanks @jakearchibald. Good idea. I added links to the steps as suggested.

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