handling of # in href of an anchor that has an onclick question

[Logos]

There seems to be a serious difference between how FF an IE handle an
anchor with an href containing a # and an onclick event.

If the onclick event returns false, IE does not change
window.location.href to include the #. FF does.

(eg) <a href="#moo" onclick="alert('moo'); return false;">
After clicking in IE, location bar in browser shows
"www.moo.cow/index.htm".
After clicking in FF, location bar in browser shows
"www.moo.cow/index.htm#moo".

Can anyone tell me why this should be so? It screws up some otherwise
nifty things for me...

Tyler

 

[James Black]

(eg) <a href="#moo" onclick="alert('moo'); return false;">
After clicking in IE, location bar in browser shows
"www.moo.cow/index.htm".
After clicking in FF, location bar in browser shows
"www.moo.cow/index.htm#moo".

When they first click the link, get the value from document.location.
Then, store that in a variable, and call setTimeout, and have another
function just copy that location back to document.location.

The only thing I don't know is whether that would lead to a reloading
of the page, but, I think this may work.

 

[Matt Kruse]

There seems to be a serious difference between how FF an IE handle an
anchor with an href containing a # and an onclick event.

That is an incorrect assumption.

If the onclick event returns false, IE does not change
window.location.href to include the #. FF does.

That is an incorrect conclusion.

(eg) <a href="#moo" onclick="alert('moo'); return false;">
After clicking in IE, location bar in browser shows
"www.moo.cow/index.htm".
After clicking in FF, location bar in browser shows
"www.moo.cow/index.htm#moo".
Can anyone tell me why this should be so?

Because your example doesn't match exactly with what you are doing.
If you put the above in an actual file and did the test, it would work as
expected.

For example,

<a href="#moo" onclick="alert('moo'); return false;">temp</a>
<br><br>
<span onclick="alert(window.location.href)">Click to alert location</span>

