Closed
Bug 193014
Opened 22 years ago
Closed 22 years ago
getAttribute returns null instead of empty string
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
INVALID
People
(Reporter: gav, Assigned: jst)
References
()
Details
(Whiteboard: Not a dup of bug 108480; see comment 15)
Attachments
(2 files)
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.
Comment 1•22 years ago
|
||
wfm in 2003021008 1.3b PC/WINXP Zeldman's page now notes that dozens of people are reporting WFM to him on this issue.
Comment 2•22 years ago
|
||
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.....)
Reporter | ||
Comment 3•22 years ago
|
||
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.
Comment 4•22 years ago
|
||
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.
Comment 5•22 years ago
|
||
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....
Comment 6•22 years ago
|
||
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?
Comment 7•22 years ago
|
||
I'd like to hear how IE behaves on that testcase....
Comment 8•22 years ago
|
||
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
Comment 9•22 years ago
|
||
So... how do IE and Opera handle the style switcher on that page?
Comment 10•22 years ago
|
||
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
Comment 11•22 years ago
|
||
Hmm.. see, that's what confuses me. If a browser returns 'null' for getAttribute("not-there") and the browser follows links when exceptions happen in the handler then the browser should follow the link to http://www.zeldman.com/about/switch/ on that page. So every single browser listed in comment 8 except for Safari should be following the link. According to comment 10 only Opera 6 on Mac does so.... Chris, what do you get if you go to http://www.zeldman.com/daily/0203b.shtml in those browsers and type the following in the URL bar: javascript:alert(document.getElementsByTagName("link").length) javascript:alert(document.getElementsByTagName("link")[5].getAttribute("rel")) javascript:alert(document.getElementsByTagName("link")[5].getAttribute("rel")==null) ?
Comment 12•22 years ago
|
||
Test results for the tests in comment 11: OS X Opera 6.0 7 undefined true Safari 0.60b 7 blank dialog false IE 5.2.2 7 blank dialog false OmniWeb 4.2b1 No response... Nor for javascript:alert(alert("foo")) Win 2k Opera 7.01 7 "Warning" false IE 6sp1 7 blank dialog false (no one ever said browsers make sense)
Comment 13•22 years ago
|
||
Aaaaargh. ;) Well, I think we may be on to something... What are your results on this one?
Comment 14•22 years ago
|
||
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 )
Comment 15•22 years ago
|
||
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...
Assignee: saari → jst
Severity: normal → major
Component: Event Handling → DOM Core
Keywords: qawanted
Summary: Style switcher: <a> processes onclick and goes to href despite return false → getAttribute returns null instead of empty string
Whiteboard: Not a dup of bug 108480; see comment 15
Comment 16•22 years ago
|
||
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
Comment 17•22 years ago
|
||
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.
Comment 19•22 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
Comment 21•21 years ago
|
||
*** Bug 201972 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•