- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Sat, 06 Jun 2015 08:06:01 -0400
- To: Justin Rogers <justrog@microsoft.com>
- CC: Ilya Grigorik <igrigorik@google.com>, Jonas Sicking <jonas@sicking.cc>, "public-web-perf@w3.org" <public-web-perf@w3.org>, Przemysław Pietrzkiewicz <ppi@google.com>
On 6/6/15 1:58 AM, Justin Rogers wrote: > Incumbency seems problematic. No other Apis that I know of do this. window.postMessage does (to derive the caller origin). The .contentDocument and .contentWindow accessors on <iframe> compare the origin of the thing inside it it to the incumbent settings origin. Property access on a window compares its origin to the incumbent settings origin. window.close checks the incumbent settings origin and whether the incumbent settings global is allowed to navigate the target window. The location.assign and location.replace use the incumbent settings object to determine the responsible browsing context. showModalDialog uses the incumbent settings object to find the responsible browsing context. The MessageChannel constructor uses the incumbent settings object to determine the global of the new MessagePorts. The BroadcastChannel constructor uses the incumbent settings global. The Worker constructor uses the incumbent settings object. I stopped about 2/3 of the way through the whatwg html spec. There are more uses there. > What we do have is caller based detection for Apis that need to resolve security origins and relative Uris. But that isn't this. Per spec, it's exactly the same thing. > Why would we make a new concept here? It's not a new concept... it's all over the HTML spec already. And it requires access to the actual incumbent settings global in some of those cases, not just origins or URIs. So you must have a way of getting the incumbent settings global already if you're implementing those parts of the spec. That's all we're using here. > This feels more like a method call potentially passing in an object to resolve the time origin against. That might be a more explicit way of doing this, yes. So then you'd use it as: worker.getWorkerStart(self) ? -Boris
Received on Saturday, 6 June 2015 12:06:32 UTC