Re: More on workerStart

On 6/6/15 12:22 PM, Justin Rogers wrote:
> As noted the caller for us is very expensive.

That's fair.  I haven't checked how expensive getting the incumbent 
global is in practice in Gecko, fwiw; it requires some form of stack 
walk for us as well.

> Per the other thread if we pass in context:
>    computeWorkerStart(self)
>        or
>    computeWorkerStart(top)
> Then you'd be able to do the time origin calls on a given namespace quite easily.


The main drawback is that it uglifies the API in a worker context, where 
there is only one sane thing you could possibly want to pass in 
("self"), and also uglifies it in the reasonably common case of 
everything happening in a single window.

Maybe the right thing to do is to make the argument optional and default 
it to the global of the Worker/SharedWorker/ServiceWorker object or the 
global of the realm of the function being called (not necessarily the 
same thing, of course, but in the common cases it'll all be the same). 
Then someone who wants the "incumbent global" behavior can just always 
pass "self" explicitly.

I guess that's what you're thinking of too, given your next sentence, 
now that I read it.

> Instances have a global they were created in. People get that.

Sorta kinda.  Spec writers don't seem to get it very much.  :(

> Note: will reply more later but sometimes your incumbent settings are in another process

That's entirely an implementation detail.  Nothing in specs prevents 
multiple parts of the JS heap of a single web page being different 
processes, really...

> You can now pass in any window

We should fix this.  It looks like right now Web IDL only specifies 
performing a security check on the this value, but it should just be 
done on all arguments too.  Gecko already does that, fwiw: if you have 
an API taking Window and you pass a cross-origin Window in, we will 
throw a security exception.

I filed


Received on Monday, 8 June 2015 02:11:53 UTC