Closed Bug 37750 Opened 24 years ago Closed 23 years ago

getAttribute fails to identify a missing attribute

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla0.9.6

People

(Reporter: rsalesas, Assigned: jst)

Details

(4 keywords, Whiteboard: [lm] relnote-devel)

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

<html>
<head>
	<title>Untitled</title>
</head>

<script>

	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")
				alert("undefined");
			else if (attr == null)
				alert("null");
			else if (attr == "")
				alert("empty");
			else
				alert("Value: " + attr);
		}	
	}
	
</script>


<body>

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

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

</body>
</html>
*** Bug 38381 has been marked as a duplicate of this bug. ***
confirming. happens for me with 2000060708 nightly build
Severity: normal → major
OS: Windows 2000 → All
Hardware: PC → All
doh. forgot to confirm. sorry
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
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?
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
see.
er, make that element methods, not node methods.
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.
nominating nsbeta3 coz I feel getting attributes and having them return their 
existance is something atleast expected.
Keywords: nsbeta3
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
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
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
http://www.w3.org/TR/2000/WD-DOM-Level-1-20000929/level-one-core.html#ID-745549614)
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).
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
Keywords: nsbeta3arch, 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: nsbeta1nsbeta1+
Target Milestone: Future → mozilla0.9.1
Moving to mozilla0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Moving to mozilla0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Pushing to mozilla0.9.5
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Target Milestone: mozilla0.9.5 → mozilla0.9.6
I believe this was fixed by the null string landing not long ago. Wooooo?
Yup, this one was fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.