Problem with window.open

L

len.hartley

Hi,

I am trying to pop-up a window when the user clicks on an image. The
problem is that when the user clicks on the image and the window pops
up OK, but the window underneath also proceeds to the image. The
desired behavior is that when the pop-up is invoked, I want the
underlying window to stay put.

I don't have this problem when I run the code on my local computer but
I do have it when I run the code on geocities.

The webpage code is simple:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Page title</title>
<script language="JavaScript" type="text/javascript">
var tallParm =
'scrollbars=1,toolbar=0,location=0,directories=0,status=0,menubar=0,resizable=1,height='+(screen.height
- 200)+',width=' + (screen.width - 80);

function pop_tall_image_win (ref) {
window.open(ref,"x",tallParm);
return false;
}
</script>
</head>
<body>
<a href="large.gif" onclick="return
pop_tall_image_win('large.gif')"><img src="small.gif" border="0"></a>
</body>
</html>

The place where I have the page on geocities is:
http://www.geocities.com/sample_issue/index.htm

As a side-note, I still want the link on the image to go to the target,
in case the user decides to use right-mouse open-new-window. That is
why I have the HREF reference.
 
J

jshanman

Hi,

I am trying to pop-up a window when the user clicks on an image. The
problem is that when the user clicks on the image and the window pops
up OK, but the window underneath also proceeds to the image. The
desired behavior is that when the pop-up is invoked, I want the
underlying window to stay put.

I don't have this problem when I run the code on my local computer but
I do have it when I run the code on geocities.

The webpage code is simple:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Page title</title>
<script language="JavaScript" type="text/javascript">
var tallParm =
'scrollbars=1,toolbar=0,location=0,directories=0,status=0,menubar=0,resizable=1,height='+(screen.height
- 200)+',width=' + (screen.width - 80);

function pop_tall_image_win (ref) {
window.open(ref,"x",tallParm);
return false;
}
</script>
</head>
<body>
<a href="large.gif" onclick="return
pop_tall_image_win('large.gif')"><img src="small.gif" border="0"></a>
</body>
</html>

The place where I have the page on geocities is:
http://www.geocities.com/sample_issue/index.htm

As a side-note, I still want the link on the image to go to the target,
in case the user decides to use right-mouse open-new-window. That is
why I have the HREF reference.

try
<a href="large.gif" onclick="pop_tall_image_win('large.gif'); return
false;"><img src="small.gif" border="0"></a>

- JS
http://www.endeavorpub.com
 
R

Richard Cornford

I am trying to pop-up a window when the user clicks on an image.
<a href="large.gif" onclick="return

Assuming that this carriage return is not in the original code (and if
it is the symptoms described still would not be evident as the function
would then ver be called) this code should 'work'.
pop_tall_image_win('large.gif')"><img src="small.gif"
^^^^^^^^^^

Rather than pass the image file to the function as a string literal
use - this.href - as that will pass on the HREF from the A element and
save you having to update both if the image URL needs changing
(eliminating some potential for making mistakes in the process).
border="0"></a>
The place where I have the page on geocities is:
http://www.geocities.com/sample_issue/index.htm
<snip>

The page at this URL does not exhibit the symptoms described (does _not_
navigate away from the page with the link) on Opera 8 or IE 6.

Richard.
 
L

len.hartley

jshanman said:
try
<a href="large.gif" onclick="pop_tall_image_win('large.gif'); return
false;"><img src="small.gif" border="0"></a>

- JS
http://www.endeavorpub.com
--> I just gave that idea a try (labelling the original "1." and this
idea "2.") and both behave the same way -- again not locally but when I
run it on geocities (public Internet?)
 
L

len.hartley

Richard Cornford wrote:
The page at this URL does not exhibit the symptoms described (does
_not_ navigate away from the page with the link) on Opera 8 or IE 6.

--> that's interesting that you are NOT seeing this behavior because I
get it for Firefox 1.0, IE 6.0-SP2 and Netscape 8.1 (and others have
reported it). I don't have Opera and you may have a different service
pack of IE6. It doesn't happen in IE5 (something that I forgot to
mention).

The carriage return isn't in the original code (View Source on
http://www.geocities.com/sample_issue/index.htm might be the best way
to see the code without the NewsGroup wrapping added).

Thanks for the tip on "this.href". If I can solve this problem, it's
something that I'd like to start to use.
 
E

Evertjan.

wrote on 28 apr 2006 in comp.lang.javascript:
Any other ideas to address this?

