RE: More on workerStart

To codify the proposal I think it would look something like:

partial interface AbstractWorker {
    DOMHighResTimeStamp computeWorkerStart([SameOrigin] optional Window timeOriginBasis);
}

With the additional notes of whether or not this represents information disclosure if the [SameOrigin] restriction is removed. This is under the assumption that we add [SameOrigin] or similar annotation capabilities to WebIDL per the bug #28778 below. It's probably easiest to move forward with a same origin check and then relax later if we find useful cases for cross origin. 

The only thing I could think is if you are using postMessage to funnel all of your time deltas into a single cross origin logging domain. While you can post directly from the worker in that case, you could imagine setting up a chain that corrects the value as it goes through. The last step would be cross origin logger frame receives postMessage from cross origin source frame with data value from cross origin worker time values. In that case the best you could do to set the time origin would be to make it relative to the cross origin source frame.

-----Original Message-----
From: Boris Zbarsky [mailto:bzbarsky@mit.edu] 
Sent: Sunday, June 7, 2015 7:11 PM
To: Justin Rogers
Cc: Ilya Grigorik; Jonas Sicking; public-web-perf@w3.org; Przemysław Pietrzkiewicz
Subject: 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.

True.

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 https://www.w3.org/Bugs/Public/show_bug.cgi?id=28778

-Boris

Received on Monday, 8 June 2015 18:14:31 UTC