scopes, execution contexts, and scripts

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

Re: scopes, execution contexts, and scripts

John J Barton
Boris Zbarsky wrote:
> 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).

and how to distinguish the (and possibly..) case from
unload-because-we-are-being-deleted.

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

And so to handle this case, I guess I need to track onLocationChange
events for every nsIDOMWindow?  I don't understand how to tell if a
window is being destroyed after unload vs being reused.

>
> -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/26/10 2:04 PM, John J. Barton wrote:
> and how to distinguish the (and possibly..) case from
> unload-because-we-are-being-deleted.

You can't.  But onload does mean whatever was in that window before is gone.

> And so to handle this case, I guess I need to track onLocationChange
> events for every nsIDOMWindow? I don't understand how to tell if a
> window is being destroyed after unload vs being reused.

You can't tell right now.

I plan to add a notification (with the window id) when a window is "torn
down" sometime in the next 1-1.5 weeks.

-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/26/10 2:04 PM, John J. Barton wrote:
>> and how to distinguish the (and possibly..) case from
>> unload-because-we-are-being-deleted.
>
> You can't.  But onload does mean whatever was in that window before is
> gone.
>
>> And so to handle this case, I guess I need to track onLocationChange
>> events for every nsIDOMWindow? I don't understand how to tell if a
>> window is being destroyed after unload vs being reused.
>
> You can't tell right now.
>
> I plan to add a notification (with the window id) when a window is "torn
> down" sometime in the next 1-1.5 weeks.
>
> -Boris

Ok, in the meantime I can delete the metadata about the unloaded window
on the unload handler without delay and new metadata for the window will
be created.  It means that unload handlers may not debug if they fire
after mine.

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
John J. Barton wrote:

> Boris Zbarsky wrote:
>> On 1/26/10 2:04 PM, John J. Barton wrote:
>>> and how to distinguish the (and possibly..) case from
>>> unload-because-we-are-being-deleted.
>>
>> You can't.  But onload does mean whatever was in that window before is
>> gone.
>>
>>> And so to handle this case, I guess I need to track onLocationChange
>>> events for every nsIDOMWindow? I don't understand how to tell if a
>>> window is being destroyed after unload vs being reused.
>>
>> You can't tell right now.
>>
>> I plan to add a notification (with the window id) when a window is
>> "torn down" sometime in the next 1-1.5 weeks.
>>
>> -Boris
>
> Ok, in the meantime I can delete the metadata about the unloaded window
> on the unload handler without delay and new metadata for the window will
> be created.  It means that unload handlers may not debug if they fire
> after mine.

Just FYI, (or me I suppose) the XBL destructors seem to run after the
unload event handlers, so again I find myself re-creating metadata for a
dead window. (The unload runs, deletes my context, the XBL destructor
compiles, I track it back to the outer DOM window context, create a new
context for it). Similarly XBL fields. In fact the unload event comes
earlier than I expected. So for the outer DOM window in a XUL window, I
queue the closer and trigger it when the global event
xul-window-destroyed arrives (which is very late).

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