[w3c/ServiceWorker] [Feature request] Clients should know their own IDs (#1557)

Ref: https://lists.w3.org/Archives/Public/public-webapps/2020OctDec/0028.html

I recently ran in to a case where a client needed to know its own ID (as part of #1556). It was surprisingly difficult to get a client's own ID from the service worker: you have to `postMessage` to the SW, which then looks at the message's source ID, and posts it back again. This also involves taking in to account the SW lifecycle (e.g. maybe waiting for registration to complete, adjusting the SW to claim clients...) and the message-passing process is async. I'm sure there are other use cases: anything involving per-client state may need clients to know their own ID, and in some cases you might want to do something like attach a client ID to a network request so the FetchEvent can see the relevant client ID (which was the case in the workaround to #1556).

Presumably the browser already knows what each client's ID is, so it makes sense to make that available to the client itself. I think it would be most useful if clients had a fixed ID that was shared between all possible Service Workers, so then it could be a global property that's always available, e.g. `navigator.serviceWorker.myClientId`. If client IDs can vary depending on the service worker (and I'd ask: why would they?), perhaps the `ServiceWorker` interface could have a `myClientId` property, but then you'd still need to deal with lifecycle issues involving obtaining a ServiceWorker in the first place.

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

Received on Thursday, 10 December 2020 12:10:23 UTC