Add registeringClientId to the ServiceWorker object

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

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

Start with the linked design doc, then read the Service Worker behavior around navigator.serviceWorker.register(), updatefound, event.target.installing, and client IDs. Compare the proposed registeringClientId property with the alternative register() signal, and define the expected behavior for updates initiated by the same or another tab. Done means the spec direction and observable behavior are agreed and recorded.