Anchor element follows HREF even though onClick returns false

[Johnny]

I have a page with a button that has the following link:

<a href="/somelink?org.apache.struts.taglib.html.TOKEN=ef9f9f5973be37ffe39c60227f402770#"
onclick="javascript:go( event, 'myForm');return false;">

The go() function submits a form and returns false. This is definately
working.

The problem is that on some peoples' computers ( only a rare few, that
have different OS's and browsers ) this link follows the HREF and goes
to "/somelink?..." instead of proceeding to the action inside of the
form.

I've identified that a fix to this problem is to replace to
'href="/somelink?..."' with 'href=#', though I don't know why this is
only a problem on some computers.

Has anyone else seen this in the past? I'm thinking there might be an
issue with popup-blockers... or some other third-party software.

Any information would be appreciated, thanks.

 

[Richard Cornford]

onclick="javascript:go( event, 'myForm');return false;">

The go() function submits a form and returns false. This is
definately working.

The - go - function is a one of yours?

The problem is that on some peoples' computers ( only a rare
few, that have different OS's and browsers ) this link follows
the HREF and goes to "/somelink?..." instead of proceeding to
the action inside of the form.

<snip>

If an error occurs within the - go - function then JavaScript execution
will terminate and the event handling function will not return a value.
So the navigation within the HREF will be followed (that will also be
the case when JavaScript is not available on the client).

Obviously without seeing the code within the - go - function, or the
HTML it is interacting with, speculating as to whether, or how, it might
be erroring would be futile.

Richard.

 

[kaeli]

I have a page with a button that has the following link:

<a href="/somelink?org.apache.struts.taglib.html.TOKEN=ef9f9f5973be37ffe39c60227f402770#"
onclick="javascript:go( event, 'myForm');return false;">

Don't put "javascript:" in an event handler. An event handler is already
script.

The go() function submits a form and returns false. This is definately
working.

Is it working in the problem browsers/OSs?
See Richard's post. If it's broken in some situations and "go" is
undefined (which is what happens in some browsers when a function has an
error), the browser may ignore the function.

If taking out the href were an option, why is it there?
Most of us put it there to support old browsers or browsers with no
script. If you don't need it (intranet, cd, etc), don't use it.

--

 

[Johnny]

Don't put "javascript:" in an event handler. An event handler is already
script.


Is it working in the problem browsers/OSs?
See Richard's post. If it's broken in some situations and "go" is
undefined (which is what happens in some browsers when a function has an
error), the browser may ignore the function.

If taking out the href were an option, why is it there?
Most of us put it there to support old browsers or browsers with no
script. If you don't need it (intranet, cd, etc), don't use it.

--

Thank you both for your posts.

The reason I didn't provide the source to the go() function is that it
is not even getting executed. When the user click's the image this
anchor tag wraps, the go() function is not even being executed, the
browser follows the HREF immediately.

Kaeli, to answer your first question, yes, everything works on the
problem browser/OS after replacing the HREF with '#'. But, the
interesting part is that without replacing the HREF, everything works
on the same OS/browser on other machines. For some reason, this
machine is different, and that's what I'm trying to nail down... what
could be different? I was hoping that it would be a popup blocker, but
I was unable to find one.

To answer your second question, there is no logical reason for the
HREF to be there. I'm just troubleshooting the issue, but after
speaking with the developers, it seems that the HREF really has no
value. So, it will be removed either way.

 

[kaeli]

Kaeli, to answer your first question, yes, everything works on the
problem browser/OS after replacing the HREF with '#'. But, the
interesting part is that without replacing the HREF, everything works
on the same OS/browser on other machines. For some reason, this
machine is different, and that's what I'm trying to nail down... what
could be different? I was hoping that it would be a popup blocker, but
I was unable to find one.

I wouldn't think so, as most popup blockers I know of only block popups
that were NOT the direct result of a user action (IE). That is, if a
function from onClick opens a window, it's cool. If a function calls
another function that opens a window, it's blocked.
This is IME from using the blockers, so I could be totally off base
here.

I wonder if the browser settings are the same...


--
--
~kaeli~
Jesus saves, Allah protects, and Cthulhu thinks you'd make
a nice sandwich.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace