- From: Ben Kelly <notifications@github.com>
- Date: Mon, 19 Jun 2017 20:00:55 -0700
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/issues/1091/309631215@github.com>
> reserved client: reserved environment for nested.html request (this is different from the f2f decision)
Do you mean a new reserved client that is different from the about:blank initial document client? Which client does the final document end up with?
Either way you are suggesting that the client ID for a global change during its lifetime. That seems like a bad invariant to break.
And all of this is observable to the service worker. Consider this:
```
<!doctype html>
<!-- top.html -->
<html>
<body>
<!-- declaratively defined iframe -->
<iframe src="nested.html" id="nested"></iframe>
<script>
let frame = document.getElementById("nested");
frame.contentWindow.navigator.serviceWorker.postMessage(evt => {
// do stuff and post back to the service worker
evt.source.postMessage(someMsg);
});
</script>
</body>
</html>
```
A clients.matchAll() can get and postMessage() to the initial about:blank. Of course the final window is also accessible as well. I think the service worker could get confused if the MessageEvent.source.id changes over time for the same global.
I understand this is complex, but this is the cost of exposing the browser's underlying window/global model via a primitive API like Clients. The about:blank replacement complexity is already there. The primitive needs to reflect that to be honest about what is really happening.
--
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/1091#issuecomment-309631215
Received on Tuesday, 20 June 2017 03:01:33 UTC