To addess what?

Please quote what you are replying to. If you want to post a followup via
groups.google.com, don't use the "Reply" link at the bottom of the article.
Click on "show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
<http://www.safalra.com/special/googlegroupsreply/>
 
L

len.hartley

I am wondering if there are any other ideas to address my original
query:

-------ORIGINAL QUERY ------------------------------------------
I am trying to pop-up a window when the user clicks on an image. The
problem is that when the user clicks on the image and the window pops
up OK, but the window underneath also proceeds to the image. The
desired behavior is that when the pop-up is invoked, I want the
underlying window to stay put.

I don't have this problem when I run the code on my local computer but
I do have it when I run the code on geocities.

The webpage code is simple:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Page title</title>
<script language="JavaScript" type="text/javascript">
var tallParm =
'scrollbars=1,toolbar=0,location=0,directories=0,status=0,menubar=0,resizable=1,height='+(screen.height
- 200)+',width=' + (screen.width - 80);

function pop_tall_image_win (ref) {
window.open(ref,"x",tallParm);
return false;
}

</script>
</head>
<body>
<a href="large.gif" onclick="return
pop_tall_image_win('large.gif')"><img src="small.gif" border="0"></a>
</body>
</html>

The place where I have the page on geocities is:
http://www.geocities.com/sample_issue/index.htm

As a side-note, I still want the link on the image to go to the target,
in case the user decides to use right-mouse open-new-window. That is
why I have the HREF reference.

END OF ORIGINAL QUERY ------------------------------------------

1. This was suggested and made no difference:
<a href="large.gif" onclick="pop_tall_image_win('large.gif'); return
false;"><img src="small.gif" border="0"></a>

2. Also, someone queried the line-wrapping and that is just the
newgroup posting adding carriage returns. The full code at:
http://www.geocities.com/sample_issue/index.htm has no extra carriage
returns.

3. I am seeing this in Firefox 1.0, IE 6.0-SP2 and Netscape 8.1 when
accessing the link above (and others have reported it too). Someone
suggested that it might not be happening in Opera but I don't have
Opera so I cannot comment on that.
 
V

VK

I am wondering if there are any other ideas to address my original
query:

-------ORIGINAL QUERY ------------------------------------------
I am trying to pop-up a window when the user clicks on an image. The
problem is that when the user clicks on the image and the window pops
up OK, but the window underneath also proceeds to the image. The
desired behavior is that when the pop-up is invoked, I want the
underlying window to stay put.

I don't have this problem when I run the code on my local computer but
I do have it when I run the code on geocities.

The webpage code is simple:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Page title</title>
<script language="JavaScript" type="text/javascript">
var tallParm =
'scrollbars=1,toolbar=0,location=0,directories=0,status=0,menubar=0,resizable=1,height='+(screen.height
- 200)+',width=' + (screen.width - 80);

function pop_tall_image_win (ref) {
window.open(ref,"x",tallParm);
return false;
}

</script>
</head>
<body>
<a href="large.gif" onclick="return
pop_tall_image_win('large.gif')"><img src="small.gif" border="0"></a>
</body>
</html>


That's an old "wrapper in wrapper" bug (bug? really don't know how to
call it, seems rather a dark spot left in the specs). You have the same
with setting window.status or onsubmit handler on many UA's.

The workaround is the regular one:
....
function f() {
// do stuff
return false;
}
....
<a href="foobar.html" onclick="return f();">
 
L

len.hartley

quote ************
I am wondering if there are any other ideas to address my original
query:
-------ORIGINAL QUERY ------------------------------------------
I am trying to pop-up a window when the user clicks on an image. The
problem is that when the user clicks on the image and the window pops
up OK, but the window underneath also proceeds to the image. The
desired behavior is that when the pop-up is invoked, I want the
underlying window to stay put.
I don't have this problem when I run the code on my local computer but
I do have it when I run the code on geocities.
The webpage code is simple:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Page title</title>
<script language="JavaScript" type="text/javascript">
var tallParm =
'scrollbars=1,toolbar=0,location=0,directories=0,status=0,menubar=0,resizable=1,height='+(screen.height
- 200)+',width=' + (screen.width - 80);
function pop_tall_image_win (ref) {
window.open(ref,"x",tallParm);
return false;
}
</script>
</head>
<body>
<a href="large.gif" onclick="return
pop_tall_image_win('large.gif')"><img src="small.gif" border="0"></a>
</body>
</html>

