getAttribute fails to identify a missing attribute

RESOLVED FIXED in mozilla0.9.6



DOM: Core & HTML
18 years ago
17 years ago


(Reporter: rsalesas, Assigned: jst)


(4 keywords)

arch, dom0, helpwanted, relnote

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [lm] relnote-devel)



18 years ago
The following code shows problems handling attributes. The results should be 
null, empty, empty, value: 1. Instead they are empty, emtpy, empty, value: 1. 
There is currently no way to tell the difference between a missing attribute 
(null) and one with no value.

Build: Netscape Preview (2000033112)


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">



	function testAttributes(attribute) {
		var all = document.getElementsByTagName('span');
		// Create a new array and add all matching objects
		var elements = new Array();
		for (var e = 0; e < all.length; e++) {
			var attr = all[e].getAttribute(attribute);
			if (typeof(attr) == "undefined")
			else if (attr == null)
			else if (attr == "")
				alert("Value: " + attr);


<input type="button" onclick="testAttributes('attr1')">

<span attr1></span>
<span attr1=""></span>
<span attr1="1"></span>


Comment 1

18 years ago
*** Bug 38381 has been marked as a duplicate of this bug. ***

Comment 2

18 years ago
confirming. happens for me with 2000060708 nightly build
Severity: normal → major
OS: Windows 2000 → All
Hardware: PC → All

Comment 3

18 years ago
doh. forgot to confirm. sorry
Ever confirmed: true

Comment 4

18 years ago
This bug has been marked "future" because the original netscape engineer
working on this is over-burdened. If you feel this is an error, that you or
another known resource will be working on this bug,or if it blocks your work
in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: --- → Future

Comment 5

18 years ago
Yeah, I think it's "in error". How can we identify if an attribute is missing 
in a compatible manner, or in any other way for that matter?

Comment 6

18 years ago
DOM Level 2 defines the node methods hasAttribute() and hasAttributeNS() that
will work in nsbeta2 (not sure if they work right now). Hopefully this would be
resolved before the release but it's a *lot* of work, so we'll haveto wait and

Comment 7

18 years ago
er, make that element methods, not node methods.

Comment 8

18 years ago
Not to beat this horse, but... there's a ton of application code that breaks 
with this. It really breaks, you get completely the wrong behaviour. The amount 
of code to work around this, in every application, is not trivial. I mean, 
getting attributes and having them return their existance or not, that's pretty 
much expected.

Comment 9

18 years ago
nominating nsbeta3 coz I feel getting attributes and having them return their 
existance is something atleast expected.
Keywords: nsbeta3

Comment 10

18 years ago
I agree, and now we're actually getting close to being able to fix this easily,
our string classes will soon be taught about the difference between an empty
string and a null string.
Keywords: correctness
Target Milestone: Future → M18


18 years ago
Priority: P3 → P2
nsbeta3-. Not a stop-ship. There *is* a workaround--explicit testing as noted in 
the description, and someone could write a utility function in JavaScript that 
does the workaround test and returns the right value.

Once we get through all jst's nsbeta3+ bugs, I'd consider accepting this as a 
last-minute exception fix, but for now, nsbeta3-.
Keywords: relnote
Whiteboard: [lm][nsbeta3-]
Whiteboard: [lm][nsbeta3-] → [lm][nsbeta3-] relnote-devel

Comment 12

18 years ago
Actually, mozilla is doing the right thing here even if it doesn't seem so (and
I didn't think it did untill reasantly), but the DOM spec (both level 1 and
level 2, look for the definition of getAttribute at
does state that the returned value is either the value of the attribute or an
empty string if the attribute doesn't exist.

If this is relnoted it should be relnoted as an incompatibility with IE, not as
an incompatibility with the DOM spec.

I'm leaving this bug open since I wouldn't be surpriced if this will get dupes
over time, and we might even consider "fixing" this since what IE does is more
useful than what mozilla currently does (and what the DOM spec specifies).

Comment 13

18 years ago
Mozilla does the right thing here but I don't wanna close this bug (see my last
comment) so I'm pushing this to Future for now...
Target Milestone: M18 → Future
Keywords: dom0


17 years ago
Keywords: nsbeta3 → arch, helpwanted
Whiteboard: [lm][nsbeta3-] relnote-devel → [lm] relnote-devel
Nom. nsbeta1. Suggest that we fix for xbrowser compatibility since jst feels 
that IE's behavior is the Right Thing from the developer's standpoint, and 
request a change to the spec for the next DOM errata.
Keywords: nsbeta1
Johnny, putting for 0.9.1 for re-evaluation.
Keywords: nsbeta1 → nsbeta1+
Target Milestone: Future → mozilla0.9.1

Comment 16

17 years ago
Moving to mozilla0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 17

17 years ago
Moving to mozilla0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Target Milestone: mozilla0.9.3 → mozilla0.9.4

Comment 18

17 years ago
Pushing to mozilla0.9.5
Target Milestone: mozilla0.9.4 → mozilla0.9.5


17 years ago
Target Milestone: mozilla0.9.5 → mozilla0.9.6

Comment 19

17 years ago
I believe this was fixed by the null string landing not long ago. Wooooo?

Comment 20

17 years ago
Yup, this one was fixed.
Last Resolved: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.