Clicking the link then the span alerts the correct url (without #moo) and
the location bar doesn't show #moo either.

I suspect that your actual test case calls a function, and that function
causes an error in firefox, which then causes the return false to never be
called, which makes the #moo href be followed.

Always post example code that actually illustrates the problem.
http://www.javascripttoolbox.com/clj/#getanswers

 

[Logos]

Since you didn't post the ACTUAL code you are using, I would have to

assume that the problem is in your code. It certainly doesn't exist in
the tiny snippet that you provided.

The actual code is fairly large. You can see it in action at
http://65.110.86.247/Product_List3.asp.

The orignial code was:


try { //IE will not allow name attribute to be set after element
creation
link =document.createElement("<a id='itemNo|" +intPartId +"'
name='itemNo|" +intPartId +"' href='#itemNo|" +intPartId +"' />");
} catch (e) {
link =document.createElement("a");
link.setAttribute("id","itemNo|" +intPartId);
link.setAttribute("name","itemNo|" +intPartId);
link.setAttribute("href","#itemNo|" +intPartId);
}
if(link.attachEvent) { eval("link.attachEvent('onclick',function() {
GB_show('" +part.strDesc +"', '" +INFO_URL_BASE+part.infoUrl +"', 470,
600); return false; },false)"); }
else { eval("link.addEventListener('click',function() { GB_show('"
+part.strDesc +"', '" +INFO_URL_BASE+intPartId+".jpg" +"', 470, 600);
return false; },false)"); }


Substituting an alert instead of GB_show yielded the same problem.

Interestingly, if I use link.onclick instead of link.addEventListener,
the problem disappears:

else { eval("link.onclick =function() { GB_show('" +part.strDesc
+"', '" +INFO_URL_BASE+intPartId+".jpg" +"', 470, 600); return false;
}"); }

I wonder why? The link above uses the working onlick version, not the
addEventListener, if anyone cares to peek at it.

Tyler

 

[Matt Kruse]

if(link.attachEvent) { eval("link.attachEvent('onclick',function() {
GB_show('" +part.strDesc +"', '" +INFO_URL_BASE+part.infoUrl +"', 470,
600); return false; },false)"); }

Why are you using eval?
http://www.javascripttoolbox.com/bestpractices/#eval

 

[Jeremy]

Can anyone tell me why this should be so? It screws up some otherwise
nifty things for me...

Tyler

Replying again, in this thread instead of the other. The other has
turned into an off-topic flamewar.

So you're not allowed to use javascript: pseudo-URLs? Hrm...

If the link will ALWAYS cancel out, why must you use a link in the first
place? Why not a <span> that's styled to look like a link? The URL in
the status bar would never be useful anyway, if it's only "#".

 

[Logos]

Why are you using eval?
http://www.javascripttoolbox.com/bestpractices/#eval

I agree that eval is evil... A workaround just occured to
me...testing...

Yup, that worked; I put the URL in the anchor as a custom property
(link.infoUrl ="http://babble.com/blather"), and changed the onclick
assignment to link.onclick=function() {GB_show("Product
Information",this.infoUrl,470,600); return false; };

Thanks for reminding me to fix that! I was concentrating more on just
getting the bloody click to work as I wanted it to...

Tyler

 

[Logos]

Replying again, in this thread instead of the other. The other has

turned into an off-topic flamewar.

Yes. Blooie! Thanks for coming to the new thread.

So you're not allowed to use javascript: pseudo-URLs? Hrm...

If the link will ALWAYS cancel out, why must you use a link in the first
place? Why not a <span> that's styled to look like a link? The URL in
the status bar would never be useful anyway, if it's only "#".

For the same reason I can't use pseudo-URLs. A large portion of our
user base is seniors, and many of them won't click on a link unless
their status bar shows it to be a related or expected URL. You know,
it's one of those 'internet anti-phishing tactics for dummies' things.
We had to do a pain in the butt change to our online shopping cart on
another site because people didn't think it went over a secure
connection; the https submission was done via a javascript function
initiated by a button, rather than via a link they could hover over and
see an HTTPS URL in the status bar. We also wound up putting the whole
page out over HTTPS, just so people could see a little lock symbol on
the shopping cart page & feel all safe and warm and secure (never mind
that it tripled the time to load because of the time it took to
encrypt/decrypt all the JS that went along with the page!).

FYI, the # in the link actually shows up as the page URL in the status
bar, not as an #. In IE and FF it does, anyway.

Tyler

 

[Logos]

If there is an error in the code before the return false in the event
handler, Mozilla will still perform the default action. Your example
code didn't demonstrate that, since an alert wouldn't cause an error,
but that's why Mozilla and IE seem to be acting differently.

My original code didn't demonstrate the error; it just shows the
effective JS rather than what actually goes on. Another post of mine
shows that the problem lies in attachEventListener in FF, actually. If
I use link.onclick =function () {...} it works exactly like I expect it
to, without any changes to the code in the function.

I've never tried it, but I wonder if this would work when there is an error:

<a href="#moo" onclick="try{doSomething('moo');}catch(e){}return false;">

It's probably not all that useful though, even if it works.

That's a good suggestion, though - hadn't thought of that. But it's
definitely not a good practice, I should think! The code shouldn't be
erroring out at ALL, and doesn't if you attach it in a different way.
Something funky is going on there with FF. Idea - I will test out the
original in Opera and see what happens with that tomorrow. That will
tell me if it's an FF idiosyncracy or not; I *think* it supports
attachEventListener....

Tyler

 

[Randy Webb]

Logos said the following on 6/22/2006 11:20 PM:

That's a good suggestion, though - hadn't thought of that.

Another possibility is:

onclick="return doSomething()"

And have doSomething return true/false. If it fails or errors out, then
nothing gets returned and the default action occurs.

But in this case, it might be better to have it follow the default
action just so you know that something is wrong if something does go wrong.