open.window reloads parent window

[Marshall Dudley]

When I do the following line in Netscape, the popup loads as it should,
but the parent window usually, but not always, reloads as well.

<a href="#"
onClick="window .open('/cgi-bin/displayimage.cg i?/store/demo/image.jpg&YOUR+ PRODUCT%27<b>S+ NAME+GOES',
'fullimage', 'WIDTH=420,HEIG HT=405,status=0 ')">

The original window should not reload, but is, and I have tested it with
both version 4.72 and 7.02, and they both do it. IE does not do it.
The big problem is that the original window has security built into it
so it must be called from the right referring url, but when Netscape
reloads this parent window, it neglects to send the original referring
url, so the original page is replaced with an error page as soon as the
above link is clicked.

Is there any workaround for this, where either Netscape will not reload
the original page, or if it does, at least not lose the referring url?

Thanks,

Marshall

[Silvio Bierman]

"Marshall Dudley" <md*****@king-cart.com> wrote in message
news:40******** *******@king-cart.com...

When I do the following line in Netscape, the popup loads as it should,
but the parent window usually, but not always, reloads as well.

<a href="#"
onClick="window .open('/cgi-bin/displayimage.cg i?/store/demo/image.jpg&YOUR+ P
RODUCT%27<b>S+N AME+GOES', 'fullimage', 'WIDTH=420,HEIG HT=405,status=0 ')">

The original window should not reload, but is, and I have tested it with
both version 4.72 and 7.02, and they both do it. IE does not do it.
The big problem is that the original window has security built into it
so it must be called from the right referring url, but when Netscape
reloads this parent window, it neglects to send the original referring
url, so the original page is replaced with an error page as soon as the
above link is clicked.

Is there any workaround for this, where either Netscape will not reload
the original page, or if it does, at least not lose the referring url?

Thanks,

Marshall

Onclick should return false to prevent a reload.

Silvio Bierman

[Matt Kruse]

Marshall Dudley wrote:

<a href="#"
onClick="window .open('/cgi-bin/displayimage.cg i?/store/demo/image.jpg&YOUR+ P
RODUCT%27<b>S+N AME+GOES', 'fullimage', 'WIDTH=420,HEIG HT=405,status=0 ')">

Having a better understanding of the functionality of the onClick handler
will make you realize the problem...

When an onClick handler exists in an <a>, it is fired before the browser
navigates to the href url. It runs whatever script is specified in the
onClick handler, then _based on the return value_ either navigates to the
href or not.

That is, a browser expects the code within onClick to return either true or
false. If true, it will navigate to the href. If false, it will stop
processing an _not_ navigate to the href.

So in your situation, you would want to do:
<a href="#" onClick="window .open(...);retu rn false;">

That way, the onClick will always return false no matter what, and the "#"
href will never be navigated to.

Now, an important note:
Using "#" as your href url can be misleading, because it will simply cause a
reload in many browsers. Also, for users without js enabled, it will do
nothing and give no useful information. A better way to do it is
<a href="/note_about_java script_being_re quired.html" onClick="...;re turn
false;">
That way, non-js users will at least be taken to a page which informs them
of why the link didn't work as expected.

<FAQENTRY> because I expected to see this covered in more detail in the FAQ
but it wasn't... such a common problem should be addressed a little better
in the FAQ, IMO.

--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/

[Lee]

Marshall Dudley said:

When I do the following line in Netscape, the popup loads as it should,
but the parent window usually, but not always, reloads as well.

<a href="#"
onClick="windo w.open('/cgi-bin/displayimage.cg i?/store/demo/image.jpg&YOUR+ PRODUCT%27<b>S+ NAME+GOES',
'fullimage', 'WIDTH=420,HEIG HT=405,status=0 ')">

The original window should not reload, but is, and I have tested it with
both version 4.72 and 7.02, and they both do it. IE does not do it.
The big problem is that the original window has security built into it
so it must be called from the right referring url, but when Netscape
reloads this parent window, it neglects to send the original referring
url, so the original page is replaced with an error page as soon as the
above link is clicked.

