Intent to Implement and Ship: FetchEvent.resultingClientId
Matt Falkenhagen
Contact emails
Explainer
This is in the Service Worker specification. There is some background at https://github.com/w3c/ServiceWorker/issues/1091 and https://github.com/w3c/ServiceWorker/issues/1245.
Design doc/Spec
https://w3c.github.io/ServiceWorker/#fetch-event-resultingclientid
Tag review requested.
Summary
FetchEvent.resultingClientId is set for main resource requests (requests for documents or workers). It is the id of the Client potentially created by the request.
Motivation
Without resultingClientId, it is difficult to associate the FetchEvent for the main resource request for a document with subsequent FetchEvents for subresource requests from the document. Such association can be useful for logging and metrics purposes, e.g., measuring milestones in page load time.
It is also needed to make a polyfill for AppCache using service worker. It would enable associating a page to a given cache for its lifespan.
Risks
Interoperability and Compatibility
It is a new addition to an existing feature. There is low risk as it has been discussed in various meetings and GitHub issues for some time, which resulted in its incorporation into the specification.
Edge: No signals
Firefox: Public support
Safari: No signals
Web developers: It is a minor addition to an existing feature so it hasn’t had much publicity. I’ve heard feedback that it would be useful from internal developers and from the AppCache discussion.
Ergonomics
Are there any other platform APIs this feature will frequently be used in tandem with? No
Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)? No
Activation
Will it be challenging for developers to take advantage of this feature immediately, as-is? No
Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use? No
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?
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/4846038800138240
Requesting approval to ship?
Yes
Philip Jägenstedt
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ_xCikLcVH1_miS_0P2eWppVOXh%3DyjXhwuGh_Cwsd6BXr4vKw%40mail.gmail.com.
Daniel Bratell
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/CAARdPYfvu19S_2txf3KPSXnx4hPQMCtARd1Eoo2iOvE1yFJotQ%40mail.gmail.com.
Mike West
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zp7euwbarbppqq%40cicero2.linkoping.osa.
Joe Medley
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3Dd9WQqZ-fYqbaSUwRvNzau8zPSYP_r8oH4BDGnzwCTyMQ%40mail.gmail.com.
Matt Falkenhagen
Matt,Do you have a tracking bug for this?
