Intent to Prototype and Ship: FetchEvent.handled

138 views
Skip to first unread message

Makoto Shimazu

unread,
Jul 7, 2020, 10:41:11 PM7/7/20
to blink-dev
ting...@intel.com, shi...@chromium.org Specification: https://w3c.github.io/ServiceWorker/#fetch-event-handled

Spec discussion: https://github.com/w3c/ServiceWorker/issues/1397

Not needed because it's a simple modification to an existing feature. FetchEvent dispatched to a service worker is in a loading pipeline, which is performance sensitive. A new promise FetchEvent.handled is a promise to be resolved when a response is returned from a service worker to its client. This allows a service worker to explicitly wait to run some tasks until tasks critical to return a response to its client complete.
The risk should be low because it's a tiny modification to an existing feature and the name and the behavior of API has been agreed among other two browser implementers at TPAC. Firefox: Public support (https://github.com/w3c/ServiceWorker/issues/1397#issuecomment-478081533) Edge: No public signals Safari: Public signals (https://github.com/w3c/ServiceWorker/issues/1397#issuecomment-479336553) Web developers: Positive The API returns a promise and is expected to be used with waitUntil() API in FetchEvent.
This might be a little tricky as discussed around https://github.com/w3c/ServiceWorker/issues/1397#issuecomment-479036562 .
However, this API is consistent with other APIs used in service workers. ExtendableEvent with promises is an essential part of the service worker related API and the risk is the same with other existing APIs. Using the feature is fairly easy - just use await for the promise in waitUntil.

Yes Yes https://wpt.fyi/results/service-workers/service-worker?label=master&label=experimental&aligned&q=service-workers%2Fservice-worker%2Ffetch-event-handled.https.html https://chromestatus.com/feature/5654467158474752
This intent message was generated by Chrome Platform Status.

Alex Russell

unread,
Jul 9, 2020, 3:32:54 PM7/9/20
to blink-dev, Makoto Shimazu
Thanks for sending this. 

Looks great to prototype, but before we approve shipping I'd appreciate an explainer that outlines how this feature is meant to be used and which problems it solves. 

Regards

Ben Kelly

unread,
Jul 13, 2020, 2:22:53 PM7/13/20
to Alex Russell, blink-dev, Makoto Shimazu
Alex, this is a relatively small feature.  I tried to describe the use case, problem, and alternatives in the spec issue filed here:


Does this need to be extracted into a separate doc?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f81d329c-fd58-4a50-95f9-17e54cd1cfa3n%40chromium.org.

Alex Russell

unread,
Jul 13, 2020, 6:01:35 PM7/13/20
to Ben Kelly, blink-dev, Makoto Shimazu
Extracting that comment into a short doc might help. I'd specifically like to understand guarantees around ordering and potential for alleviating HOL-blocking behavior of post-handling cleanup work. E.g., in a cascade of fetch events, will this help us keep the SW more responsive to incoming fetches?

Makoto Shimazu

unread,
Jul 13, 2020, 11:20:34 PM7/13/20
to Alex Russell, Ben Kelly, blink-dev, Makoto Shimazu
Thanks Ben and Alex.
Now Ting is working on making a short explainer doc based on that comment and will send it out soon.

2020年7月14日(火) 7:01 Alex Russell <sligh...@chromium.org>:

Ben Kelly

unread,
Jul 14, 2020, 10:52:35 AM7/14/20
to Makoto Shimazu, Alex Russell, blink-dev
Ok.  I just wanted to clarify if explainers were always needed or not.  I thought for small things that were already handled at the spec issue level they were not.  In this case we already have cross-vendor consensus and it's been merged to the official spec.

On Mon, Jul 13, 2020 at 11:20 PM Makoto Shimazu <shi...@chromium.org> wrote:
Thanks Ben and Alex.
Now Ting is working on making a short explainer doc based on that comment and will send it out soon.

2020年7月14日(火) 7:01 Alex Russell <sligh...@chromium.org>:
Extracting that comment into a short doc might help. I'd specifically like to understand guarantees around ordering and potential for alleviating HOL-blocking behavior of post-handling cleanup work. E.g., in a cascade of fetch events, will this help us keep the SW more responsive to incoming fetches?

Per the spec it's a promise resolved at the end of Handle Fetch.  Step 26:


So from that perspective ordering is defined.

What may be a bit undefined is if browsers execute any internal, non-specified tasks on the SW thread after Handle Fetch to process the Response.  The intent is for this microtask to run after all that internal work is done.

Since this feature is just reordering work on the SW thread, I don't think it should make things better or worse for FetchEvent responsiveness.

Shao, Ting

unread,
Jul 27, 2020, 11:56:52 AM7/27/20
to Alex Russell, Ben Kelly, blink-dev, Makoto Shimazu

Dear All,

 

Sorry for the delay, I made an explainer for the FetchEvent.handled new API at https://github.com/tingshao/FetchEvent.handled

Please take a look when you have time. Any comment is welcome.

 

Thanks

Ting

Yoav Weiss

unread,
Jul 28, 2020, 9:09:00 AM7/28/20
to Shao, Ting, Alex Russell, Ben Kelly, blink-dev, Makoto Shimazu
LGTM1

On Mon, Jul 27, 2020 at 5:56 PM Shao, Ting <ting...@intel.com> wrote:

Dear All,

 

Sorry for the delay, I made an explainer for the FetchEvent.handled new API at https://github.com/tingshao/FetchEvent.handled

Please take a look when you have time. Any comment is welcome.


Thanks for the explainer, it was extremely helpful when reviewing!
 

Chris Harrelson

unread,
Jul 30, 2020, 2:52:37 PM7/30/20
to Yoav Weiss, Shao, Ting, Alex Russell, Ben Kelly, blink-dev, Makoto Shimazu

Mike West

unread,
Jul 30, 2020, 3:07:03 PM7/30/20
to blink-dev, Chris Harrelson, ting...@intel.com, Alex Russell, Ben Kelly, blink-dev, Makoto Shimazu, yo...@yoav.ws
LGTM3.
Reply all
Reply to author
Forward
0 new messages