Is there any workaround for this, where either Netscape will not reload
the original page, or if it does, at least not lose the referring url?

The workaround is to stop telling the browser to reload the page.

Unless the onClick event handler returns false, the link will be
followed. The link is "#", which is the top of the current page.

As you've found, some browsers choose to guess what you probably
want to happen, rather than doing what you actually tell them.

To correct it, add:
;return false
just before the closing quote of your onclick attribute.

[Marshall Dudley]

Thanks, that fixed it.

Marshall

Silvio Bierman wrote:

"Marshall Dudley" <md*****@king-cart.com> wrote in message
news:40******** *******@king-cart.com...

When I do the following line in Netscape, the popup loads as it should,
but the parent window usually, but not always, reloads as well.

<a href="#"

onClick="window .open('/cgi-bin/displayimage.cg i?/store/demo/image.jpg&YOUR+ P
RODUCT%27<b>S+N AME+GOES',

'fullimage', 'WIDTH=420,HEIG HT=405,status=0 ')">

The original window should not reload, but is, and I have tested it with
both version 4.72 and 7.02, and they both do it. IE does not do it.
The big problem is that the original window has security built into it
so it must be called from the right referring url, but when Netscape
reloads this parent window, it neglects to send the original referring
url, so the original page is replaced with an error page as soon as the
above link is clicked.

Is there any workaround for this, where either Netscape will not reload
the original page, or if it does, at least not lose the referring url?

Thanks,

Marshall

Onclick should return false to prevent a reload.

Silvio Bierman

[Marshall Dudley]

Thanks for the in depth explaination. I will do what you suggest to handle
browsers without javascript enabled.

Marshall

Matt Kruse wrote:

Marshall Dudley wrote:

<a href="#"

onClick="window .open('/cgi-bin/displayimage.cg i?/store/demo/image.jpg&YOUR+ P
RODUCT%27<b>S+N AME+GOES',

'fullimage', 'WIDTH=420,HEIG HT=405,status=0 ')">

Having a better understanding of the functionality of the onClick handler
will make you realize the problem...

When an onClick handler exists in an <a>, it is fired before the browser
navigates to the href url. It runs whatever script is specified in the
onClick handler, then _based on the return value_ either navigates to the
href or not.

That is, a browser expects the code within onClick to return either true or
false. If true, it will navigate to the href. If false, it will stop
processing an _not_ navigate to the href.

So in your situation, you would want to do:
<a href="#" onClick="window .open(...);retu rn false;">

That way, the onClick will always return false no matter what, and the "#"
href will never be navigated to.

Now, an important note:
Using "#" as your href url can be misleading, because it will simply cause a
reload in many browsers. Also, for users without js enabled, it will do
nothing and give no useful information. A better way to do it is
<a href="/note_about_java script_being_re quired.html" onClick="...;re turn
false;">
That way, non-js users will at least be taken to a page which informs them
of why the link didn't work as expected.

<FAQENTRY> because I expected to see this covered in more detail in the FAQ
but it wasn't... such a common problem should be addressed a little better
in the FAQ, IMO.

--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/

[Richard Cornford]

Matt Kruse wrote:

Marshall Dudley wrote: <snip> Now, an important note:
Using "#" as your href url can be misleading, because it will simply
cause a reload in many browsers. Also, for users without js enabled,
it will do nothing and give no useful information. A better way to do
it is <a href="/note_about_java script_being_re quired.html"
onClick="...;re turn false;">
That way, non-js users will at least be taken to a page which informs
them of why the link didn't work as expected.
In the context of the OPs window opening code this doesn't represent
trying very hard to handle the possibilities.

First; while you might be telling the users of javascript
disabled/incapable browsers why the link isn't doing anything, you are
potentially telling lies to the users of javascript capable/enabled
browsers that do not implement the window.open function. For them the
window.open call fails, the onclick handler does not return and the
browser navigates to the URL in the HREF.

