vbgunz said:
I tested the following script in Konqueror 3, Safari 3, Firefox 2 and
Opera 9. All browsers work as expected and all browsers are exactly
the same in there results. I have 3 peculiar problems I hope I
commented well on the following pastebin.
http://dpaste.com/hold/26276/
I did not include the HTML but did include the snippet in which this
script deals with (at the tail end of the paste). I am still very new
in learning JavaScript so there might be something I am missing
entirely. I appreciate any help on these issues regarding IE6.
Thank you for supplying long scripts separately via a URL, but next time
please include the questions themselves in your post so they are easier
to quote. For people who haven't visited the URL, they are these:
| problem 1 is: IE6 gets the source order execution wrong. all browsers
| start from the top and work their way down. IE does not. why?
If I understand the question correctly, you're wondering why IE doesn't
call the event handlers added in these lines:
addEvent(link, 'click', alertTarget);
addEvent(link, 'click', alertType);
in the order they appear in the script. The page at
http://msdn2.microsoft.com/en-us/library/ms536343.aspx says:
| If you attach multiple functions to the same event on the same object,
| the functions are called in random order, immediately after the
| object's event handler is called.
So IE is executing them in random order, as the documentation said it
would. Nothing "wrong" about it.
[Given this HTML snippet...]
<p id="intro-paragraph">bubble and get some info!
<a href="
http://google.com" id="googleit">Google it!</a>
</p>
| problem 2 is: when clicking on the "link", all browsers bubble up
| correctly. First link.alertTarget then p.alertTarget (check the HTML
| below). IE6 fires the link.alertTarget *but* not p.alertTarget. why?
That's because window.event.srcElement gives you the name of the element
that was clicked, not the name of the element whose event handler is
intercepting the click. The event bubbles properly but the handlers both
report the originating element. If you were to use event.target instead
of event.currentTarget in Firefox, you'd see the same thing.
| problem 3 is: weird. IE6 doesn't bubble *but* link.alertTarget is now
| called twice. first type is called then alertTarget (2 times). IE6
| not only does it in reverse *but* also repeats itself. why?
I don't know what you mean "doesn't bubble" because you haven't
prevented it bubbling. The code
function cancel(e) {
e.preventDefault ?
e.preventDefault() : // FF2, K3, S3, O9
e.returnValue = false; // IE6
}
will prevent the A element executing its default action when clicked,
but it won't prevent other event handlers being called. By happy
coincidence the solution to this problem introduces a more conventional
way to write this type of conditional statement
function cancel(e) {
if (e.preventDefault) {
e.preventDefault();
} else if (typeof e.returnValue != "undefined") {
e.returnValue = false;
}
if (e.stopPropagation) {
e.stopPropagation();
} else if (typeof e.cancelBubble != "undefined") {
e.cancelBubble = true;
}
}
One interesting gotcha I noticed when testing this is that if
preventDefault(), stopPropagation() and cancelBubble = true are all
executed in Firefox 2.0.0.10, then preventDefault() is ignored. That was
annoying.
A couple of last things. The comments in your code indicate you think
some browser versions are executing a few things they in fact aren't.
You might find the FAQ notes on feature detection useful. Also you might
like to ensure your code passes a true or false in the final parameter
of addEventListener(). I guess the browser type-converts your undefined
'flag' variable to false, but it's better to make your own decision.
Hope that helps.
