Friendly TAG review: Why not exposed to Service Worker

[kenchris]

in response to w3ctag/design-reviews#283 :

You told me you were going to kill this page on my document, but I probably want to hear that in my Service Worker where I have more context and access to all the tabs that are instance of my app.

The ServiceWorker manages state for the whole app, and might be a better spot for this, though you could expose it to both the service worker and the documents.

[spanicker]

Current thinking on exposing lifecycle state to service worker:

• we intend to expose lifecycle state on WindowClient (similar to visibilityState) in the future. This is needed for supporting background APIs such as ability to update tab title from service worker (eg. inbox count in gmail).
  While currently we don't freeze sites that need to update title or play a sound (eg. chat notification), in the long run we expect to freeze such sites and support their needs via service worker; however this API is currently blocked behind Deferred Push proposal -- a key pre-requisite here.

• we'd expose lifecycle state on WindowClient sooner -- if we find other concrete use-cases / needs.

• service worker is intentionally ephemeral, we don't want to wake up the service worker to inform it about freezing (eg. firing an event like onfreeze) as it undoes much of the performance benefit of freezing -- as service worker itself needs to attach itself to a renderer that is active and not frozen. We could still get some perf wins by improving our implementation here, but this is still undesirable behavior.

[kenchris]

Thanks for the comments, this reasoning resonates with me.

How do you know that such sites need to update title or play sound?

[spanicker]

We determine if sites need to update title or play sound etc based on heuristics driven by a combination of local observation + global observation (i.e. historically did this site update title).