scopes, execution contexts, and scripts

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

scopes, execution contexts, and scripts

John J Barton
Does anyone understand what jsdIStackframe.executionContext is? How is
it related to jsdIStackframe.scope?

At
http://mxr.mozilla.org/mozilla/source/js/jsd/idl/jsdIDebuggerService.idl#766
we read about jsdIContext

  /* Top of the scope chain for this context. */
  readonly attribute jsdIValue     globalObject;

and at
http://mxr.mozilla.org/mozilla/source/js/jsd/idl/jsdIDebuggerService.idl#841
we read about jsdIStackframe:

      /* Top object in the scope chain. */
      readonly attribute jsdIValue      scope;

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".

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.

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.

jjb


_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: scopes, execution contexts, and scripts

Boris Zbarsky
On 1/22/10 12:46 AM, John J. Barton wrote:
> Does anyone understand what jsdIStackframe.executionContext is?

It seems to be an abstraction for the JSContext the script is running on.

> How is it related to jsdIStackframe.scope?

It's not, in general.

> /* Top of the scope chain for this context. */
> readonly attribute jsdIValue globalObject;

Right.

> and at
> http://mxr.mozilla.org/mozilla/source/js/jsd/idl/jsdIDebuggerService.idl#841
>
> we read about jsdIStackframe:
>
> /* 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.

> 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.

> 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).

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).

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).

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.

Does that help?

-Boris
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: scopes, execution contexts, and scripts

John J Barton
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
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: scopes, execution contexts, and scripts

Boris Zbarsky
On 1/22/10 11:26 AM, John J. Barton wrote:
>>> 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.

As it happens, no.  Lookups follow the parent and prototype chains.
Where those terminate depends on the embedding.  In the Firefox case,
for example, the outermost scope is the inner window's JSObject (whereas
the context's global is the outer window's JSObject).

In particular, when you navigate from one page to another the outermost
scope becomes a new object whereas the context's global doesn't change
object identity (though it does have al tis properties removed).

> "That sort of thing" needs to be sorted out. esp setTimeout and
> setInterval.

setTimeout and setInterval run on the JSContext of the window they were
set on.

> 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.

That seems sensible.

-Boris
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: scopes, execution contexts, and scripts

John J Barton
Boris Zbarsky wrote:

> On 1/22/10 11:26 AM, John J. Barton wrote:
>>>> 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.
>
> As it happens, no.  Lookups follow the parent and prototype chains.
> Where those terminate depends on the embedding.  In the Firefox case,
> for example, the outermost scope is the inner window's JSObject (whereas
> the context's global is the outer window's JSObject).
>
> In particular, when you navigate from one page to another the outermost
> scope becomes a new object whereas the context's global doesn't change
> object identity (though it does have al tis properties removed).

Somehow Firebug manages to work despite having no understanding of these
subtle issues ;-)

>
>> "That sort of thing" needs to be sorted out. esp setTimeout and
>> setInterval.
>
> setTimeout and setInterval run on the JSContext of the window they were
> set on.

But how can I enumerate these things?

jjb
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: scopes, execution contexts, and scripts

Boris Zbarsky
On 1/22/10 3:31 PM, John J Barton wrote:
> But how can I enumerate these things?

Which things?

-Boris
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: scopes, execution contexts, and scripts

John J Barton
Boris Zbarsky wrote:
> On 1/22/10 3:31 PM, John J Barton wrote:
>> But how can I enumerate these things?
>
> Which things?
>
> -Boris

The setTimeout/Intervals jobs waiting.

jjb
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: scopes, execution contexts, and scripts

Boris Zbarsky
On 1/22/10 4:53 PM, John J Barton wrote:
> The setTimeout/Intervals jobs waiting.

So something like bug 532903?

-Boris
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: scopes, execution contexts, and scripts

John J Barton
Boris Zbarsky wrote:
> On 1/22/10 4:53 PM, John J Barton wrote:
>> The setTimeout/Intervals jobs waiting.
>
> So something like bug 532903?
>
> -Boris

No, I was thinking more like a way of enumerating the queued setTimeouts
or getting an event when they are queued/fired, stuff you'd use to
explore the application state. eg "did all 25 of my setIntervals get set
up?" or "golly why do I have 25 setIntervals!".  bug 532903 is more
similar to activity analysis, "where is my time going".

jjb
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: scopes, execution contexts, and scripts

Boris Zbarsky
On 1/22/10 7:45 PM, John J Barton wrote:
> No, I was thinking more like a way of enumerating the queued setTimeouts
> or getting an event when they are queued/fired, stuff you'd use to
> explore the application state. eg "did all 25 of my setIntervals get set
> up?" or "golly why do I have 25 setIntervals!". bug 532903 is more
> similar to activity analysis, "where is my time going".

OK.  Can you file a bug with a description of the sort of information
you'd want?

-Boris
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: scopes, execution contexts, and scripts

John J Barton
In reply to this post by Boris Zbarsky
Boris Zbarsky wrote:

> On 1/22/10 11:26 AM, John J. Barton wrote:
>>>> 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.
>
> As it happens, no.  Lookups follow the parent and prototype chains.
> Where those terminate depends on the embedding.  In the Firefox case,
> for example, the outermost scope is the inner window's JSObject (whereas
> the context's global is the outer window's JSObject).
>
> In particular, when you navigate from one page to another the outermost
> scope becomes a new object whereas the context's global doesn't change
> object identity (though it does have al tis properties removed).

I wonder if this is may help explain why Chromebug never works properly.

I have three interconnected problems. First I end up maintaining refs to
windows with names "about:blank". I don't know what these are.  Second I
end up maintaining refs to windows with chrome URL names but that have
been destroyed (window.closed == true). Third, if I set an unload
handler on the window and remove the refs, then some of my chrome URL
window data is lost.

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.

jjb
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: scopes, execution contexts, and scripts

Boris Zbarsky
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?

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

-Boris
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: scopes, execution contexts, and scripts

John J Barton
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
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: scopes, execution contexts, and scripts

Boris Zbarsky
On 1/25/10 6:18 PM, John J Barton wrote:
> 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.

OK, so this is correctly testing outer window identity.  In particular,
this is the object that (currently) does NOT change identity when you
perform navigation (e.g. clicking a link).

Is that really what you want?

> 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 (win instanceof ChromeWindow) {
     /* It's a chrome window */
   }