That's an old "wrapper in wrapper" bug (bug? really don't know how to
call it, seems rather a dark spot left in the specs). You have the same
with setting window.status or onsubmit handler on many UA's.

The workaround is the regular one:
....
function f() {
// do stuff
return false;
}

....
<a href="foobar.html" onclick="return f();">
end of quote **************

I don't see how what you are suggesting in in any way different from
what I have -- from onclick, call a function that always returns false
(which I do). Am I missing something here?
 
V

VK

That's an old "wrapper in wrapper" bug (bug? really don't know how to
call it, seems rather a dark spot left in the specs). You have the same
with setting window.status or onsubmit handler on many UA's.

The workaround is the regular one:
...
function f() {
// do stuff
return false;
}

...
<a href="foobar.html" onclick="return f();">
end of quote **************

I don't see how what you are suggesting in in any way different from
what I have -- from onclick, call a function that always returns false
(which I do). Am I missing something here?

First of all it works with the intended results (if you checked this,
you saw it).

Secondly and formally it is *kind of* the same, but not totally, as it
produces different results. The entire pinpoint explanation can be left
for theory gurus - I'm not one of them.

Basically it's a synchronization problem with event bubbles. By using
in anonymous handler:
onclick="return functionName();" instead of onclick="functionName();
return false;" you ensure the event synchronization by "locking" it in
the current execution context.

Something like this... or something completely else... I was just using
it automatically without thinking of the full background mechanics.

I confirm that at least Opera 9 Beta holds the bubbles as expected, so
your original approach works for it. One could file to Bugzilla either
bug or feature request - depending on what one can read out of specs
(if anything).
 
E

Evertjan.

VK wrote on 29 apr 2006 in comp.lang.javascript:
Basically it's a synchronization problem with event bubbles. By using
in anonymous handler:
onclick="return functionName();" instead of onclick="functionName();
return false;" you ensure the event synchronization by "locking" it in
the current execution context.

Not fully understanding much of this stuff,
I returned to the bubbles in my bath,
... and saw some glimmer of logic in the above.

Could anyone make an experimental little script
demonstrating such synchronisation error?


The below dos NOT do the trick in IE:

<div onclick='alert("div")'>
<a
onclick='x();return false;'
href='#'
<br><br>
<a
onclick='return x();'
href='#'
</div>


<script type='text/javascript'>

function x(){
for(i=0;i<1000;i++)
for(j=0;j<1000;j++)
;
alert('a');
return false;
};

</script>
 
R

Randy Webb

Evertjan. said the following on 4/29/2006 5:23 AM:
VK wrote on 29 apr 2006 in comp.lang.javascript:


Not fully understanding much of this stuff,
I returned to the bubbles in my bath,
... and saw some glimmer of logic in the above.

Forget what you saw as it was a mirage in the desert.
Could anyone make an experimental little script
demonstrating such synchronisation error?

No because its not a problem. The only difference is in where you need
to return true and false. In the first the function has to return true
or false, in the second it doesn't. The advantage of the first is if
there is a script error in the function then you don't crash the page,
the second one could. Crashing the page meaning that your page is now
broken with no navigation.
 
E

Evertjan.

Randy Webb wrote on 29 apr 2006 in comp.lang.javascript:
No because its not a problem. The only difference is in where you need
to return true and false. In the first the function has to return true
or false, in the second it doesn't. The advantage of the first is if
there is a script error in the function

I always write perfect function code.
then you don't crash the page,

What is that "crash the page"?
the second one could. Crashing the page meaning that your page is now
broken with no navigation.

Navigare necesse est!

;-)
 
R

Randy Webb

Evertjan. said the following on 4/29/2006 3:02 PM:
Randy Webb wrote on 29 apr 2006 in comp.lang.javascript:


I always write perfect function code.

Don't we all? :)
What is that "crash the page"?

Broken navigation that depends on script. When an error occurs, no more
scripts execute. Or something like that.
 
R

Richard Cornford

Richard Cornford wrote:
The page at this URL does not exhibit the symptoms described
(does _not_ navigate away from the page with the link) on
Opera 8 or IE 6.

--> that's interesting that you are NOT seeing this behavior
because I get it for Firefox 1.0, IE 6.0-SP2 and Netscape 8.1
(and others have reported it). I don't have Opera and you may
have a different service pack of IE6. It doesn't happen in IE5
(something that I forgot to mention).

