193014 - getAttribute returns null instead of empty string

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[gavin long]

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

[Bill Mason]

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

[Boris Zbarsky [:bzbarsky]]

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

Comment 3

[gavin long]

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

[Boris Zbarsky [:bzbarsky]]

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

[Boris Zbarsky [:bzbarsky]]

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

[Boris Zbarsky [:bzbarsky]]

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

[Boris Zbarsky [:bzbarsky]]

Attachment: testcase

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

Comment 8

[Chris Casciano]

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

[Boris Zbarsky [:bzbarsky]]

So... how do IE and Opera handle the style switcher on that page?

Comment 10

[Chris Casciano]

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

[Boris Zbarsky [:bzbarsky]]

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

[Chris Casciano]

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

[Boris Zbarsky [:bzbarsky]]

Attachment: another testcase

Aaaaargh.  ;)

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

Comment 14

[Chris Casciano]

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

[Boris Zbarsky [:bzbarsky]]

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

Comment 16

[Jeffrey Zeldman]

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

[Jeffrey Zeldman]

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.

Comment 18

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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

[Boris Zbarsky [:bzbarsky]]

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.

Comment 20

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 21

[Boris Zbarsky [:bzbarsky]]

*** Bug 201972 has been marked as a duplicate of this bug. ***