- 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