As it happens viewing the page in Firefox did exhibit the problem, and
so allow its cause to be identified.
The carriage return isn't in the original code (View Source
on http://www.geocities.com/sample_issue/index.htm might be
the best way to see the code without the NewsGroup wrapping
added).

The newsgroup didn't add any wrapping, that was done by your positing
software and so is your personal responsibility. The base way of
avoiding it is as described in the FAQ (or the liked material).
Thanks for the tip on "this.href". If I can solve this problem,
it's something that I'd like to start to use.

It is a good idea, and if you use the TARGET attribute in the A element
you can also pass that onto pop-up window scripts as - this.target -,
and it will turn out that adding - "tartget="_blank" - to your like may
solve your problem in the simplest way.

Now to the issue itself. My first problem with your code was that it
should 'work' properly. That is, if it encounters a pop-up blocker or a
browser that does not implement - window.open - it won't actually work
at all (or will work unexpectedly) but on a common desktop browser with
pop-ups enabled and not blocked it should do what it was written to do.
As a result trying it in a couple of browsers and finding that it did
indeed work made this look like a non-issue.

In case you haven't guessed by now, VK's explanation is another of his
fantasies; a fiction made up off the top of his head and without any
meaning in relation to javascript and browser scripting. He seems to
believe this nonsense himself, no matter how often it is demonstrated
wrong, leaving everyone else with little choice but attribute his
postings to mental illness. Unfortunately people who don't know
javascript can be taken in by his ravings, and in fact he has stated
that impressing those who don't know any better is one of his aims.

Any analyses of an issue must account for the symptoms. Here the
symptoms are that your onclick handler successfully opens the pop-up
window and the page itself is navigated to the URL in its HREF
attribute. When a page navigates to the URL specified in its HREF, where
the link has an onclick attribute that returns false, the usual
explanation is that the onclick handler actually errored and so did not
return at all. This is quite common when the onclick code is attempting
to open pop-up windows because attempts to open, or interact with,
windows in the presence of pop-up blockers (of various sorts) can cause
exceptions to be thrown.

