Incumbency seems problematic. No other Apis that I know of do this. Basically
take the method, gets its script environment, then get its global is instance,
then convert that back to a script site. It's actually even more complicated
than that in our case. Maybe less so for others. Basically you are tying
together non platform objects to get to platform objects to resolve the time
origin.
What we do have is caller based detection for Apis that need to resolve
security origins and relative Uris. But that isn't this.
Why would we make a new concept here? Or is there an API you can share that
behaves like this?
This feels more like a method call potentially passing in an object to resolve
the time origin against. Otherwise the concept breaks duck typing and global
reuse of functions across script contexts by assigning too much meaning to the
function instance.
> On Jun 5, 2015, at 10:33 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:
>
>> On 6/6/15 1:13 AM, Justin Rogers wrote:
>> I'm a little bit confused. Shouldn't the workerStart just look at the time
>> origin of the global object of the worker instance?
>
> That depends on what we want out of it.
>
>> I'm not familiar with the wording of incumbent settings object, so maybe I'm
>> confusing something.
>
> The incumbent settings object is, loosely speaking, "the settings object
> corresponding to the global of the code that made the call into the API".
>
>> If this is possible then workerStart is the difference between the time
>> origins of the worker instance global and the attached WorkerGlobalScope
>> global.
>
> No, that's precisely what it's not if we do the incumbent settings thing.
> What you propose would allow you to convert the performance.now() time from
> inside a worker to something sane only if you happen to know which global's
> constructor the worker came from (and hence can use that global's
> performance.now() or can measure its offset from yourself and use your own
> performance.now()).
>
> Again, the point of the incumbent settings thing is so the comment in the
> following code is true no matter what global the worker w came from:
>
> w.onmessage = function (e) {
> var timeFromWorker = e.data;
> var timeInOurTimeline = timeFromWorker + w.workerStart;
> // timeInOurTimeline can be compared to performance.now() calls
> // made in this function.
> }
>
> Making workerStart just look at the time origin of the global the worker
> instance is associated with does not satisfy the comments in that code.
> Maybe that's OK, of course. I'm just saying if we _do_ want that property
> then we should use the incumbent settings object.
>
> -Boris
