Prev: Cheap Wholesale Adidas Shoes (paypal payment)
Next: validation has syntax errors
From: Thomas 'PointedEars' Lahn on 3 Aug 2010 13:40
RobG wrote:

> On Aug 3, 2:53 pm, "me" <m...(a)example.com> wrote:
>> "Andrew Poulos" <ap_p...(a)hotmail.com> 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?

> 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.
Preventing scripts from promoting windows, as you call it, which is
effectively disabling the effect of the focus() method, does not
prevent the `focus' *user* event from being created, of course.

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

>> > Is 3 the best way to go.
>>
>> Have you tried attaching an onbeforeunload event
>
> That (Microsoft proprietary) event will fire on events other than
> window.close:
>
> <URL: http://msdn.microsoft.com/en-us/library/ms536907%28v=vs.85%29.aspx

Microsoft uses a weird (IMHO wrong) terminology in their event model. HTML-
and other-DOM-wise, `onbeforeload' is not an event; it is an event handler.
The corresponding event (type) would be `beforeunload'. Incidentally, while
that event type and event handler originated in the MSHTML DOM (which would
justify "Microsoft proprietary") neither is MSHTML-only:

<https://developer.mozilla.org/en/DOM/window.onbeforeunload>

That said,
<https://developer.mozilla.org/en/window.open#Avoid_resorting_to_window.open()>.


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
From: Thomas 'PointedEars' Lahn on 3 Aug 2010 13:45
Andrew Poulos wrote:

> On 3/08/2010 4:40 PM, RobG wrote:
>>> Have you tried attaching an onbeforeunload event
>> That (Microsoft proprietary) event will fire on events other than
>> window.close:
>>
>> <URL: http://msdn.microsoft.com/en-us/library/ms536907%28v=vs.85%29.aspx
>
> Dang, what about adding an invisible iframe with an unload event?

What about double-checking everything you read?


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
From: Thomas 'PointedEars' Lahn on 3 Aug 2010 13:53
Jeff North wrote:

> Read up on it: http://orangoo.com/labs/GreyBox/
> Try the on-page demo.

Not accessible, misuse of CSS, browser sniffing. Strongly recommended
against, especially for an LMS.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: SAM on 3 Aug 2010 18:11
Le 8/3/10 7:27 AM, Andrew Poulos a �crit :
>
> - if the course changes the URL of its window doesn't that kill any
> events attached to the window?

I think that "attached" onunload and onbeforeunload
will fire anyway, no ?

--
sm
From: RobG on 3 Aug 2010 20:55
On Aug 4, 3:40 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> RobG wrote:
> > On Aug 3, 2:53 pm, "me" <m...(a)example.com> wrote:
> >> "Andrew Poulos" <ap_p...(a)hotmail.com> 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.


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

[...]
> >> > 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.
When the opener gets focus, it can check to see if the child has been
closed:

function windowStillOpen(windowRef){
return !!windowRef && !windowRef.closed;
}

The closed property has not been standardised, however it is widely
supported.


> >> > Is 3 the best way to go.
>
> >> Have you tried attaching an onbeforeunload event
>
> > That (Microsoft proprietary) event will fire on events other than
> > window.close:
>
> > <URL:http://msdn.microsoft.com/en-us/library/ms536907%28v=vs.85%29.aspx
>
> Microsoft uses a weird (IMHO wrong) terminology in their event model. HTML-
> and other-DOM-wise, `onbeforeload' is not an event; it is an event handler.
> The corresponding event (type) would be `beforeunload'. Incidentally, while
> that event type and event handler originated in the MSHTML DOM (which would
> justify "Microsoft proprietary") neither is MSHTML-only:

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


--
Rob
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Cheap Wholesale Adidas Shoes (paypal payment)
Next: validation has syntax errors