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

On the Workbox team, we're currently building a library that will run in the window context and aid in SW registration, updates, and lifecycle management ([design doc](https://docs.google.com/document/d/16BJDNhfqMjIvJ3_kR4lklpbliCGpi1dFhCdf7kHOsL8/edit?usp=sharing)).

One thing I discovered while working on an early prototype is there are use cases we want to support that are currently not possible (or they're super hacky) to achieve given the current spec.

Here's an example of two cases that are very difficult to reliably distinguish between (AFAIK):

- Tab A registers a SW, and that registration triggers an `updatefound` event.
- Tab A registers a SW and no update is triggered. But before tab A closes, tab B registers a SW for the same script and an `updatefound` event is triggered.

The code running in tab A cannot easily tell that the updated SW wasn't triggerred by its call to `navigator.serviceWorker.register()`.

This isn't necessarily a big problem if the SW code doesn't call `skipWaiting()`, or if it just display a reload banner any time an update is found, but realistically there are cases where webapps want to be more aggressive about updates, or perform in-place updates, and in those cases it's really important to know whether the given update is the one your app was expecting or a future update your code isn't prepared to handle.

I think a reasonable addition to the SW spec would be a property like `registeringClientId`, which would match the client of the window that executed the `navigator.serviceWorker.register()` code.

Then, in an `updatefound` callback, a page could compare its clientId (my understanding is we want to expose the Clients API on the window at some point) to the `registeringClientId` property on `event.target.installing` and determine whether the update came from its version of the code.

* * *

Another possible solution (arguably cleaner but probably also less doable), is a change to the way `register()` works. At the moment, there's no easy way to tell if a `register()` call *didn't* result in an update. If the result of calling `register()` (or some new method) came with any sort of signal for when an update *was not* found, then it would make the above issue a lot easier to solve, as you'd know you wouldn't need to add any `updatefound` event listeners in that case.




-- 
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