waitUntil(|f|)
method *must* run these steps:
- 1. If the extensions allowed flag is unset, then:
+ 1. If the [=ExtendableEvent/pending promises count=] is zero and the [=dispatch flag=] is unset, then:
1. Throw an "{{InvalidStateError}}" exception.
1. Abort these steps.
+
+ Note: If no lifetime extension promise has been added in the task that called the event handlers), calling {{ExtendableEvent/waitUntil()}} in subsequent asynchronous tasks will throw.
+
1. Add |f| to the [=ExtendableEvent/extend lifetime promises=].
1. Increase the [=ExtendableEvent/pending promises count=] by one.
@@ -1316,6 +1315,8 @@ spec: webappsec-referrer-policy; urlPrefix: https://w3c.github.io/webappsec-refe
1. Run [=Handle Extend Lifetime Promise=] with the [=context object=] and |f|.
1. Return.
+
+ The user agent *should not* terminate the [=/service worker=] associated with |event|'s relevant settings object's [=environment settings object/global object=] when |event|'s [=dispatch flag=] is set or |event|'s [=ExtendableEvent/pending promises count=] is not zero. However, the user agent *may* impose a time limit to this lifetime extension.
then
methods, if any, in the task where |promise| has been settled have executed.
+ 2. [=Queue a microtask=], on |promise|'s [=relevant settings object=]'s [=responsible event loop=], to decrease |event|'s [=ExtendableEvent/pending promises count=] by one.
true
if |request|'s [=request/client=] is a window client and the event was dispatched with the user's intention for the page reload, and false
otherwise.
1. Dispatch |e| at |activeWorker|'s [=service worker/global object=].
- 1. Invoke [=Extend Service Worker Lifetime=] with |e|.
1. If |e|'s [=FetchEvent/respond-with entered flag=] is set, set |respondWithEntered| to true.
1. If |e|'s [=FetchEvent/wait to respond flag=] is set, then:
1. Wait until |e|'s [=FetchEvent/wait to respond flag=] is unset.
@@ -3023,7 +3000,6 @@ spec: webappsec-referrer-policy; urlPrefix: https://w3c.github.io/webappsec-refe
1. Initialize |e|’s {{ForeignFetchEvent/request}} attribute to |r|.
1. Initialize |e|’s {{ForeignFetchEvent/origin}} attribute to the Unicode serialization of |request|'s [=request/origin=].
1. Dispatch |e| at |activeWorker|'s [=service worker/global object=].
- 1. Invoke [=Extend Service Worker Lifetime=] with |e|.
1. If |e|'s [=ForeignFetchEvent/respond-with entered flag=] is set, set |respondWithEntered| to true.
1. If |e|'s wait to respond flag is set, wait until |e|'s wait to respond flag is unset.
1. Let |internalResponse| be |e|'s [=ForeignFetchEvent/potential response=].
@@ -3085,7 +3061,6 @@ spec: webappsec-referrer-policy; urlPrefix: https://w3c.github.io/webappsec-refe
1. Invoke Run Service Worker algorithm with |activeWorker| as the argument.
1. Queue a task |task| to run these substeps:
1. Invoke |callbackSteps| with |activeWorker|'s [=service worker/global object=] as its argument.
- 1. Invoke [=Extend Service Worker Lifetime=] with |event|.
The |task| *must* use |activeWorker|'s event loop and the handle functional event task source.
diff --git a/docs/index.html b/docs/index.html
index 0304e494..186b3c12 100644
--- a/docs/index.html
+++ b/docs/index.html
@@ -1424,7 +1424,7 @@
An ExtendableEvent
object has an associated extend lifetime promises (an array of promises). It is initially an empty array.
An ExtendableEvent
object has an associated extensions allowed flag. It is initially set.
An ExtendableEvent
object has an associated pending promises count (the number of pending promises in the extend lifetime promises). It is initially set to zero.
Service workers have two lifecycle events, install
and activate
. Service workers use the ExtendableEvent
interface for activate
event and install
event.
Service worker extensions that define event handlers may also use or extend the ExtendableEvent
interface.
Note: To extend the lifetime of a service worker, algorithms that dispatch events using the ExtendableEvent
interface run Extend Service Worker Lifetime algorithm after dispatching the event. See Handle Fetch, Handle Foreign Fetch, and Handle Functional Event.
An ExtendableEvent
object has an associated pending promises count (the number of pending promises in the extend lifetime promises). It is initially set to zero.
Service workers have two lifecycle events, install
and activate
. Service workers use the ExtendableEvent
interface for activate
event and install
event.
Service worker extensions that define event handlers may also use or extend the ExtendableEvent
interface.
event.waitUntil(f)
waitUntil()
method extends the lifetime of the event.
waitUntil(f)
method must run these steps:
If the extensions allowed flag is unset, then:
+If the pending promises count is zero and the dispatch flag is unset, then:
Throw an "InvalidStateError
" exception.
Abort these steps.
Note: If no lifetime extension promise has been added in the task that called the event handlers), calling waitUntil()
in subsequent asynchronous tasks will throw.
Add f to the extend lifetime promises.
Increase the pending promises count by one.
-Note: The pending promises count is increased even if the given promise has already been settled. The corresponding count decrease is done within Handle Extend Lifetime Promise algorithm.
+Increase the pending promises count by one.
+Note: The pending promises count is increased even if the given promise has already been settled. The corresponding count decrease is done within Handle Extend Lifetime Promise algorithm.
Run Handle Extend Lifetime Promise with the context object and f.
Return.
The user agent should not terminate the service worker associated with event’s relevant settings object’s global object when event’s dispatch flag is set or event’s pending promises count is not zero. However, the user agent may impose a time limit to this lifetime extension.
Service workers and extensions that define event handlers may define their own behaviors, allowing the extend lifetime promises to suggest operation length, and the rejected state of any of the promise in extend lifetime promises to suggest operation failure.
-Service workers define the following behaviors for install
event and activate
event, respectively:
Service workers and extensions that define event handlers may define their own behaviors, allowing the extend lifetime promises to suggest operation length, and the rejected state of any of the promise in extend lifetime promises to suggest operation failure.
+Service workers define the following behaviors for install
event and activate
event, respectively:
Adding a promise f to the event’s extend lifetime promises delays treating the installing worker as installed (i.e. a waiting worker) until all the promises in the extend lifetime promises resolve successfully. (See step 11.3.1 of Install algorithm.) If f rejects, the installation fails. This is primarily used to ensure that a service worker is not considered installed (i.e. a waiting worker) until all of the core caches it depends on are populated.
+Adding a promise f to the event’s extend lifetime promises delays treating the installing worker as installed (i.e. a waiting worker) until all the promises in the extend lifetime promises resolve successfully. (See step 11.3.1 of Install algorithm.) If f rejects, the installation fails. This is primarily used to ensure that a service worker is not considered installed (i.e. a waiting worker) until all of the core caches it depends on are populated.
Adding a promise to the event’s extend lifetime promises delays treating the active worker as activated until all the promises in the extend lifetime promises settle. (See step 12.3 of Activate algorithm.) This is primarily used to ensure that any functional events are not dispatched to the ServiceWorkerGlobalScope
object that represents the service worker until it upgrades database schemas and deletes the outdated cache entries.
Adding a promise to the event’s extend lifetime promises delays treating the active worker as activated until all the promises in the extend lifetime promises settle. (See step 12.3 of Activate algorithm.) This is primarily used to ensure that any functional events are not dispatched to the ServiceWorkerGlobalScope
object that represents the service worker until it upgrades database schemas and deletes the outdated cache entries.
InstallEvent
[Constructor(DOMString type, optional ExtendableEventInit eventInitDict), Exposed=ServiceWorker] -interface InstallEvent : ExtendableEvent { +interface InstallEvent : ExtendableEvent { void registerForeignFetch(ForeignFetchOptions options); }; @@ -3147,7 +3146,7 @@4.6.
FetchEvent
[Constructor(DOMString type, FetchEventInit eventInitDict), Exposed=ServiceWorker] -interface FetchEvent : ExtendableEvent { +interface FetchEvent : ExtendableEvent { [SameObject] readonly attribute Request request; readonly attribute Promise<any> preloadResponse; readonly attribute DOMString clientId; @@ -3167,7 +3166,7 @@-boolean isReload = false; };
Service workers have an essential functional event fetch
. For fetch
event, service workers use the FetchEvent
interface which extends the ExtendableEvent
interface.
Service workers have an essential functional event fetch
. For fetch
event, service workers use the FetchEvent
interface which extends the ExtendableEvent
interface.
Each event using FetchEvent
interface has an associated potential response (a response), initially set to null, and the following associated flags that are initially unset:
Add r to the extend lifetime promises.
Increase the pending promises count by one.
-Note: The pending promises count is increased even if the given promise has already been settled. The corresponding count decrease is done within Handle Extend Lifetime Promise algorithm.
+Increase the pending promises count by one.
+Note: The pending promises count is increased even if the given promise has already been settled. The corresponding count decrease is done within Handle Extend Lifetime Promise algorithm.
Run Handle Extend Lifetime Promise with the context object and r.
-Note: event.respondWith(r)
extends the lifetime of the event by default as if event.waitUntil(r)
is called.
Note: event.respondWith(r)
extends the lifetime of the event by default as if event.waitUntil(r)
is called.
Set the stop propagation flag and stop immediate propagation flag.
Set the respond-with error flag.
-Note: If the respond-with error flag is set, a network error is returned to Fetch through Handle Fetch algorithm. (See the step 21.1.) Otherwise, the value response is returned to Fetch through Handle Fetch algorithm. (See the step 22.1.)
+Note: If the respond-with error flag is set, a network error is returned to Fetch through Handle Fetch algorithm. (See the step 21.1.) Otherwise, the value response is returned to Fetch through Handle Fetch algorithm. (See the step 22.1.)
Unset the wait to respond flag.
@@ -3341,7 +3340,7 @@ForeignFetchEvent
[Constructor(DOMString type, ForeignFetchEventInit eventInitDict), Exposed=ServiceWorker] -interface ForeignFetchEvent : ExtendableEvent { +interface ForeignFetchEvent : ExtendableEvent { [SameObject] readonly attribute Request request; readonly attribute USVString origin; @@ -3359,7 +3358,7 @@-
sequence<ByteString> headers; };
Service workers have a functional event foreignfetch
. For foreignfetch
events, service workers use the ForeignFetchEvent
interface which extends the ExtendableEvent
interface.
Service workers have a functional event foreignfetch
. For foreignfetch
events, service workers use the ForeignFetchEvent
interface which extends the ExtendableEvent
interface.
Each event using ForeignFetchEvent
interface has an associated potential response (a response), initially set to null, an associated origin (a USVString
or null), initially set to null, an associated list of exposed headers (whose element type is a byte string), initially set to an empty list, and the following associated flags that are initially unset:
Add r to the extend lifetime promises.
Increase the pending promises count by one.
-Note: The pending promises count is increased even if the given promise has already been settled. The corresponding count decrease is done within Handle Extend Lifetime Promise algorithm.
+Increase the pending promises count by one.
+Note: The pending promises count is increased even if the given promise has already been settled. The corresponding count decrease is done within Handle Extend Lifetime Promise algorithm.
Run Handle Extend Lifetime Promise with the context object and r.
Set the respond-with error flag.
-Note: If the respond-with error flag is set, a network error is returned to Fetch through Handle Foreign Fetch algorithm. (See the step 19.1.) Otherwise, a filtered version of response is returned to Fetch through Handle Foreign Fetch algorithm. (See the step 20.1.)
+Note: If the respond-with error flag is set, a network error is returned to Fetch through Handle Foreign Fetch algorithm. (See the step 19.1.) Otherwise, a filtered version of response is returned to Fetch through Handle Foreign Fetch algorithm. (See the step 20.1.)
Unset the wait to respond flag.
@@ -3520,7 +3519,7 @@ExtendableMessageEvent
[Constructor(DOMString type, optional ExtendableMessageEventInit eventInitDict), Exposed=ServiceWorker] -interface ExtendableMessageEvent : ExtendableEvent { +interface ExtendableMessageEvent : ExtendableEvent { readonly attribute any data; readonly attribute USVString origin; readonly attribute DOMString lastEventId; @@ -3536,7 +3535,7 @@-sequence<MessagePort> ports = []; };
Service workers define the extendable message
event to allow extending the lifetime of the event. For the message
event, service workers use the ExtendableMessageEvent
interface which extends the ExtendableEvent
interface.
Service workers define the extendable message
event to allow extending the lifetime of the event. For the message
event, service workers use the ExtendableMessageEvent
interface which extends the ExtendableEvent
interface.
event.data
The data attribute must return the value it was initialized to. When the object is created, this attribute must be initialized to null. It represents the message being sent.
@@ -3574,16 +3573,16 @@activate
- ExtendableEvent
+ ExtendableEvent
fetch
FetchEvent
- Response
object, can be retrieved from a Cache
object or directly from network using self.fetch(input, init)
method. (A custom Response
object can be another option.)
+ Response
object, can be retrieved from a Cache
object or directly from network using self.fetch(input, init)
method. (A custom Response
object can be another option.)
foreignfetch
FetchEvent
- Response
object, can be retrieved from a Cache
object or directly from network using self.fetch(input, init)
method. (A custom Response
object can be another option.)
+ Response
object, can be retrieved from a Cache
object or directly from network using self.fetch(input, init)
method. (A custom Response
object can be another option.)
message
ExtendableMessageEvent
@@ -4469,7 +4468,7 @@ Plug-ins should not load via service workers. As plug-ins may get their security origins from their own urls, the embedding service worker cannot handle it. For this reason, the Handle Fetch algorithm makes the potential-navigation-or-subresource request (whose context is either <embed>
or <object>
) immediately fallback to the network without dispatching fetch
event.
Plug-ins should not load via service workers. As plug-ins may get their security origins from their own urls, the embedding service worker cannot handle it. For this reason, the Handle Fetch algorithm makes the potential-navigation-or-subresource request (whose context is either <embed>
or <object>
) immediately fallback to the network without dispatching fetch
event.
Some of the legacy networking stack code may need to be carefully audited to understand the ramifications of interactions with service workers.
Specifications may define a functional event by extending ExtendableEvent
interface:
Specifications may define a functional event by extending ExtendableEvent
interface:
// e.g. define FunctionalEvent interface interface FunctionalEvent : ExtendableEvent { // add a functional event’s own attributes and methods @@ -4512,8 +4511,8 @@8.4. Request Functional Event Dispatch
-To request a functional event dispatch to a service worker, specifications may invoke Handle Functional Event algorithm with its service worker registration registration and the algorithm callbackSteps as the arguments.
-Specifications may define an algorithm callbackSteps where the corresponding functional event can be created and fired with specification specific objects. The algorithm is passed globalObject (a
+ServiceWorkerGlobalScope
object) at which it may fire its functional events. This algorithm is called on a task queued by Handle Functional Event algorithm.To request a functional event dispatch to a service worker, specifications may invoke Handle Functional Event algorithm with its service worker registration registration and the algorithm callbackSteps as the arguments.
+Specifications may define an algorithm callbackSteps where the corresponding functional event can be created and fired with specification specific objects. The algorithm is passed globalObject (a
ServiceWorkerGlobalScope
object) at which it may fire its functional events. This algorithm is called on a task queued by Handle Functional Event algorithm.Note: See an example hook defined in Notifications API.
@@ -5086,18 +5085,16 @@
Initialize e’s type
attribute toinstall
.Dispatch e at installingWorker’s global object.
-- -
Invoke Extend Service Worker Lifetime with e.
WaitForAsynchronousExtensions: Run the following substeps in parallel:
-
- -
Wait until e’s extensions allowed flag is unset.
+Wait until e’s pending promises count is zero.
If the result of waiting for all of e’s extend lifetime promises rejected, set installFailed to true.
If task is discarded or the script has been aborted by the termination of installingWorker, set installFailed to true.
+If task is discarded or the script has been aborted by the termination of installingWorker, set installFailed to true.
Wait for task to have executed or been discarded.
- @@ -5124,7 +5121,7 @@
Set redundantWorker to registration’s waiting worker.
- -
Terminate redundantWorker.
+Terminate redundantWorker.
The user agent may abort in-flight requests triggered by redundantWorker.
@@ -5171,7 +5168,7 @@
Wait for redundantWorker to finish handling any in-progress requests.
- -
Terminate redundantWorker.
+Terminate redundantWorker.
Run the Update Registration State algorithm passing registration, "
@@ -5207,18 +5204,16 @@active
" and registration’s waiting worker as the arguments.Queue a task task to run the following substeps:
- -
Let e be the result of creating an event with
+ExtendableEvent
.Let e be the result of creating an event with
ExtendableEvent
.Dispatch e at activeWorker’s global object.
- -
Invoke Extend Service Worker Lifetime with e.
-- -
WaitForAsynchronousExtensions: Wait, in parallel, until e’s extensions allowed flag is unset.
+WaitForAsynchronousExtensions: Wait, in parallel, until e’s pending promises count is zero.
- -
Wait for task to have executed or been discarded, or the script to have been aborted by the termination of activeWorker.
+Wait for task to have executed or been discarded, or the script to have been aborted by the termination of activeWorker.
Wait for the step labeled WaitForAsynchronousExtensions to complete.
- @@ -5358,32 +5353,13 @@
Abort the script currently running in serviceWorker. -
- Extend Service Worker Lifetime
--
-- -
Input
-- -
event, an
-ExtendableEvent
object- -
Output
-- -
None
--
-- -
If event’s pending promises count is zero, unset event’s extensions allowed flag and abort these steps.
-Note: If no lifetime extension promise has been added up to this point (i.e., at the end of the task that called the event handlers), the extensions allowed flag is immediately unset. Calling
-waitUntil()
in subsequent asynchronous tasks will throw.The user agent should not terminate the service worker associated with event’s relevant settings object’s global object until event’s extensions allowed flag is unset. However, the user agent may impose a time limit to this lifetime extension.
-Handle Extend Lifetime Promise
Input
- -
event, an
+ExtendableEvent
objectevent, an
ExtendableEvent
objectpromise, a promise
- @@ -5393,30 +5369,14 @@
- -
Wait until promise is settled in parallel.
+Wait, in parallel, until promise is settled and promise’s
then
methods, if any, in the task where promise has been settled have executed.- -
Queue a microtask to run the following substeps:
--
+- -
Decrease event’s pending promises count by one.
-- -
For each reaction in promise.[[PromiseFulfillReactions]]:
--
-- -
Append reaction.[[Capability]].[[Promise]] to event’s extend lifetime promises.
-- -
Increase event’s pending promises count by one.
-- -
Invoke Handle Extend Lifetime Promise with event and reaction.[[Capability]].[[Promise]].
-- -
If event’s pending promises count is zero, unset event’s extensions allowed flag.
-Queue a microtask, on promise’s relevant settings object's responsible event loop, to decrease event’s pending promises count by one.
Handle Fetch
-The Handle Fetch algorithm is the entry point for the fetch handling handed to the service worker context.
+The Handle Fetch algorithm is the entry point for the fetch handling handed to the service worker context.
Input
@@ -5563,8 +5523,6 @@isReload attribute of e be initialized to
true
if request’s client is a window client and the event was dispatched with the user’s intention for the page reload, andfalse
otherwise.Dispatch e at activeWorker’s global object.
-- -
Invoke Extend Service Worker Lifetime with e.
If e’s respond-with entered flag is set, set respondWithEntered to true.
- @@ -5616,7 +5574,7 @@
Handle Foreign Fetch
-The Handle Foreign Fetch algorithm is the entry point for the fetch handling handed to the service worker context to handle foreign fetch requests.
+The Handle Foreign Fetch algorithm is the entry point for the fetch handling handed to the service worker context to handle foreign fetch requests.
Input
@@ -5683,8 +5641,6 @@Initialize e’s
origin
attribute to the Unicode serialization of request’s origin.Dispatch e at activeWorker’s global object.
-- -
Invoke Extend Service Worker Lifetime with e.
If e’s respond-with entered flag is set, set respondWithEntered to true.
- @@ -5767,7 +5723,7 @@
Input
- -
event, an
+ExtendableEvent
objectevent, an
ExtendableEvent
objectregistration, a service worker registration
- @@ -5804,8 +5760,6 @@
Invoke callbackSteps with activeWorker’s global object as its argument.
-- -
Invoke Extend Service Worker Lifetime with event.
The task must use activeWorker’s event loop and the handle functional event task source.
- @@ -6019,7 +5973,7 @@
target, a string (one of "
installing
", "waiting
", and "active
")- -
source, a service worker or null
+source, a service worker or null
Output
- @@ -6073,9 +6027,9 @@
Input
- -
worker, a service worker
+worker, a service worker
- -
state, a service worker's state
+state, a service worker's state
Output
- @@ -6099,27 +6053,27 @@
installing - -
Note: The service worker in this state is considered an installing worker. During this state,
+waitUntil()
can be called inside theoninstall
event handler to extend the life of the installing worker until the passed promise resolves successfully. This is primarily used to ensure that the service worker is not active until all of the core caches are populated.Note: The service worker in this state is considered an installing worker. During this state,
waitUntil()
can be called inside theoninstall
event handler to extend the life of the installing worker until the passed promise resolves successfully. This is primarily used to ensure that the service worker is not active until all of the core caches are populated.installed
- -
Note: The service worker in this state is considered a waiting worker.
+Note: The service worker in this state is considered a waiting worker.
activating
- -
Note: The service worker in this state is considered an active worker. During this state,
+waitUntil()
can be called inside theonactivate
event handler to extend the life of the active worker until the passed promise resolves successfully. No functional events are dispatched until the state becomes activated.Note: The service worker in this state is considered an active worker. During this state,
waitUntil()
can be called inside theonactivate
event handler to extend the life of the active worker until the passed promise resolves successfully. No functional events are dispatched until the state becomes activated.activated
- -
Note: The service worker in this state is considered an active worker ready to handle functional events.
+Note: The service worker in this state is considered an active worker ready to handle functional events.
redundant
- -
Note: A new service worker is replacing the current service worker, or the current service worker is being discarded due to an install failure.
+Note: A new service worker is replacing the current service worker, or the current service worker is being discarded due to an install failure.
Fire an event named
@@ -6194,7 +6148,7 @@statechange
at workerObject.
Output
- -
worker, a service worker
+worker, a service worker
- @@ -6262,7 +6216,7 @@
Output
- -
newestWorker, a service worker
+newestWorker, a service worker
- @@ -6557,18 +6511,18 @@
Appendix B: Extended HTTP headers
Service Worker Script Request
-An HTTP request to fetch a service worker's script resource will include the following header:
+An HTTP request to fetch a service worker's script resource will include the following header:
- -
Indicates this request is a service worker's script resource request.
+Indicates this request is a service worker's script resource request.
Note: This header helps administrators log the requests and detect threats.
- Service Worker Script Response
-An HTTP response to a service worker's script resource request can include the following header:
+An HTTP response to a service worker's script resource request can include the following header:
- @@ -6615,7 +6569,7 @@
Syntax
-ABNF for the values of the headers used by the service worker's script resource requests and responses:
+ABNF for the values of the headers used by the service worker's script resource requests and responses:
Service-Worker = %x73.63.72.69.70.74 ; "script", case-sensitiveNote: The validation of the Service-Worker-Allowed header’s values is done by URL parsing algorithm (in Update algorithm) instead of using ABNF.
@@ -6734,8 +6688,6 @@ExtendableMessageEvent(type), in §4.8
- ExtendableMessageEvent(type, eventInitDict), in §4.8
- extend lifetime promises, in §4.4 -
- Extend Service Worker Lifetime, in §Unnumbered section -
- extensions allowed flag, in §4.4
- fetch, in §4.9
- FetchEvent, in §4.6
- FetchEventInit, in §4.6 @@ -7137,8 +7089,8 @@
worker, in §4.3
- "worker", in §4.3
- worker client, in §2.3 -
- workerType, in §5.2
- workertype, in §5.2 +
- workerType, in §5.2
- worker type, in §Unnumbered section
Terms defined by reference
@@ -7804,7 +7756,8 @@3.5. Events (2)
- 4.1. ServiceWorkerGlobalScope (2) (3) (4)
- 4.1.3. skipWaiting() (2) -
- 4.4. ExtendableEvent (2) (3) (4) (5) (6) (7) +
- 4.4. ExtendableEvent (2) (3) (4) (5) (6) +
- 4.4.1. event.waitUntil(f)
- 4.5.1. event.registerForeignFetch(options) (2)
- 4.6. FetchEvent (2)
- 4.7. ForeignFetchEvent (2) @@ -7822,16 +7775,15 @@
Install (2)
- Run Service Worker
- Terminate Service Worker -
- Extend Service Worker Lifetime -
- Handle Fetch -
- Handle Foreign Fetch -
- Update Registration State -
- Update Worker State (2) (3) (4) (5) (6) (7) (8) (9) (10) -
- Match Service Worker for Foreign Fetch -
- Get Newest Worker -
- Service Worker Script Request (2) -
- Service Worker Script Response -
- Syntax +
- Handle Fetch +
- Handle Foreign Fetch +
- Update Registration State +
- Update Worker State (2) (3) (4) (5) (6) (7) (8) (9) (10) +
- Match Service Worker for Foreign Fetch +
- Get Newest Worker +
- Service Worker Script Request (2) +
- Service Worker Script Response +
- Syntax - @@ -9949,60 +9889,45 @@
2.1.1. Lifetime
- 2.2. Service Worker Registration -
- Install (2) -
- Activate (2) -
- Extend Service Worker Lifetime +
- 4.4.1. event.waitUntil(f) +
- Install (2) +
- Activate (2)
- Handle Fetch
- Handle Foreign Fetch
- Handle Service Worker Client Unload
- Clear Registration (2) (3) -
- -Extend Service Worker Lifetime
- - : Input - :: |event|, an {{ExtendableEvent}} object - : Output - :: None - - 1. If |event|'s [=ExtendableEvent/pending promises count=] is zero, unset |event|'s [=ExtendableEvent/extensions allowed flag=] and abort these steps. - - Note: If no lifetime extension promise has been added up to this point (i.e., at the end of the task that called the event handlers), the [=ExtendableEvent/extensions allowed flag=] is immediately unset. Calling {{ExtendableEvent/waitUntil()}} in subsequent asynchronous tasks will throw. - - The user agent *should not* terminate the [=/service worker=] associated with |event|'s relevant settings object's [=environment settings object/global object=] until |event|'s extensions allowed flag is unset. However, the user agent *may* impose a time limit to this lifetime extension. -Handle Extend Lifetime Promise
@@ -2500,14 +2484,8 @@ spec: webappsec-referrer-policy; urlPrefix: https://w3c.github.io/webappsec-refe : Output :: None - 1. Wait until |promise| is settled [=in parallel=]. - 2. [=Queue a microtask=] to run the following substeps: - 1. Decrease |event|'s [=ExtendableEvent/pending promises count=] by one. - 1. For each |reaction| in |promise|.\[[PromiseFulfillReactions]]: - 1. Append |reaction|.\[[Capability]].\[[Promise]] to |event|'s [=ExtendableEvent/extend lifetime promises=]. - 1. Increase |event|'s [=ExtendableEvent/pending promises count=] by one. - 1. Invoke [=Handle Extend Lifetime Promise=] with |event| and |reaction|.\[[Capability]].\[[Promise]]. - 1. If |event|'s [=ExtendableEvent/pending promises count=] is zero, unset |event|'s [=ExtendableEvent/extensions allowed flag=]. + 1. Wait, [=in parallel=], until |promise| is settled and |promise|'sthen
methods, if any, in the task where |promise| has been settled have executed. + 2. [=Queue a microtask=], on |promise|'s [=relevant settings object=]'s [=responsible event loop=], to decrease |event|'s [=ExtendableEvent/pending promises count=] by one.@@ -2571,7 +2549,6 @@ spec: webappsec-referrer-policy; urlPrefix: https://w3c.github.io/webappsec-refe 1. If |request| is a navigation request, initialize |e|'s {{FetchEvent/targetClientId}} attribute to |request|'s [=request/target client id=], and to the empty string otherwise. 1. Let the {{FetchEvent/isReload}} attribute of |e| be initialized to true
if |request|'s [=request/client=] is a window client and the event was dispatched with the user's intention for the page reload, andfalse
otherwise. 1. Dispatch |e| at |activeWorker|'s [=service worker/global object=]. - 1. Invoke [=Extend Service Worker Lifetime=] with |e|. 1. If |e|'s [=FetchEvent/respond-with entered flag=] is set, set |respondWithEntered| to true. 1. If |e|'s [=FetchEvent/wait to respond flag=] is set, then: 1. Wait until |e|'s [=FetchEvent/wait to respond flag=] is unset. @@ -2621,7 +2598,6 @@ spec: webappsec-referrer-policy; urlPrefix: https://w3c.github.io/webappsec-refe 1. Invoke Run Service Worker algorithm with |activeWorker| as the argument. 1. Queue a task |task| to run these substeps: 1. Invoke |callbackSteps| with |activeWorker|'s [=service worker/global object=] as its argument. - 1. Invoke [=Extend Service Worker Lifetime=] with |event|. The |task| *must* use |activeWorker|'s event loop and the handle functional event task source. diff --git a/docs/v1/index.html b/docs/v1/index.html index f1d277bb..3f93fda9 100644 --- a/docs/v1/index.html +++ b/docs/v1/index.html @@ -1424,7 +1424,7 @@Service Workers 1
-Editor’s Draft,
+Editor’s Draft,
- This version: @@ -1659,7 +1659,6 @@
Table of Contents
- Activate
- Run Service Worker
- Terminate Service Worker -
- Extend Service Worker Lifetime
- Handle Extend Lifetime Promise
- Handle Fetch
- Handle Functional Event @@ -2939,48 +2938,48 @@
An
-ExtendableEvent
object has an associated extend lifetime promises (an array of promises). It is initially an empty array.An
-ExtendableEvent
object has an associated extensions allowed flag. It is initially set.An
-ExtendableEvent
object has an associated pending promises count (the number of pending promises in the extend lifetime promises). It is initially set to zero.Service workers have two lifecycle events,
-install
andactivate
. Service workers use theExtendableEvent
interface foractivate
event andinstall
event.Service worker extensions that define event handlers may also use or extend the
-ExtendableEvent
interface.Note: To extend the lifetime of a service worker, algorithms that dispatch events using the
+ExtendableEvent
interface run Extend Service Worker Lifetime algorithm after dispatching the event. See Handle Fetch and Handle Functional Event.An
+ExtendableEvent
object has an associated pending promises count (the number of pending promises in the extend lifetime promises). It is initially set to zero.Service workers have two lifecycle events,
+install
andactivate
. Service workers use theExtendableEvent
interface foractivate
event andinstall
event.Service worker extensions that define event handlers may also use or extend the
ExtendableEvent
interface.- 4.4.1.
event.waitUntil(f)
waitUntil()
method extends the lifetime of the event.
waitUntil(f)
method must run these steps:+
- -
If the extensions allowed flag is unset, then:
+If the pending promises count is zero and the dispatch flag is unset, then:
+
Throw an "
InvalidStateError
" exception.Abort these steps.
Note: If no lifetime extension promise has been added in the task that called the event handlers), calling
waitUntil()
in subsequent asynchronous tasks will throw.Add f to the extend lifetime promises.
- -
Increase the pending promises count by one.
-Note: The pending promises count is increased even if the given promise has already been settled. The corresponding count decrease is done within Handle Extend Lifetime Promise algorithm.
+Increase the pending promises count by one.
+Note: The pending promises count is increased even if the given promise has already been settled. The corresponding count decrease is done within Handle Extend Lifetime Promise algorithm.
Run Handle Extend Lifetime Promise with the context object and f.
Return.
The user agent should not terminate the service worker associated with event’s relevant settings object’s global object when event’s dispatch flag is set or event’s pending promises count is not zero. However, the user agent may impose a time limit to this lifetime extension.
Service workers and extensions that define event handlers may define their own behaviors, allowing the extend lifetime promises to suggest operation length, and the rejected state of any of the promise in extend lifetime promises to suggest operation failure.
-Service workers define the following behaviors for
+install
event andactivate
event, respectively:Service workers and extensions that define event handlers may define their own behaviors, allowing the extend lifetime promises to suggest operation length, and the rejected state of any of the promise in extend lifetime promises to suggest operation failure.
+Service workers define the following behaviors for
install
event andactivate
event, respectively:
- -
Adding a promise f to the event’s extend lifetime promises delays treating the installing worker as installed (i.e. a waiting worker) until all the promises in the extend lifetime promises resolve successfully. (See step 11.3.1 of Install algorithm.) If f rejects, the installation fails. This is primarily used to ensure that a service worker is not considered installed (i.e. a waiting worker) until all of the core caches it depends on are populated.
+Adding a promise f to the event’s extend lifetime promises delays treating the installing worker as installed (i.e. a waiting worker) until all the promises in the extend lifetime promises resolve successfully. (See step 11.3.1 of Install algorithm.) If f rejects, the installation fails. This is primarily used to ensure that a service worker is not considered installed (i.e. a waiting worker) until all of the core caches it depends on are populated.
- -
Adding a promise to the event’s extend lifetime promises delays treating the active worker as activated until all the promises in the extend lifetime promises settle. (See step 12.3 of Activate algorithm.) This is primarily used to ensure that any functional events are not dispatched to the
+ServiceWorkerGlobalScope
object that represents the service worker until it upgrades database schemas and deletes the outdated cache entries.Adding a promise to the event’s extend lifetime promises delays treating the active worker as activated until all the promises in the extend lifetime promises settle. (See step 12.3 of Activate algorithm.) This is primarily used to ensure that any functional events are not dispatched to the
ServiceWorkerGlobalScope
object that represents the service worker until it upgrades database schemas and deletes the outdated cache entries.4.5.
FetchEvent
[Constructor(DOMString type, FetchEventInit eventInitDict), Exposed=ServiceWorker] -interface FetchEvent : ExtendableEvent { +interface FetchEvent : ExtendableEvent { [SameObject] readonly attribute Request request; readonly attribute DOMString clientId; readonly attribute DOMString reservedClientId; @@ -2998,7 +2997,7 @@-boolean isReload = false; };
Service workers have an essential functional event
+fetch
. Forfetch
event, service workers use theFetchEvent
interface which extends theExtendableEvent
interface.Service workers have an essential functional event
fetch
. Forfetch
event, service workers use theFetchEvent
interface which extends theExtendableEvent
interface.Each event using
FetchEvent
interface has an associated potential response (a response), initially set to null, and the following associated flags that are initially unset:
- @@ -3053,11 +3052,11 @@
Add r to the extend lifetime promises.
- -
Increase the pending promises count by one.
-Note: The pending promises count is increased even if the given promise has already been settled. The corresponding count decrease is done within Handle Extend Lifetime Promise algorithm.
+Increase the pending promises count by one.
+Note: The pending promises count is increased even if the given promise has already been settled. The corresponding count decrease is done within Handle Extend Lifetime Promise algorithm.
Run Handle Extend Lifetime Promise with the context object and r.
-Note:
+event.respondWith(r)
extends the lifetime of the event by default as ifevent.waitUntil(r)
is called.Note:
event.respondWith(r)
extends the lifetime of the event by default as ifevent.waitUntil(r)
is called.Set the stop propagation flag and stop immediate propagation flag.
- @@ -3157,7 +3156,7 @@
Set the respond-with error flag.
-Note: If the respond-with error flag is set, a network error is returned to Fetch through Handle Fetch algorithm. (See the step 21.1.) Otherwise, the value response is returned to Fetch through Handle Fetch algorithm. (See the step 22.1.)
+Note: If the respond-with error flag is set, a network error is returned to Fetch through Handle Fetch algorithm. (See the step 21.1.) Otherwise, the value response is returned to Fetch through Handle Fetch algorithm. (See the step 22.1.)
Unset the wait to respond flag.
@@ -3168,7 +3167,7 @@
4.6.
ExtendableMessageEvent
[Constructor(DOMString type, optional ExtendableMessageEventInit eventInitDict), Exposed=ServiceWorker] -interface ExtendableMessageEvent : ExtendableEvent { +interface ExtendableMessageEvent : ExtendableEvent { readonly attribute any data; readonly attribute USVString origin; readonly attribute DOMString lastEventId; @@ -3184,7 +3183,7 @@-sequence<MessagePort> ports = []; };
Service workers define the extendable
+message
event to allow extending the lifetime of the event. For themessage
event, service workers use theExtendableMessageEvent
interface which extends theExtendableEvent
interface.Service workers define the extendable
message
event to allow extending the lifetime of the event. For themessage
event, service workers use theExtendableMessageEvent
interface which extends theExtendableEvent
interface.4.6.1.
event.data
The data attribute must return the value it was initialized to. When the object is created, this attribute must be initialized to null. It represents the message being sent.
@@ -3218,16 +3217,16 @@
install
-ExtendableEvent
+ExtendableEvent
[Lifecycle event] The service worker's containing service worker registration’s installing worker changes. (See step 11.2 of the Install algorithm.) activate
-ExtendableEvent
+ExtendableEvent
[Lifecycle event] The service worker's containing service worker registration’s active worker changes. (See step 12.2 of the Activate algorithm.) fetch
FetchEvent
-[Functional event] The http fetch invokes Handle Fetch with request. As a result of performing Handle Fetch, the service worker returns a response to the http fetch. The response, represented by a Response
object, can be retrieved from aCache
object or directly from network usingself.fetch(input, init)
method. (A customResponse
object can be another option.) +[Functional event] The http fetch invokes Handle Fetch with request. As a result of performing Handle Fetch, the service worker returns a response to the http fetch. The response, represented by a Response
object, can be retrieved from aCache
object or directly from network usingself.fetch(input, init)
method. (A customResponse
object can be another option.)message
ExtendableMessageEvent
@@ -4016,7 +4015,7 @@The implementers are encouraged to note:
@@ -4042,7 +4041,7 @@
- -
Plug-ins should not load via service workers. As plug-ins may get their security origins from their own urls, the embedding service worker cannot handle it. For this reason, the Handle Fetch algorithm makes the potential-navigation-or-subresource request (whose context is either
+<embed>
or<object>
) immediately fallback to the network without dispatchingfetch
event.Plug-ins should not load via service workers. As plug-ins may get their security origins from their own urls, the embedding service worker cannot handle it. For this reason, the Handle Fetch algorithm makes the potential-navigation-or-subresource request (whose context is either
<embed>
or<object>
) immediately fallback to the network without dispatchingfetch
event.Some of the legacy networking stack code may need to be carefully audited to understand the ramifications of interactions with service workers.
7.2. Define Functional Event
-Specifications may define a functional event by extending
+ExtendableEvent
interface:Specifications may define a functional event by extending
ExtendableEvent
interface:// e.g. define FunctionalEvent interface interface FunctionalEvent : ExtendableEvent { // add a functional event’s own attributes and methods @@ -4059,8 +4058,8 @@7.4. Request Functional Event Dispatch
-To request a functional event dispatch to a service worker, specifications may invoke Handle Functional Event algorithm with its service worker registration registration and the algorithm callbackSteps as the arguments.
-Specifications may define an algorithm callbackSteps where the corresponding functional event can be created and fired with specification specific objects. The algorithm is passed globalObject (a
+ServiceWorkerGlobalScope
object) at which it may fire its functional events. This algorithm is called on a task queued by Handle Functional Event algorithm.To request a functional event dispatch to a service worker, specifications may invoke Handle Functional Event algorithm with its service worker registration registration and the algorithm callbackSteps as the arguments.
+Specifications may define an algorithm callbackSteps where the corresponding functional event can be created and fired with specification specific objects. The algorithm is passed globalObject (a
ServiceWorkerGlobalScope
object) at which it may fire its functional events. This algorithm is called on a task queued by Handle Functional Event algorithm.Note: See an example hook defined in Notifications API.
@@ -4573,23 +4572,21 @@
Queue a task task to run the following substeps: -
- -
Let e be the result of creating an event with
+ExtendableEvent
.Let e be the result of creating an event with
ExtendableEvent
.Dispatch e at installingWorker’s global object.
-- -
Invoke Extend Service Worker Lifetime with e.
WaitForAsynchronousExtensions: Run the following substeps in parallel:
- -
Wait until e’s extensions allowed flag is unset.
+Wait until e’s pending promises count is zero.
If the result of waiting for all of e’s extend lifetime promises rejected, set installFailed to true.
If task is discarded or the script has been aborted by the termination of installingWorker, set installFailed to true.
+If task is discarded or the script has been aborted by the termination of installingWorker, set installFailed to true.
Wait for task to have executed or been discarded.
- @@ -4616,7 +4613,7 @@
Set redundantWorker to registration’s waiting worker.
- -
Terminate redundantWorker.
+Terminate redundantWorker.
The user agent may abort in-flight requests triggered by redundantWorker.
@@ -4663,7 +4660,7 @@
Wait for redundantWorker to finish handling any in-progress requests.
- -
Terminate redundantWorker.
+Terminate redundantWorker.
Run the Update Registration State algorithm passing registration, "
@@ -4699,18 +4696,16 @@active
" and registration’s waiting worker as the arguments.Queue a task task to run the following substeps:
- -
Let e be the result of creating an event with
+ExtendableEvent
.Let e be the result of creating an event with
ExtendableEvent
.Dispatch e at activeWorker’s global object.
- -
Invoke Extend Service Worker Lifetime with e.
-- -
WaitForAsynchronousExtensions: Wait, in parallel, until e’s extensions allowed flag is unset.
+WaitForAsynchronousExtensions: Wait, in parallel, until e’s pending promises count is zero.
- -
Wait for task to have executed or been discarded, or the script to have been aborted by the termination of activeWorker.
+Wait for task to have executed or been discarded, or the script to have been aborted by the termination of activeWorker.
Wait for the step labeled WaitForAsynchronousExtensions to complete.
- @@ -4850,32 +4845,13 @@
Abort the script currently running in serviceWorker. -
- Extend Service Worker Lifetime
--
-- -
Input
-- -
event, an
-ExtendableEvent
object- -
Output
-- -
None
--
-- -
If event’s pending promises count is zero, unset event’s extensions allowed flag and abort these steps.
-Note: If no lifetime extension promise has been added up to this point (i.e., at the end of the task that called the event handlers), the extensions allowed flag is immediately unset. Calling
-waitUntil()
in subsequent asynchronous tasks will throw.The user agent should not terminate the service worker associated with event’s relevant settings object’s global object until event’s extensions allowed flag is unset. However, the user agent may impose a time limit to this lifetime extension.
-Handle Extend Lifetime Promise
Input
- -
event, an
+ExtendableEvent
objectevent, an
ExtendableEvent
objectpromise, a promise
- @@ -4885,30 +4861,14 @@
- -
Wait until promise is settled in parallel.
+Wait, in parallel, until promise is settled and promise’s
then
methods, if any, in the task where promise has been settled have executed.- -
Queue a microtask to run the following substeps:
--
+- -
Decrease event’s pending promises count by one.
-- -
For each reaction in promise.[[PromiseFulfillReactions]]:
--
-- -
Append reaction.[[Capability]].[[Promise]] to event’s extend lifetime promises.
-- -
Increase event’s pending promises count by one.
-- -
Invoke Handle Extend Lifetime Promise with event and reaction.[[Capability]].[[Promise]].
-- -
If event’s pending promises count is zero, unset event’s extensions allowed flag.
-Queue a microtask, on promise’s relevant settings object's responsible event loop, to decrease event’s pending promises count by one.
Handle Fetch
-The Handle Fetch algorithm is the entry point for the fetch handling handed to the service worker context.
+The Handle Fetch algorithm is the entry point for the fetch handling handed to the service worker context.
Input
@@ -5020,8 +4980,6 @@isReload attribute of e be initialized to
true
if request’s client is a window client and the event was dispatched with the user’s intention for the page reload, andfalse
otherwise.Dispatch e at activeWorker’s global object.
-- -
Invoke Extend Service Worker Lifetime with e.
If e’s respond-with entered flag is set, set respondWithEntered to true.
- @@ -5077,7 +5035,7 @@
Input
- -
event, an
+ExtendableEvent
objectevent, an
ExtendableEvent
objectregistration, a service worker registration
- @@ -5114,8 +5072,6 @@
Invoke callbackSteps with activeWorker’s global object as its argument.
-- -
Invoke Extend Service Worker Lifetime with event.
The task must use activeWorker’s event loop and the handle functional event task source.
- @@ -5329,7 +5285,7 @@
target, a string (one of "
installing
", "waiting
", and "active
")- -
source, a service worker or null
+source, a service worker or null
Output
- @@ -5383,9 +5339,9 @@
Input
- -
worker, a service worker
+worker, a service worker
- -
state, a service worker's state
+state, a service worker's state
Output
- @@ -5409,27 +5365,27 @@
installing - -
Note: The service worker in this state is considered an installing worker. During this state,
+waitUntil()
can be called inside theoninstall
event handler to extend the life of the installing worker until the passed promise resolves successfully. This is primarily used to ensure that the service worker is not active until all of the core caches are populated.Note: The service worker in this state is considered an installing worker. During this state,
waitUntil()
can be called inside theoninstall
event handler to extend the life of the installing worker until the passed promise resolves successfully. This is primarily used to ensure that the service worker is not active until all of the core caches are populated.installed
- -
Note: The service worker in this state is considered a waiting worker.
+Note: The service worker in this state is considered a waiting worker.
activating
- -
Note: The service worker in this state is considered an active worker. During this state,
+waitUntil()
can be called inside theonactivate
event handler to extend the life of the active worker until the passed promise resolves successfully. No functional events are dispatched until the state becomes activated.Note: The service worker in this state is considered an active worker. During this state,
waitUntil()
can be called inside theonactivate
event handler to extend the life of the active worker until the passed promise resolves successfully. No functional events are dispatched until the state becomes activated.activated
- -
Note: The service worker in this state is considered an active worker ready to handle functional events.
+Note: The service worker in this state is considered an active worker ready to handle functional events.
redundant
- -
Note: A new service worker is replacing the current service worker, or the current service worker is being discarded due to an install failure.
+Note: A new service worker is replacing the current service worker, or the current service worker is being discarded due to an install failure.
Fire an event named
@@ -5535,7 +5491,7 @@statechange
at workerObject.
Output
- -
newestWorker, a service worker
+newestWorker, a service worker
- @@ -5830,18 +5786,18 @@
Appendix B: Extended HTTP headers
Service Worker Script Request
-An HTTP request to fetch a service worker's script resource will include the following header:
+An HTTP request to fetch a service worker's script resource will include the following header:
- -
Indicates this request is a service worker's script resource request.
+Indicates this request is a service worker's script resource request.
Note: This header helps administrators log the requests and detect threats.
Service Worker Script Response
-An HTTP response to a service worker's script resource request can include the following header:
+An HTTP response to a service worker's script resource request can include the following header:
- @@ -5888,7 +5844,7 @@
Syntax
-ABNF for the values of the headers used by the service worker's script resource requests and responses:
+ABNF for the values of the headers used by the service worker's script resource requests and responses:
Service-Worker = %x73.63.72.69.70.74 ; "script", case-sensitiveNote: The validation of the Service-Worker-Allowed header’s values is done by URL parsing algorithm (in Update algorithm) instead of using ABNF.
@@ -6004,8 +5960,6 @@ExtendableMessageEvent(type), in §4.6
- ExtendableMessageEvent(type, eventInitDict), in §4.6
- extend lifetime promises, in §4.4 -
- Extend Service Worker Lifetime, in §Unnumbered section -
- extensions allowed flag, in §4.4
- fetch, in §4.7
- FetchEvent, in §4.5
- FetchEventInit, in §4.5 @@ -6904,7 +6858,8 @@
3.5. Events (2)
- 4.1. ServiceWorkerGlobalScope (2) (3) (4)
- 4.1.3. skipWaiting() (2) -
- 4.4. ExtendableEvent (2) (3) (4) (5) (6) (7) +
- 4.4. ExtendableEvent (2) (3) (4) (5) (6) +
- 4.4.1. event.waitUntil(f)
- 4.5. FetchEvent (2)
- 4.6. ExtendableMessageEvent (2)
- 5.2. Understanding Cache Lifetimes (2) @@ -6920,14 +6875,13 @@
Install (2)
- Run Service Worker
- Terminate Service Worker -
- Extend Service Worker Lifetime -
- Handle Fetch -
- Update Registration State -
- Update Worker State (2) (3) (4) (5) (6) (7) (8) (9) (10) -
- Get Newest Worker -
- Service Worker Script Request (2) -
- Service Worker Script Response -
- Syntax +
- Handle Fetch +
- Update Registration State +
- Update Worker State (2) (3) (4) (5) (6) (7) (8) (9) (10) +
- Get Newest Worker +
- Service Worker Script Request (2) +
- Service Worker Script Response +
- Syntax - @@ -8711,48 +8653,35 @@
2.1.1. Lifetime
- 2.2. Service Worker Registration -
- Install (2) -
- Activate (2) -
- Extend Service Worker Lifetime +
- 4.4.1. event.waitUntil(f) +
- Install (2) +
- Activate (2)
- Handle Fetch
- Handle Service Worker Client Unload
- Clear Registration (2) (3) -