Re: [w3c/ServiceWorker] Add registeringClientId to the ServiceWorker object (#1379)

Looking back on this issue several months later, I'm not sure `registeringClientId` is the right solution to this problem—though I do think the use case is worth solving.

Let me clarify the use case:

- Tab A is loaded with v1 of the app code and service worker.
- Tab B is loaded an hour later, and in the time since tab A was loaded, an updated version (v2) of the app and service worker has been released.
- When tab B is loaded, both A and B will get the `updatefound` event, but only tab B is running window code released with the same version as the updated service worker (v2).

For apps the do a lot of SW to window post messaging, the scenario described above could result in a lot of errors for tab A, so tab A would likely want to show a notification to the user that they should reload, whereas tab B will likely work just fine.

So, the use case is to enable a way for a developer receiving an `updatefound` event to know whether or not the update found is:

- "expected" (i.e. from a version of the service worker released at the same time as the version of the current window code)
- "unexpected" (i.e. from a newer version of the service worker, released more recently than the currently-running window code)

The problem, currently, is that when window code calls either `register()` or `update()`, there's no good way to determine whether or not that call resulted in an update being found. On the flip side, when an `updatefound` event is received, there's no good way to determine whether or not it was the result of that page's call to `register()`/`update()`, or whether it was the result of a `register()`/`update()` call in another tab or even the browser doing its own soft update check as you mentioned.

I'm not tied to any particular solution to this problem, but if we could add a way for a page to reason about whether an `updatefound` event is "expected" or "unexpected", that would be really helpful in knowing how to react to the update.

Some possible solutions:

- Expose the time `Last-Modified` time of the service worker file on the `updatefound` event. (Then developers could compare that time to `performance.timeOrigin`).
- Expose whether or not the update found was directly the result of a `register()`/`update()` call from the current document (or whether it was from another document or a soft update check).



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1379#issuecomment-531663849