Second; there is considerable potential for fall-back for javascript
disabled/incapable browsers in this context. The presentation might not
be quite as intended but opening a URL in a window with default chrome
seems like a reasonable thing to be doing when it isn't possible to open
it in a pre-sized window. Given a suitable HTML version (4.01
transitional) the link may be provided with TARGET attribute so
navigation would open the HREF resource in a new browser window, when
the browser and any accompanying content inserting/re-writing proxy
allowed it.

<a
href="'/cgi-bin/displayimage.cg i?/store/demo/image.jpg&etc"
target="fullima ge"
onclick="window .open(this.href , this.target,
'width=420,heig ht=405,status'; return false"
The referenced resource URL has to move to the HREF but now the users of
normal desktop browsers with javascript disabled will get to see the
image in a new window. Browsers that cannot open new windows will be
navigating within the current window, but that doesn't seem like an
unreasonable next step in a fall-back sequence as they can easily get
back to the page with this link with their back button.

Note the use of - this.href - and - this.target - to avoid repetition of
the information, allowing the same onclick code to be used with other
similar links without modification/editing and avoiding the risk of the
HREF and the - window.open - argument getting out of sync during
maintenance.

Another characteristic of this code is that it is now possible to have
the HREF open in a new window or tab using the context menu, which seems
like useful additional functionality to be providing for the user (as it
is normal (therefore expected) behaviour form a link in a web browser
and it hadn't previously been working because the javascript dependent
version broke it).

As with any window opening attempt this script will be subject to the
influence of pop-up blocking mechanisms so the call to - window.open -
may not result in a new window, or that window may be immediately closed
by an external pop-up blocker.

Without a pop-up blocker the above code does not have a path of
execution that does not result in the user looking at the referenced
resource, javascript enabled or not. With a pop-up blocker there will be
scenarios where the code fails to present the user with the resource,
but that has nothing to do with javascript.

To some extent the influence of pop-up blockers can be detected, and
some permutations would block window.open but allow targeted links so it
might be worth examining the success of the window.open call and
returning true or false from the onclick handler based on the apparent
success of the call. That is too complex to reasonable be implemented in
the code provided as the string value for an onclick attribute. A
separate function that did the window opening, tested the outcome and
returned true when it appeared to fail and false when it appeared to
succeed, would be the obvious approach. Giving an onclick attribute in
the form:-

onclick="return windowOpeningFu nction(this.hre f, this.target');"

Such a function provides the opportunity to verify that the browser
supports the - window.open - function, and examine the results of a call
to it when it does exist. A - null - return value from - window.open -
signifies a blocked window on Opera 7 and Mozilla, but other blocking
mechanisms take much more work (and some are not practically
detectable). Positive indication of failure allows the function to
return true and allow the navigation (and potential use of the TARGET
attribute) as fall-back. Increasing the overall reliability of the
system. Though the only really effective approach to avoiding the
unreliability introduced into the opening of new windows by the use of
pop-up blocking is not to attempt to open new windows.
<FAQENTRY> because I expected to see this covered in more detail in
the FAQ but it wasn't... such a common problem should be addressed a
little better in the FAQ, IMO.

Yes, I have been considering adding a page on HTML attribute event
handling attributes and the functions created from them. Cancelling
events with return values should certainly feature on such a page.

Richard.

[Thomas 'PointedEars' Lahn]

Richard Cornford schrieb:

Matt Kruse wrote:

[...] A better way to do it is <a
href="/note_about_java script_being_re quired.html"
onClick="...;re turn false;"> That way, non-js users will at least
be taken to a page which informs them of why the link didn't work
as expected.
In the context of the OPs window opening code this doesn't represent
trying very hard to handle the possibilities.

First; while you might be telling the users of javascript
disabled/incapable browsers why the link isn't doing anything, you
are potentially telling lies to the users of javascript
capable/enabled browsers that do not implement the window.open
function.

open() is a method of Window objects implemented in *JavaScript* from
version 1.0 on[1] ("DOM Level 0"). It has been moved from the core
language to the Gecko DOM in version 1.5, but I have yet to see a UA
that is capable of J(ava)Script but not of open(). A popup blocker
could block it, though.

