Re: More on workerStart

As noted the caller for us is very expensive. We have to do a stack walk. So few methods need the caller to derive the security context from that computing it on demand is the only way we bother storing it. I also will do a bug hunt today. You also listed things in your list of incumbency that I don't recall us having our walk for :-( so I'll have to see if we have some missing behavior. 

If this isn't a caller relative computation then we can make it very fast. As fast as a normal JS field access since it is just a number. Moving it to a method would not allow this speed but would allow the context to be examined as a member instead of a stack walk. 

For full disclosure we call this caller security and we annotate the API to emit additional logic to do the above at great expense (relatively speaking). I'll look more deeply into it though maybe there is an optimization we've never bothered doing here. It would make since that the immediate requesting script context should be much cheaper if we don't need to do a walk of the entire chain. 

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. I used top since I think it would be most common for telemetry based algorithms. This is also how workerStart would be negative in more cases. It would be explicit which time origin you wanted to be in. Most people would never use it. They'd just pass nothing and we'd use the worker instance global instead. 

Note caller urls used for security are okay. People kinda get it. But they normally don't realize this exists and that it functionally changes things since usually caller and site are identical. We get many bugs per year where the issue is that caller contexts cause someone grief because they don't understand them. Adding it to non security scenarios could be problematic. Getting webidl decorations could be useful since one doesn't exist I don't think today and it could alert people reading specs. 

Instances have a global they were created in. People get that. Though they also don't understand when instance == Constructor is false because instance was in another iframe so maybe any context based operations are confusing :-)

I can imagine if function a gets worker start calls function b which does the same and then the values coming back are different, that might be confusing? Maybe b is a library utility meant to do some more work on the values so original global is irrelevant. 

Note: will reply more later but sometimes your incumbent settings are in another process ala window.open. I'm going to think through that. Similar thoughts with passing a time origin basis to a method. You can now pass in any window which means you can detect the diff between your time origin and a cross domain iframe unless we describe a validation of the time origin. 

>> On Jun 6, 2015, at 5:09 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> 
>> On 6/6/15 2:01 AM, Justin Rogers wrote:
>> Wow that is way better than my points. Taken one step further we implement our getters as functions. So the incumbent would always be the internal getter.
> 
> No, built-ins don't affect the incumbent global.  It's all in the HTML spec; please do read it.
> 
>> I don't think we have any way to get the containing function other than a stack walk.
> 
> You clearly need to have one in terms of black-box behavior if you're implementing what the HTML spec says for a bunch of cases.
> 
> -Boris

Received on Saturday, 6 June 2015 16:22:37 UTC