Re: scopes, execution contexts, and scripts

Boris Zbarsky wrote:
> On 1/25/10 2:34 AM, John J. Barton wrote:
>> I have a decent solution for finding objects as they arrive but I can't
>> figure out how to un-find them when they leave. Maybe my ideas about
>> what defines object identity is incorrect.
> 
> What are your ideas?

We start with a reference that comes from some API call. We first test it:
    if (global instanceof Window)
If true, we chase the global.parent until it is null or equal to itself, 
then test
    if (context.window == rootWindow)
where context.window is set to a previous reference from the same(?) API 
call.

I can see this is wrong: we should use the child window directly in 
chromebug, not the top window as in Firebug.  So I need to test whether 
the window is a content or chrome  window. The only way I know how to do 
this is with some bizarre nsIDocShellTreeItem.itemType test. Is there a 
better way?

If the global is not a Window, then we test (context.global == global), 
where context.global was set to a global from a previous call.

Now about those API calls that give the references we believe are windows:

In Firebug there are two paths:
   1) via progress.DOMWindow in onLocationChange: function(progress, 
request, uri)
   2) we get network request and get an nsIWebProgress from it, and 
progress.DOMWindow again.

In Chromebug I've tried lots of things. Currently
   1) onload handler for the outer DOMWindow of a XUL window 
(event.target.defaultView).
   2) mouse enter handler for inspect, node.ownerDocument.defaultView;
   3) outermost global scope on the first JS statement execution.

Obviously based on the above, I am relying on these paths to all give 
similar objects.

> 
> Would creating unique IDs for all inner/outer windows, and notifying on 
> window destruction by id, help?

I hope that bug 342715 is planning to do this.

jjb

> 
> -Boris