Re: scopes, execution contexts, and scripts

Boris Zbarsky wrote:
> On 1/22/10 12:46 AM, John J. Barton wrote:
...
>> /* Top object in the scope chain. */
>> readonly attribute jsdIValue scope;
> 
> This is probably a bit of a misuse of the word "top".
> 
>> Despite the word 'top' here, in practice, you get the scope chain by
>> chasing scope.jsParent. So I'm guessing that the correct comment for the
>> frame.scope would be "youngest object in the scope chain".
> 
> It's not necessarily "youngest" so much.  Just the one that's first to 
> have names looked up in it.

Maybe "innermost" as in "lexically innermost". The stack frames have a 
time basis, but the scope chain axis  is, ah, er, lexical.

> 
>> If I apply the same correction to the globalObject for jsdIContext we'd
>> have "youngest scope for this context", but that does not make any more
>> sense to me.
> 
> Sure.  That's because there's no age anything going on there.

So outermost scope. Or last-to-be-used-for lookup.

> 
>> I guess that frame.executionContext is basically the container for the
>> frames, which is why is not useful for anything. But I'd like to know
>> more about it.
> 
> The executionContext is what I said above: a reflection of the JSContext 
> the script is running on (well, and maybe of the nsIScriptContext). What 
> this means in practice depends on the particular JS embedding; in the 
> case of Firefox each (outer) DOM window has its own JSContext. There are 
> also various other JSContexts floating about (e.g. an XPConnect sandbox 
> gets its own JSContext, temporary JSContexts are used in the component 
> loader, DOM workers have separate JSContexts, that sort of thing).

We need to do some work here.
   sandboxes need identifiers or paths,
   we need a bit more understanding of BackStagePass (all the components 
seem to share one by the way).
   DOM Workers are not debuggable,
   "That sort of thing" needs to be sorted out. esp setTimeout and 
setInterval.

> 
> The JSContext gives the JSAPI consumer the ability to control certain 
> things about how script will be compiled and run (e.g. which JS version 
> will be used, whether jit will be used, whether strict mode should be 
> used etc).

Firebug uses the scriptEnabled control (and that's all).

> 
> As far as debugger usage...  if a cross-window call happens, then the 
> script from one window will end up running on the other windows 
> JSContext: the executionContext doesn't change when such a call occurs. 
>  So it doesn't tell you much about the script you're looking at (other 
> than some data about how it's being run, but NOT data about how it was 
> compiled).

Yes, it is exactly this issue that I am struggling with. Chromebug 
sometimes gets confused and very often Chromebug users get confused. I 
wanted to be sure I was thinking about this correctly.

Chromebug chases the frame.scope to its outermost "global" object and 
uses that to find the HTML/DOM/metadata to show the user for a frame. 
Firebug does the same, but if the result is not a window, it looks into 
older frames until it finds a window.

Arguments to a script may be bound to objects in another window/global. 
The UI then can't be as effective for arguments.

> 
> The globalObject of a JSContext is just some arbitrary object of the 
> embedding's choosing; in Firefox's case it's the JSObject for the outer 
> window.

Right. I was searching for a cached value of the outermost scope of a 
script definition. Every time we hit a hook in jsd we have to find the 
Firebug context to match the running script. I think the debugger would 
be a lot faster if the lookup was faster, but more important the code 
would a lot less obscure.

> 
> Does that help?
> 
> -Boris

Yes! I think Chromebug's confusion is just a bug I need to find, not a 
flaw in my understanding.

jjb