> 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.

So I'm curious... at what point is the reference from context to the
global removed?

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

Those all give you outer windows.

> I hope that bug 342715 is planning to do this.

It can build on top of that, yes.

-Boris
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: scopes, execution contexts, and scripts

John J Barton
Boris Zbarsky wrote:

> On 1/25/10 6:18 PM, John J Barton wrote:
>> 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.
>
> OK, so this is correctly testing outer window identity.  In particular,
> this is the object that (currently) does NOT change identity when you
> perform navigation (e.g. clicking a link).
>
> Is that really what you want?

Yes, (I guess) because we don't have any event to tell us about identity
change, so we track link clicking with onLocationChange in Firebug. In
Chromebug I just do something for each case. For example, onOpenWindow
from nsIWindowMediatorListener tells us that a new XUL window arrives,
so we track it's nsIDOMWindow.

>
>> 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 (win instanceof ChromeWindow) {
>     /* It's a chrome window */
>   }

Thanks, but I want the reverse test, I want to know it is a content
window (since I guess there may be Window objects that are not
ChromeWindow objects and not content windows.

>
>> 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.
>
> So I'm curious... at what point is the reference from context to the
> global removed?

Good question! The one I am trying to answer now! For content windows,
pagehide or unload handlers; for ChromeWindows, unload handlers; for
non-windows, my only story so far is exit the app. For non-windows I
think can mark off the deleted scripts as they die, then when they all
go, remove the ref. That assumes that non-windows are only useful for JS.

jjb
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: scopes, execution contexts, and scripts

Boris Zbarsky
On 1/25/10 9:10 PM, John J Barton wrote:
>> if (win instanceof ChromeWindow) {
>> /* It's a chrome window */
>> }
>
> Thanks, but I want the reverse test, I want to know it is a content
> window (since I guess there may be Window objects that are not
> ChromeWindow objects and not content windows.

   if (win instanceof Window && !(win instanceof ChromeWindow))) {
   }

Though you might need Components.interfaces.nsIDOMWindow and
nsIDOMChromeWindow respectively, depending on whether Window and
ChromeWindow do the right thing for cross-scope access.

> Good question! The one I am trying to answer now! For content windows,
> pagehide or unload handlers; for ChromeWindows, unload handlers; for
> non-windows, my only story so far is exit the app.

Hmm...  How common is the non-window case for Firebug (not Chromebug)?

-Boris

_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: scopes, execution contexts, and scripts

John J Barton
Boris Zbarsky wrote:

> On 1/25/10 9:10 PM, John J Barton wrote:
>>> if (win instanceof ChromeWindow) {
>>> /* It's a chrome window */
>>> }
>>
>> Thanks, but I want the reverse test, I want to know it is a content
>> window (since I guess there may be Window objects that are not
>> ChromeWindow objects and not content windows.
>
>   if (win instanceof Window && !(win instanceof ChromeWindow))) {
>   }
>
> Though you might need Components.interfaces.nsIDOMWindow and
> nsIDOMChromeWindow respectively, depending on whether Window and
> ChromeWindow do the right thing for cross-scope access.
>
>> Good question! The one I am trying to answer now! For content windows,
>> pagehide or unload handlers; for ChromeWindows, unload handlers; for
>> non-windows, my only story so far is exit the app.
>
> Hmm...  How common is the non-window case for Firebug (not Chromebug)?

Can't happen by design. There is no path to the context-creation except
from APIs that give nsIDOMWindow.

>
> -Boris
>
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: scopes, execution contexts, and scripts

John J Barton
John J. Barton wrote:
> Boris Zbarsky wrote:
...>> Hmm...  How common is the non-window case for Firebug (not Chromebug)?
>
> Can't happen by design. There is no path to the context-creation except
> from APIs that give nsIDOMWindow.

So we can't debug WebWorkers or Sandbox contexts now.

jjb
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: scopes, execution contexts, and scripts

John J Barton
In reply to this post by Boris Zbarsky
Boris Zbarsky wrote:

> On 1/25/10 6:18 PM, John J Barton wrote:
>> 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.
>
> OK, so this is correctly testing outer window identity.  In particular,
> this is the object that (currently) does NOT change identity when you
> perform navigation (e.g. clicking a link).
>
> Is that really what you want?

In my unload handler for the outer DOM window I get called with window
location = about:blank. But when I clean up the window, it has a new
location and deleting it deletes the information I want:

   // domWindow.location is about blank here...
   setTimeout(function delayCleanup() // to allow the unload handlers to
complete
   {
       // domWindow.location is chrome://test/content/testDialog.xul
       TabWatcher.unwatchTopWindow(domWindow);
   });

So somehow about:blank is getting an unload message but the domWindow
object I obtained from the unload handler event.target.defaultView; is
morphing into the window that supports my dialog.

jjb
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: scopes, execution contexts, and scripts

Boris Zbarsky
On 1/26/10 12:58 PM, John J. Barton wrote:
> In my unload handler for the outer DOM window I get called with window
> location = about:blank

OK, so about:blank is being unloaded (and possibly something else is
being laoded instead).

> // domWindow.location is about blank here...
> setTimeout(function delayCleanup() // to allow the unload handlers to
> complete

So you run this code off a delay...

> // domWindow.location is chrome://test/content/testDialog.xul

Which presumably got loaded instead of the about:blank.

> So somehow about:blank is getting an unload message but the domWindow
> object I obtained from the unload handler event.target.defaultView; is
> morphing into the window that supports my dialog.

Again, a window can have the URI loaded in it change.  This happens all
the time, in fact: if nothing else people browse the web.  When you
navigate from page A to page B the Window object involved (the one you
can get your hands on from script) does NOT change.  Its location.href
does, of course.

-Boris
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
12