From: Thomas 'PointedEars' Lahn on
RobG wrote:

> Thomas 'PointedEars' Lahn wrote:
>> RobG wrote:
>> > "me" wrote:
>> >> "Andrew Poulos" wrote [...]:
>> >> > I'm opening a new window which displays a 3rd party elearning
>> >> > course. The user may close the course at any time. Whenever the
>> >> > course is closed I need to trigger some code in window.opener.
>> >
>> > You could offer a close button and hope they use it. What if they
>> > close the opener while the child is still around?
>>
>> Since it is code in the opener that should be triggered when the course
>> (child) window is closed, that code should be triggered then and the
>> child
>> window should be closed, too. The Gecko DOM also supports the
>> "dependent" window feature for that, but it "is currently under revision
>> to be removed":
>>
>>
<https://developer.mozilla.org/en/window.open#Toolbar_and_chrome_features>
>>
>> > You could also put a focus listener on the opener. If it gets focus,
>> > check for the opened window.
>> What does this have to do with closing the course window?
>
> The opener getting focus is a hint to check whether the child window
> has been closed.

That is a very unreliable and inefficient approach. You cannot expect the
opener to be focused when relevant child windows are closed, nor does it
make sense to check all relevant child windows whenever the opener receives
the focus.

>> > Note that some browsers will allow a user to prevent script from
>> > moving, resizing or promoting windows.
>> Many will, but this has nothing to do with a `focus' event listener.
>
> It is a general issue to be dealt with when opening and closing
> windows using script.

You are mistaken. Those preferences are related to *calling* the moveTo(),
moveBy(), resizeTo(), resizeBy(), and focus() *methods* of Window instances
*from* user *code*.

> [...]
>> >> > 3. using setinterval and polling for an open course window.
>> >
>> > Ugly. :-( Use focus().
>>
>> How, IYHO, can focus() help to determine if the child (course) window is
>> still open? (Catch the exception? That would not be less ugly, and
>> hardly reliable.) ISTM you are confusing things here.
>
> Usually when a dependent window is closed, focus goes to the opener.

Rest assured that there is nothing that could be considered usual there. If
the opener is focused when the window opened from it is closed, that must be
considered mere coincidence. Far too much depends on how the GUI implements
popup windows, if at all.

> I think it's worthwhile to know what is part of a standard and what
> isn't. HTML5 (WD 2010/06/24) includes a beforeunload event type for
> the window object:
>
> <URL: http://www.w3.org/TR/html5/browsers.html#the-window-object >
>
> so it may well be standardised soon.

I would like to see that standardized as part of W3C DOM Level 3 Events
instead (since there is a widely implemented WD already), but thanks for the
information.

> For some reason, the closed property has not been included in HTML5 (so
> far). It seems to me that if an open method is provided, it is useful to
> be able to tell easily if the window is still open.

I agree. Many such inconsistencies need to be resolved before HTML 5 can
become a Web standard.


PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004)
From: Ry Nohryb on
On Aug 3, 7:27 am, Andrew Poulos <ap_p...(a)hotmail.com> wrote:
> On 3/08/2010 2:53 PM, me wrote:
>
>
>
>
>
>
>
>
>
> > "Andrew Poulos"<ap_p...(a)hotmail.com>  wrote in message
> >news:8MmdnfFOIrEnAcrRnZ2dnUVZ_g-dnZ2d(a)westnet.com.au...
> >> I'm opening a new window which displays a 3rd party elearning course. The
> >> user may close the course at any time. Whenever the course is closed I
> >> need to trigger some code in window.opener. I thought of:
>
> >> 1. creating a frameset and putting the course in it but that means that
> >> the course has to call window.top.close() otherwise my unload code in the
> >> frameset won't run because:
> >>     the course might "wrongly" call window.close().)
> >>     the course might have frame busting code
>
> >> 2. appending some of my own code to the course but I don't know what the
> >> course developer may do to the page. They might go to a new page.
>
> >> 3. using setinterval and polling for an open course window.
>
> >> Is 3 the best way to go.
>
> > Have you tried attaching an onbeforeunload event to the new window from
> > within the opener window ? You may run into problems with security
> > settings if the 3rd party content is on another server, though.
>
> Hmm, its unlikely that the course will be on a different server though:
>
> - in elearning courses using onbeforeunload is not an uncommon way to
> update a user's course status before they close the course so it might
> be already assigned (but I could use addeventlistener.)
>
> - if the course changes the URL of its window doesn't that kill any
> events attached to the window? So do I need to check whether the window
> has indeed been closed and, if it hasn't, attach onbeforeonload again???
>
> Andrew Poulos

var childWindow= window.open("");
childWindow.onunload= function () { alert("childWindow closed") };

--
Jorge.
From: Ry Nohryb on
On Aug 7, 11:30 am, Ry Nohryb <jo...(a)jorgechamorro.com> wrote:
> On Aug 3, 7:27 am, Andrew Poulos <ap_p...(a)hotmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On 3/08/2010 2:53 PM, me wrote:
>
> > > "Andrew Poulos"<ap_p...(a)hotmail.com>  wrote in message
> > >news:8MmdnfFOIrEnAcrRnZ2dnUVZ_g-dnZ2d(a)westnet.com.au...
> > >> I'm opening a new window which displays a 3rd party elearning course.. The
> > >> user may close the course at any time. Whenever the course is closed I
> > >> need to trigger some code in window.opener. I thought of:
>
> > >> 1. creating a frameset and putting the course in it but that means that
> > >> the course has to call window.top.close() otherwise my unload code in the
> > >> frameset won't run because:
> > >>     the course might "wrongly" call window.close().)
> > >>     the course might have frame busting code
>
> > >> 2. appending some of my own code to the course but I don't know what the
> > >> course developer may do to the page. They might go to a new page.
>
> > >> 3. using setinterval and polling for an open course window.
>
> > >> Is 3 the best way to go.
>
> > > Have you tried attaching an onbeforeunload event to the new window from
> > > within the opener window ? You may run into problems with security
> > > settings if the 3rd party content is on another server, though.
>
> > Hmm, its unlikely that the course will be on a different server though:
>
> > - in elearning courses using onbeforeunload is not an uncommon way to
> > update a user's course status before they close the course so it might
> > be already assigned (but I could use addeventlistener.)
>
> > - if the course changes the URL of its window doesn't that kill any
> > events attached to the window? So do I need to check whether the window
> > has indeed been closed and, if it hasn't, attach onbeforeonload again???
>
> > Andrew Poulos
>
> var childWindow= window.open("");
> childWindow.onunload= function () { alert("childWindow closed") };

Note that the childWindow will be fully retained in memory for as long
as a reference to it exists any/somewhere. IOW, given the above
example, even if childwindow were closed by the user, none of its
resources would be freed nor GCed until after/unless you did a
childWindow= null.
--
Jorge.