Re: [service-workers] Exposing parent client ID for iframe navigations

For future reference, its usually better to put this stuff on
https://github.com/w3c/ServiceWorker/issues/ as it's easier to label &
track.

On Tue, Nov 10, 2020 at 11:39 AM Ashley Gullen <ashley@scirra.com> wrote:

> I've been developing a Service Worker with a fairly straightforward goal
> of serving Blobs via a map of URL to Blob. For example the map might
> associate "myimage.png" with a Blob of a PNG image. Then this can be served
> for a request to example.com/myimage.png. The map is stored per client
> ID, so each client has its own independent map of blobs to serve.
>
> The trickier part is I'd like this to propagate through iframes too - so
> if a client using that map opens a (same-origin, same path) iframe, then
> content in that iframe can also successfully request
> example.com/myimage.png.
>
> The main problem I've come across is when a client opens an iframe, it
> makes a "navigate" mode fetch with an empty clientId, instead only having a
> resultingClientId. However I need to know the clientId of the parent
> client, so I can propagate the parent's map of blobs to also apply to the
> resultingClientId. But it seems there's no way to get the parent client
> from an iframe's FetchEvent.
>
> I can hack around this by passing a clientId in the iframe query string,
> but that is further complicated by the fact clients don't appear to know
> their own clientIds - only the Service Worker does, so there has to be an
> async postMessage to identify it (plus careful management of lifecycles to
> make sure the message works).
>
> So it seems there are two things that are missing from SWs:
> - the parent clientId for an iframe navigation (why not fill the clientId
> field of FetchEvent with that instead of leaving it blank?)
>

Right now the clientId is the client which initiated the request, so it
isn't a good fit if you're actually wanting to know the parent client ID.
But maybe we could add parent client ID?


> - clients to know their own clientId
>

It'd be great to make the clients API available in regular pages, along
with exposing 'this' client ID. Just needs people with time to do it 😀