However, the action of pop-up blockers can be dismissed entirely when
one of the symptoms is that the window actually opened. If an error is
generated then it can only happen after the call to - window.open -, as
that call must have executed successfully. And there are only two
statements executed following the call to - window.open -, two return
statements. The return statement cannot throw an exception unless an
error is generated when evaluating the expression that is returned,
and - false - cannot fail to be successfully resolved in javascript as
it is a direct reference to one of the Boolean values. The fact that no
error is reported (in, for example, firefox's javascript console,
confirms this impression.

Thus, the code used, and posted here, cannot account for the symptoms
described; it should (broadly) work as expected. So it is necessary to
look of external explanations for the phenomenon. Viewing the source of
the page in a browser that exhibits the symptoms reveals that the
geocities server is inserting many elements into the page, including a
number of SCRIPT elements. Examining the scripts inserted with these
elements identified the cause of the unexpected page navigation. This
file:-

<quote cite="http://us.geocities.com/js_source/geovck08.js">
var d=document,w=window,
h=location.hostname,fC=false,fO=false,day=new Date();
var id=''+day.getFullYear()+day.getDate()+'';
var tF='http://' + h + '/js_source/tab04.html';
var aF='http://' + h + '/js_source/adframe07.html';
var mP=location.href,cP=mP;
var tW="16",oW="184",cW="0",aW=oW;
var ts=(new Date()).getTime();
var mFr="m"+ts,tFr="t"+ts,sFr="s"+ts;
var oFR = '<frameset id="FR" cols="*,'+tW+','+aW+
'" frameborder="NO" border="0" framespacing="0">';
var oMF = '<frame id="'+mFr+'" name="'+mFr+
'" noresize="noresize" frameborder="0" src="';
var cMF = '">';
var oTF = '<frame id="'+tFr+'" name="'+tFr+
'" noresize="noresize" frameborder="0" src="' + tF + ' ">';
var oAF = '<frame id="'+sFr+'" name="'+sFr+
'" noresize="noresize" frameborder="0" src="' + aF +'">';
var cFR = '</frameset>';

function wt(){
top.d.title = eval('top.'+mFr+'.document.title');
}

function ssF(){
if(d.getElementById==null){
d.getElementById=d.all
};
if(fO==false){
eval(
'top.d.getElementById("FR").setAttribute("cols","*,'+
tW+','+aW+'");'
);
fO=true;
}else{
aW=cW;
eval(
'top.d.getElementById("FR").setAttribute("cols","*,'+
tW+','+aW+'");'
);
fO = false; aW=oW;
}
wt();
}

if ((self==top)){
if(cP.indexOf(id)<0){
w.onload=function(){
ssF();
}
if (cP.indexOf("#")>-1){
sg=cP.split("#");
mP=sg[0]+'?'+id+'#'+sg[1];
}else{
mP+='?'+id;
}
d.write(oFR+oMF+mP+cMF+oTF+oAF+cFR);
}else{
fC=true;
}
}


function isBase(){
var numB=0;
numB=document.getElementsByTagName("BASE").length;
isB=(numB>0) ? true : false; return isB;
}

function cH(e){
e=e||window.event;
var tgt=e.target||e.srcElement;
if((e.shiftKey)||(e.ctrlKey)||(e.button>=2)){
return e;
}
if ((tgt)&&(tgt.nodeName=="A")){
var uPath=tgt.pathname;
var uHash=tgt.hash;
var uHref=tgt.href;
var uHostname=tgt.hostname;
var uTarget=tgt.target;
var uNodename=tgt.nodeName;
var uProt=tgt.protocol;
}else if (
(tgt.parentNode)&&(tgt.parentNode.nodeName=="A")
) {
var uPath=tgt.parentNode.pathname;
var uHash=tgt.parentNode.hash;
var uHref=tgt.parentNode.href;
var uHostname=tgt.parentNode.hostname;
var uTarget=tgt.parentNode.target;
var uNodename=tgt.parentNode.nodeName;
var uProt=tgt.parentNode.protocol;
}else if (
(tgt.parentNode.parentNode)&&
(tgt.parentNode.parentNode.nodeName=="A")
) {
var uPath=tgt.parentNode.parentNode.pathname;
var uHash=tgt.parentNode.parentNode.hash;
var uHref=tgt.parentNode.parentNode.href;
var uHostname=tgt.parentNode.parentNode.hostname;
var uTarget=tgt.parentNode.parentNode.target;
var uNodename=tgt.parentNode.parentNode.nodeName;
var uProt=tgt.parentNode.parentNode.protocol;
}else if (
(tgt.parentNode.parentNode.parentNode)&&
(tgt.parentNode.parentNode.parentNode.nodeName=="A")
) {
var uPath=tgt.parentNode.parentNode.parentNode.pathname;
var uHash=tgt.parentNode.parentNode.parentNode.hash;
var uHref=tgt.parentNode.parentNode.parentNode.href;
var uHostname=tgt.parentNode.parentNode.parentNode.hostname;
var uTarget=tgt.parentNode.parentNode.parentNode.target;
var uNodename=tgt.parentNode.parentNode.parentNode.nodeName;
var uProt=tgt.parentNode.parentNode.parentNode.protocol;
}else{
return e;
}
if (uProt!="http:") return;
if (d.getElementsByTagName("IFRAME").length>0){
var foundOne=false;
var nI=d.getElementsByTagName("IFRAME").length;
for (i=0; i<nI; i++){
if(
(d.getElementsByTagName("IFRAME").name!="")&&
((d.getElementsByTagName("IFRAME").name)==(uTarget))
){
foundOne=true;
break;
}
}
if(foundOne==true){
return;
}
foundOne=false;
}
if((top.w.frames[0].length<=0)){
if (uHref.indexOf(id)>-1){
tHref = uHref.split("?");
uHref=tHref[0]+uHash;
eval("location.href=uHref;");
}else if(uHref.indexOf('#')>-1){
eval("location.href=uHref;");
}
}
var ytg = uTarget;
ytg=ytg.toLowerCase();
if ((ytg.indexOf("new")>-1)||(ytg.indexOf("blank")>-1)){
return;
}
if ((ytg.indexOf("self")>-1)&&(top.w.frames[0].length>0)){
return;
}
if((uHref)&&(top.w.frames[0].length!=0)&&(uHref.indexOf("#")>-1)){
return;
}
if ((tgt)&&(!fC)) {
if (uNodename=="A") {
if ((uHostname.indexOf("geocities.com"))>-1){
if((uHref.indexOf("#")<=-1)&&(frames.name==mFr)){
fO=false;ssF();
top.location.href=uHref;
}else if(
(
(top.w.frames[0].length)-
(d.getElementsByTagName("IFRAME").length)!=0)&&
(uHref.indexOf("#")<=-1)
){
if ((uTarget)&&(uTarget!=sFr)&&(uTarget!=tFr)) {

}else{
if(isBase()) {
uTarget=document.getElementsByTagName("BASE")[0].target;
return;
}
location.href=uHref;
}
}else{
top.location.href=uHref;
return false;
}
}else{
top.d.location.href=uHref;
}
}else{
return e;
}
}
}

d.onclick=cH;
</quote>

- included in the page (presented here re-formatted for clarity).

This file adds an - onclick handler to the document. This handler
attempts to compensate for geocities efforts to add advertising. That
advertising would be presented in a frameset, and so when navigation
within a page is expected geocities's addition of a frameset would make
it navigation inside the frameset, and then geocities would (attempt to)
make that new page into another frameset. To avoid this they use the
document's onclick handler to intercept clicks on A elements and try to
do what the link would have done otherwise. Unfortunately geocities
employ very unskilled script authors and their efforts are misguided and
error prone. Your issue is a direct result, as they cannot tell that the
click event was cancelled by your onclick handler so they try to
navigate the page to the URL in the HREF by assigning the URL to the -
location.href - property of the page.

You can easily see that the geocities script authors are inept because
the code includes:-

eval("location.href=uHref;");

Which means that the script's author doesn't even know enough to see why
the above can be substituted with the simpler and more direct:-

location.href=uHref;

- to precisely the same effect.

It looks like the author of the script did actually realise that
attempts to open links in new windows did not require then action of
this script, so if you add the attribute - target="_blank" - the script
will assume that it does not need to act upon the clicking on the link.

An alternative solution would be to find a hosting company that does not
insert scripts into your pages, that will eliminate the possibility of
future problems resulting form the less than intelligent scripts
inserted by geocities.

Richard.
 
E

Evertjan.

Randy Webb wrote on 30 apr 2006 in comp.lang.javascript:
Don't we all? :)


Broken navigation that depends on script. When an error occurs, no more
scripts execute. Or something like that.

This being only important for the few wretched souls,
that don't write perfect code?

Never seen one in this NG.

Something like this?

[experimental, do not copy!]

<a href='http://www.cnn.com/'
xonclick='location.hrefFF="http://bbc.co.uk/";return false'>
To the BBC
</a>

going to CNN?
 
E

Evertjan.

Evertjan wrote on 30 apr 2006 in comp.lang.javascript:
Something like this?

[experimental, do not copy!]

<a href='http://www.cnn.com/'
xonclick='location.hrefFF="http://bbc.co.uk/";return false'>
To the BBC
</a>

That was not effective in showing anything.

It seems I am not good at writing intentionally bad code.

The below shows no difference between

onclick='f();return false;'>
and
onclick='return f();'>


=========================================

<script type='text/javascript'>

function bad(){
var a = notExistingVariable;
return false;
}

function good(){
var a = 7;
return false;
}

</script>

<a href='http://bbc.co.uk/' target='_blank'
onclick='bad();return false;'>
To the BBC
</a>
<br>
<a href='http://bbc.co.uk/' target='_blank'
onclick='return bad();'>
To the BBC
</a>
<br>
<a href='http://bbc.co.uk/' target='_blank'
onclick='!bad();return false;'>
To the BBC
</a>
<br>
<a href='http://bbc.co.uk/' target='_blank'
onclick='return !bad();'>
To the BBC
</a>

<br><br>
<a href='http://bbc.co.uk/' target='_blank'
onclick='good();return false;'>
Not to the BBC
</a>
<br>
<a href='http://bbc.co.uk/' target='_blank'
onclick='return good();'>
Not to the BBC
</a>
<br>
<a href='http://bbc.co.uk/' target='_blank'
onclick='return !good();'>
To the BBC
</a>
 
R

Richard Cornford

Evertjan. wrote:
The below shows no difference between

onclick='f();return false;'>
and
onclick='return f();'>
<snip>

In the event that an exception is thrown during the execution of the -
f - function the fact that it is not caught in the event handler means
that the event handler will also throw an exception and so the final -
return false; - will never be executed in the first variant. There is
little practical difference between the two.

The second is probably the preferable formulation because it allows
the - f - function to make intelligent decisions about whether the event
handler will cancel the default action or not; cancelling it in the
event of successful execution of the function and not cancelling it if
the - f - function can anticipate and avoid errors, detect unsuccessful
action (such as the - window.open - call returning null) or catch but
not handle any exceptions thrown. Thus allowing the default action of
the event to facilitate fall-back in a controlled manor.

Richard.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top