Besides, no lies will be told in either case because "return false" will
work anyway. It is much more simple: Nothing seems to happen (unless a
script error is triggered, but then we are talking about JavaScript >
1.3) as the event is canceled.
For them the window.open call fails, the onclick handler does not
return and the browser navigates to the URL in the HREF.

No, neither one will happen. See above.
PointedEars
___________
[1]
<http://devedge.netscap e.com/library/manuals/2000/javascript/1.3/reference/window.html#120 2731>

[Richard Cornford]

Thomas 'PointedEars' Lahn wrote:

Richard Cornford schrieb: <snip> open() is a method of Window objects implemented in *JavaScript* from
version 1.0 on[1] ("DOM Level 0"). It has been moved from the core
language to the Gecko DOM in version 1.5, but I have yet to see a UA
that is capable of J(ava)Script but not of open(). A popup blocker
could block it, though.
Some browsers do not implement a window.open function, for example, Web
Browsers 2.0 on the Palm OS, and Pocket IE, but they are javascript
capable. When browsers operate on devices with tiny displays opening
multiple windows can be an alien concept for the device (and/or OS).

The window.open function is part of the host environment not the
language (it is also not part of any public specification). Language
version considerations don't come into it, if the host cannot open
windows at all not implementing the window.open function is a reasonable
thing for its designers to do.
Besides, no lies will be told in either case because "return false"
will work anyway. It is much more simple: Nothing seems to happen
(unless a script error is triggered, but then we are talking about
JavaScript >
1.3) as the event is canceled.

For them the window.open call fails, the onclick handler does not
return and the browser navigates to the URL in the HREF.

No, neither one will happen. See above.

If you call a function that does not exist an error _is_ produced. So
the onclick handler will not return and the browser will use the HREF.

There is not much point telling the user of such a browser about their
need for javascript because they already have it (javascript wasn't the
problem).

Richard.

[Thomas 'PointedEars' Lahn]

Richard Cornford schrieb:

Thomas 'PointedEars' Lahn wrote:

Richard Cornford schrieb: <snip>

open() is a method of Window objects implemented in *JavaScript* from
version 1.0 on[1] ("DOM Level 0"). It has been moved from the core
language to the Gecko DOM in version 1.5, but I have yet to see a UA
that is capable of J(ava)Script but not of open(). A popup blocker
could block it, though.

Some browsers do not implement a window.open function, for example, Web
Browsers 2.0 on the Palm OS, and Pocket IE, but they are javascript
capable. When browsers operate on devices with tiny displays opening
multiple windows can be an alien concept for the device (and/or OS).

The window.open function is part of the host environment not the
language (it is also not part of any public specification).

That is wrong for JavaScript prior version 1.5. The public Netscape
Client-side JavaScript References have been mentioned. They are what
comes closest to a specification of the JavaScript language (as there
is no language specification for this ECMAScript implementation) .
Language version considerations don't come into it,
They do.
if the host cannot open windows at all not implementing the window.open
function is a reasonable thing for its designers to do.
Then they must implement either JavaScript 1.5, or another or
no implementation of ECMAScript. They must not call the used
implementation JavaScript otherwise because if it is client-side
JavaScript prior to 1.5 there must be a "window" object and an
open() method.

Besides, no lies will be told in either case because "return false"
will work anyway. It is much more simple: Nothing seems to happen
(unless a script error is triggered, but then we are talking about
JavaScript 1.3) as the event is canceled.

For them the window.open call fails, the onclick handler does not
return and the browser navigates to the URL in the HREF.

No, neither one will happen. See above.

If you call a function that does not exist an error _is_ produced. So
the onclick handler will not return and the browser will use the HREF.

Please state the spec or reference where it is defined that if a
statement produces an error, following statements must not be executed.
There is not much point telling the user of such a browser about their
need for javascript because they already have it (javascript wasn't the
problem).

Non sequitur.
PointedEars