Intent to Implement and Ship: Add frozen or active lifecycleState to ServiceWorker Client

[Dave Tapuska]

Contact emails dtap...@chromium.org Explainer https://github.com/dtapuska/iframe-freeze/blob/master/SW.md Design docs/spec Specification: https://wicg.github.io/page-lifecycle/#service-worker-client-lifecycle-state https://github.com/w3c/ServiceWorker/pull/1442 TAG review Minor addition of a field Summary Expose the client's PageLifecycle state on the ServiceWorker Client API. Motivation Service workers do not know if the state of a client. If a client is frozen it will not immediately handle a postMessage being sent to it. Under some situations the service worker may not wish to spam the client with postMessages because that may cause the client to be discarded. In other situations the service worker may wish to focus the window client causing the client to become unfrozen. Risks

Interoperability and Compatibility Returning state information in a multiprocess environment always has race and staleness issues and this API can suffer from those. Firefox: Mixed public signals (https://github.com/w3c/ServiceWorker/pull/1442#issuecomment-511536136) Edge: No public signals Safari: Public skepticism (https://github.com/w3c/ServiceWorker/pull/1442#issuecomment-511573439) Skepticism around whole Page Lifecycle API in general. Web developers: No signals

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/clients-matchall-frozen.https.html Tracking bug https://crbug.com/1002185 Link to entry on the Chrome Platform Status https://www.chromestatus.com/feature/5737408349863936

[Philip Jägenstedt]

Is there anything we can do to address the concerns in https://github.com/w3c/ServiceWorker/pull/1442?

If not, if the proposal to leave the PR open and ship this anyway, or should we maintain a fork?

--
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/CAHgVhZU6gQ5PcEkPC8DroMbGkiDG4o35FPN2C3qsBFF63DGQfw%40mail.gmail.com.

[Dave Tapuska]

The page lifecycle spec contains the changes we wish to make to the standards (html & service worker patches). Since this spec introduces the concept of frozeness it seems relevant to place it there until another browser vendor adopts the spec and we can move it into the other standards.

I believe it is still useful to continue the PR being open especially because of this monkey patching via page lifecycle spec.

dave.

[Matt Falkenhagen]

This is one of the topics scheduled for discussion at TPAC in the Service Worker WG meeting next week (https://github.com/w3c/ServiceWorker/issues/1460). It'd probably be good to have the meeting before making a decision on shipping.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZX6P-H3tnkTYXkU%3DCnK2A3OtHkPs9s%2BtDX0pWSA9x%3DYnw%40mail.gmail.com.

[Yoav Weiss]

Any post-TPAC updates?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ_xCinLLWTgO51%2Bwdcd_4xMWmF7J4_tDJFqqxGVA6Fx4Z_rhg%40mail.gmail.com.

[Dave Tapuska]

It was clearer that we won't block additional freezing on this API for service workers. (Specifically desktop freezing and iframe freezing feature policy) While this API is nice to have and would solve problems we currently have those problems in the code with frozen tabs (on Android) anyways so being that there was indecision on the API at TPAC we are going to hold onto this proposal for now. That doesn't mean that we won't revisit it but we need to monitor closely the feedback from developers if there is a strong desire for such an API.

dave.