1.3b, WinXP. The URL describes it quite well, but I've got a little more to add: Steps to reproduce: 1. clear your cache (important!) 2. visit the URL. 3. Below the main nav menu on the left are four small rectangles (white, orange, and a couple more) 4. click the little orange rectangle. Expected behaviour: page changes to orange. You remain at the same page. Actual behaviour: page changes to orange, AND browser follows link. behind those little boxes are links like this: <a href="/about/switch/" onclick="setActiveStyleSheet('default'); return false;" ... > Essentially, the "return false" in the event handler is NOT preventing the link being followed. If you do this repeatedly, the problem only shows up the first time. If you clear your cache, then it happens again the first time you try it, but not on subsequent attempts. Despite some effort, I can't produce a standalone testcase for this. I suspect this may be due to the involvement of the cache and the fact that (IIRC) mozilla doesn't cache file:// URLs. This sounds very similar to bug 121052, which was closed a year ago due to lack of a testcase. Hopefully Zeldman will restrain himself from redesigning again before we manage to either pin this down or cook up a decent testcase... ->event handling, as a first guess.
wfm in 2003021008 1.3b PC/WINXP Zeldman's page now notes that dozens of people are reporting WFM to him on this issue.
I see the problem with linux trunk build 2003-02-12-08. Definitely very intermittent. We are _not_ getting an exception thrown in the handler that I can tell (though there are random exceptions being thrown on that page with no rhyme or reason I can discern for the 'getAttribute("rel") has no properties' thing, which happens for the last <link> on the page, presumably; that seems wrong, since getAttribute should always return something.....)
I'm guessing that many of the WFM's are from people who didn't clear their cache. As I noted above, I only see this if I clear the cache right before I test it. After I've tested it once, it then works fine until I clear the cache again. Searching bugzilla for "return false" reveals several instances of similar-sounding problems, mostly closed as WFM, going all the way back to bug 2219. None of them mention the cache.
OK. I've now carefully gone through this a few times... Indeed, clearing the cache is instrumental -- without it things don't break. With cache cleared, the exception _is_ thrown that getAttribute("rel") didn't return anything useful. Then we naturally follow the link. So the bug is that getAttribute("rel") does the wrong thing, perhaps.. still looking.
More and more curious. If you look at document.getElementsByTagName("link").length, it's sometimes 3 and sometimes 7. When it's 3, everything works fine. When it's 7, things break. I'm starting to get some suspicions....
This is a duplicate of bug 108480, basically. There is no "rel" attribute, so we return "null" (compat with IE). Then the site tries to call .indexOf() on "null", which throws an exception. An exception in the onclick handler means the return is never executed and the default action is taken. There is a separate bug here, which is that we don't always see all the <link>s. That's why it sometimes works. I know why that's happening; it's been on my far-off radar for a few weeks now... I'm somewhat suprised someone managed to actually trigger this condition. ;) I've filed bug 193069 on that problem. Once I fix that, this site's sheet switcher will _never_ work. So does this site work in IE? If so, why? Does IE not return null from getAttribute? Does IE not follow the link if the onclick handler throws an exception?
The following are the results of my hitting the testcase in various browsers: OS X Opera 6 :: True :: follows link Safari 0.60b :: False :: follows link IE 5.2.2 :: True :: follows link OmniWeb 4.2b1 :: follows link :: follows link Win2k Opera 7.01 :: True :: follows link IE 6 :: True :: follows link
So... how do IE and Opera handle the style switcher on that page?
Similarly... with the exception of Opera6/Mac results of testing http://www.zeldman.com/daily/0203b.shtml#feb1203 OS X Opera 6 :: follows link to http://www.zeldman.com/about/switch/ Safari 0.60b :: Switcher Works IE 5.2.2 :: Switcher Works OmniWeb 4.2b1 :: follows link Win2k Opera 7.01 :: Switcher Works IE 6 :: Switcher Works
Created attachment 114297 [details] another testcase Aaaaargh. ;) Well, I think we may be on to something... What are your results on this one?
Results for 2nd test case, posted in comment 13... Dropping OW cause there's really no point... Adding moz 1.3b for historical completeness OS X Mozilla 1.3b true true true true Opera 6 true true true true Safari 0.60b false false false false IE 5.2.2 true true false false Win2k Mozilla 1.3b true true true true Opera 7.01 false false false false IE 6sp1 true true false false ( hey Boris... Don't you have any browsers on your computer? :P )
Chris, I don't have IE in any form, which is the one browser in those tests I really cared about. ;) Too bad IE's behavior is FUCKED (note that it's the only browser that's not consistent on that last testcase) jst, this is all yours. Looks like IE's behavior, on both Mac and Win is that getAttribute returns "null" only if the attribute is not a "known" one for the element. Otherwise it returns the empty string.... ccing sicking too, since I bet he'd love to try to emulate this fucked-up behavior in Mozilla's attribute architecture...
Problem solved by adjustment to script. Moz was getting confused by non-css links in document <head> such as <link rel="help" href="http://www.zeldman.com/about/" title="Site info." /> Paul Sowden, creator of the original style switching script, solved problem by tweaking script values. See http://www.zeldman.com/j/nu.js. Jeffrey from zeldman.com
Feh. Typing faster than thinking. The link elements that created the problem were those that contained rev instead of rel, such as ... <link rev="alistapart" href="http://www.alistapart.com/" title="From pixels to prose, coding to content: A List Apart Magazine, for people who make websites." /> The original ALA style switching script by Paul Sowden is widely used, but links of this type are rarely used, so the problem won't be seen on all that many sites.
I think IE actually has that attribute set to an empty string. Getting document.body.attributes.length returns *98*!! So i think it's getting all sorts of defaults for all supported attributes, which gets quite a lot since IE seems to consider .foo and .getAttribute("foo") to be the same thing. All in all i think we should just mark this attribute as INVALID and ignore IE.
sicking, right now we are violating the DOM spec to be "compatible" with IE. We're not compatible with it when people are getting a "known" (to IE) attribute. We're compatible if they are getting an "unknown" (to IE) attribute. I'm ok with marking this INVALID as long as we realize the situation -- we are not _ignoring_ IE if we do so.
actually, we are never compatible when getting an non-set attribute, doesn't matter if it's "known" or "unknown". The spec says that the empty string should be returned, but we return null. However we are pretty much forced to do this due to compatibility reasons. And it is actually more usefull to return null since often clients want to differentitate between a set-empty attribute and a non-set attribute. Anyway, we'll have to live with this so i'm invalidating this bug.
*** Bug 201972 has been marked as a duplicate of this bug. ***