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.ap ache.struts.tag lib.html.TOKEN= ef9f9f5973be37f fe39c60227f4027 70#"
onclick="javasc ript:go( event, 'myForm');retur n 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]

Re: Anchor element follows HREF even though onClick returns false

"Johnny" <jazzman_333@ya hoo.com> wrote in message
news:64c780aa.0 401151456.3b86e 827@posting.goo gle.com...
<snip>[color=blue]
>onclick="javas cript:go( event, 'myForm');retur n false;">
>
>The go() function submits a form and returns false. This is
>definately working.[/color]

The - go - function is a one of yours?
[color=blue]
>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.[/color]
<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]

Re: Anchor element follows HREF even though onClick returns false

In article <64c780aa.04011 51456.3b86e827@ posting.google. com>, jazzman_
333@yahoo.com enlightened us with...[color=blue]
> I have a page with a button that has the following link:
>
> <a href="/somelink?org.ap ache.struts.tag lib.html.TOKEN= ef9f9f5973be37f fe39c60227f4027 70#"
> onclick="javasc ript:go( event, 'myForm');retur n false;">
>[/color]

Don't put "javascript :" in an event handler. An event handler is already
script.
[color=blue]
> The go() function submits a form and returns false. This is definately
> working.
>[/color]

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.

--
--
~kaeli~
Support your local medical examiner: die strangely!

http://www.ipwebdesign.net/wildAtHeart

http://www.ipwebdesign.net/kaelisSpace

[Johnny]

Re: Anchor element follows HREF even though onClick returns false

kaeli <tiny_one@NOSPA M.comcast.net> wrote in message news:<MPG.1a71a f7c5ee6b911989b 0e@nntp.lucent. com>...[color=blue]
> In article <64c780aa.04011 51456.3b86e827@ posting.google. com>, jazzman_
> 333@yahoo.com enlightened us with...[color=green]
> > I have a page with a button that has the following link:
> >
> > <a href="/somelink?org.ap ache.struts.tag lib.html.TOKEN= ef9f9f5973be37f fe39c60227f4027 70#"
> > onclick="javasc ript:go( event, 'myForm');retur n false;">
> >[/color]
>
> Don't put "javascript :" in an event handler. An event handler is already
> script.
>[color=green]
> > The go() function submits a form and returns false. This is definately
> > working.
> >[/color]
>
> 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.
>
> --[/color]

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]

Re: Anchor element follows HREF even though onClick returns false

In article <64c780aa.04011 71153.24e2b1a7@ posting.google. com>, jazzman_
333@yahoo.com enlightened us with...[color=blue]
>
> 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.
>[/color]

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