Re: More on workerStart

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