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 13 2508
Logos wrote: (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.
Logos wrote: 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
--
Matt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com
Logos wrote: There seems to be a serious difference between how FF an IE handle an anchor with an href containing a # and an onclick event.
There isn't a difference
If the onclick event returns false, IE does not change window.location.href to include the #. FF does.
No, this does not happen.
(eg) <a href="#moo" onclick="alert('moo'); return false;"> After clicking in IE, location bar in browser shows "www.moo.cow/index.htm".
Correct
After clicking in FF, location bar in browser shows "www.moo.cow/index.htm#moo".
Incorrect. I just tested it.
Can anyone tell me why this should be so?
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 most convoluted explanation that fits all the available and made-up
facts is the most likely to be believed by conspiracy theorists"
> 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
Logos wrote: 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 "#".
Matt Kruse wrote: Logos wrote: 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
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 wrote: 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
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.
So if you have:
<a href="#moo" onclick="doSomething('moo'); return false;">
and the doSomething function has an error, the script will stop
executing before you get to return false, and the default action on the
element will occur.
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.
Kevin N.
> 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 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
Logos said the following on 6/22/2006 11:20 PM:
<snip> 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.
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.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Temporarily at: http://members.aol.com/_ht_a/hikksnotathome/cljfaq/
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Logos wrote: 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.
All I can say is that you guys really haven't seen a flamewar, if you
thought that was one :)
--
"The most convoluted explanation that fits all the available and made-up
facts is the most likely to be believed by conspiracy theorists"
Logos wrote: 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.
If you are using element.addEventListener, and you want to cancel the
default action, you would use the Event.preventDefault() method:
element.addEventListener('click', function(e) {
e.preventDefault();
}, false);
If you have an error before e.preventDefault, it will still do the
default action though (you can put it at the top of the function though).
Kevin N. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Christian Radermacher |
last post by:
Hi,
the following code has the mentioned behaviour:
<html>
<head>
<script type="text/javascript">
function newA() {
for (i=0;i<3;i++) {
var a = window.frames.document.createElement("a");
|
by: Johnny |
last post by:
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...
|
by: Jerry Sievers |
last post by:
JS Programmers, "I'm a server-side coder PHP, Postgres etc...
My question; Given the following anchor
<a href="http://www.somesite.com/somefile.html">link text</a>
Is there a way to code an...
|
by: ningjun.wang |
last post by:
Hello:
My html file contains the following image link:
<a href="some_url"><img src="MyImage.gif"></a>
How can I use Javascript to find out the value of some_url for the
given image name...
|
by: usenet |
last post by:
See
<ul>
<li><a name="link1" onClick="alert(this.name);return false;"
href="#">Link1</a></li>
<li><a name="link2" href="javascript:alert(this);">Link2</a></li>
<li>Item 3</li>
</ul>
...
|
by: eswanson |
last post by:
In jscript, I would like to be able to set the href attribute of the anchor
element. I have a aspnet:hyperlink button on the page, but I would like to
be able to set the href attribute of this...
|
by: Edwin Knoppert |
last post by:
I have an asp.net imagebutton with a clickevent.
I have enclosed an anchor around the image and a small text.
If i click the image the event is executed (while the href of the anchor
shows in the...
|
by: Peter Laman |
last post by:
In my app I need to dynamically generate a series hyperlinks. Each
hyperlink's action must be to focus a field in a <form>. I created the
following function to create such a link (the argument is a...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| |