getAttribute returns null instead of empty string




DOM: Core & HTML
15 years ago
10 years ago


(Reporter: gavin long, Assigned: jst)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: Not a dup of bug 108480; see comment 15, URL)


(2 attachments)



15 years ago
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

15 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
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.....)
Keywords: qawanted
OS: Windows XP → All
Hardware: PC → All

Comment 3

15 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

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
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
Created attachment 114283 [details]

I'd like to hear how IE behaves on that testcase....

Comment 8

15 years ago
The following are the results of my hitting the testcase in various browsers:

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

Opera 7.01 :: True :: follows link
IE 6 :: True :: follows link
So... how do IE and Opera handle the style switcher on that page?

Comment 10

15 years ago
Similarly... with the exception of Opera6/Mac

results of testing

Opera 6 :: follows link to
Safari 0.60b :: Switcher Works
IE 5.2.2 :: Switcher Works
OmniWeb 4.2b1 :: follows link

Opera 7.01 :: Switcher Works
IE 6 :: Switcher Works
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 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 in
those browsers and type the following in the URL bar:



Comment 12

15 years ago
Test results for the tests in comment 11:

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)
Created attachment 114297 [details]
another testcase

Aaaaargh.  ;)

Well, I think we may be on to something... What are your results on this one?

Comment 14

15 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

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

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...
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

15 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="" title="Site info." />

Paul Sowden, creator of the original style switching script, solved problem by
tweaking script values. See

Jeffrey from

Comment 17

15 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" 
	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.
Last Resolved: 15 years ago
Resolution: --- → INVALID
*** Bug 201972 has been marked as a duplicate of this bug. ***


10 years ago
Component: DOM: Core → DOM: Core & HTML
QA Contact: desale → general
You need to log in before you can comment on or make changes to this bug.