Intent to Prototype and Ship: FetchEvent.handled

[Makoto Shimazu]

Contact emails ting...@intel.com, shi...@chromium.org Design docs/spec Specification: https://w3c.github.io/ServiceWorker/#fetch-event-handled

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

TAG review Not needed because it's a simple modification to an existing feature. Summary 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.

Risks

Interoperability and Compatibility 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 Ergonomics 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. Activation Using the feature is fairly easy - just use await for the promise in waitUntil.

Sample

https://github.com/w3c/ServiceWorker/issues/1397#issuecomment-479036562

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? Yes https://wpt.fyi/results/service-workers/service-worker?label=master&label=experimental&aligned&q=service-workers%2Fservice-worker%2Ffetch-event-handled.https.html Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5654467158474752

This intent message was generated by Chrome Platform Status.

[Alex Russell]

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]

Alex, this is a relatively small feature.  I tried to describe the use case, problem, and alternatives in the spec issue filed here:

https://github.com/w3c/ServiceWorker/issues/1397#issue-426624529  

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]

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]

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]

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:

https://w3c.github.io/ServiceWorker/#on-fetch-request-algorithm 

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]

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANr5HFWJ8pWq%3DYkuxkM%3D_mz9fWf96VD5g%3DWxR3EErwVcO2zRYA%40mail.gmail.com.

[Yoav Weiss]

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!

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DM6PR11MB35002B7CACE6227D38C0E58DE0760%40DM6PR11MB3500.namprd11.prod.outlook.com.

[Chris Harrelson]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEitt2-8EcYJb5xL94gPP0UEXXm1zucoHkv6ts60qU1m5Q%40mail.gmail.com.

[Mike West]

LGTM3.