clients.get() should not resolve before sandboxing determines the origin of the client

[mfalken]

I think this is an oversight in the spec.

clients.get(id) does:
"Wait for either client’s execution ready flag to be set or for client’s discarded flag to be set."
https://w3c.github.io/ServiceWorker/#clients-get

The execution ready flag seems set at:
"7. Set the active document of browsingContext to document."
https://html.spec.whatwg.org/multipage/browsers.html#creating-a-new-browsing-context

Which later on does:
"11. Implement the sandboxing for document."

Probably we must implement the sandboxing for document first, and if the document has a unique origin we "Run the environment discarding steps for reservedEnvironment." like a cross-origin redirect. Then we can set execution ready.

Chrome currently resolves to a WindowClient. Firefox resolves with undefined. I think the spec intent is undefined.

cc @annevk @wanderview

[mfalken]

Ah, process a navigation response https://html.spec.whatwg.org/multipage/browsing-the-web.html#process-a-navigate-response includes https://html.spec.whatwg.org/multipage/browsing-the-web.html#initialise-the-document-object which does: "Implement the sandboxing for document". So probably here we need to run the discarding steps if the document is sandboxed.

[mfalken]

Also I thought I saw Firefox passing the test I wrote but it seems to fail after all.

[wanderview]

So, AIUI your test creates an iframe with a URL and the resulting load sets sandboxing via a CSP header.

I think resultingClientId probably should resolve before the CSP header is applied. Currently its supposed to resolve with the initial about:blank. If the final document is same-origin, then the client is preserved. If it ends up cross-origin due to navigation or header-applied sandboxing, then that initial about:blank client is discarded and a new one created. But before the document is loaded and headers applied, though, the initial about:blank client is execution ready.

So I think this is why firefox is failing your test. Its marking the initial about:blank execution ready which causes it to resolve the client.

Since chrome does not expose initial about:blank in the clients API yet, I think we could perhaps disambiguate the test to avoid the situation. A couple ideas:

1. Set sandboxing via an iframe attribute instead of a header.
2. Make the SW script stash the resultingClientId and only do the clients.get() after the iframe has loaded.