e4x: XML with namespaces doesn't allow to have two attributes with the same local name and the same namespace but Spidermonkey parses that without throwing an error

VERIFIED FIXED

Status

()

Core
JavaScript Engine
VERIFIED FIXED
13 years ago
12 years ago

People

(Reporter: Martin Honnen, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
XML doesn't allow two attributes with the same name on one element, e.g.
  <god name="Kibo" name="Xibo" />
is not well-formed.
XML with namespaces restricts that further, it doesn't allow two attributes with
the same local name and the prefix bound to the same namespace URI, e.g.
  <god xmlns:pf1="http://example.com/2005/02/pf1"
xmlns:pf2="http://example.com/2005/02/pf1" pf1:name="Kibo" pf2:name="Xibo" />
is not well-formed.
Rhino catches that when parsing an XML literal, error message is:

line 1: uncaught JavaScript runtime exception: TypeError: error: Attribute
"name" bound to namespace "http://example.com/2005/02/pf1" was already specified
for element "god".

but Spidermonkey currently parses that stuff without throwing an error. As E4X
has namespace support I think it is better if E4X implements that restriction on
attribute names imposed by the XML with namespaces specification and throws an
error that the markup is not well-formed.

Test case:

var xml = <god xmlns:pf1="http://example.com/2005/02/pf1"
xmlns:pf2="http://example.com/2005/02/pf1" pf1:name="Kibo" pf2:name="Xibo" />;

if (typeof alert != 'undefined') {
  alert(xml.toXMLString());
}
else if (typeof print != 'undefined') {
  print(xml.toXMLString());
}

should throw a not well-formed error but doesn't.
(Reporter)

Comment 1

13 years ago
Created attachment 175741 [details]
test case (throws exception in Rhino but doesn't in Spidermonkey)
Martin's testcase checked in as js/tests/e4x/Namespace/regress-283972.js
Is this a duplicate of bug 277664? In any case, it looks like that bug's checkin
fixed this as well. Marking as such.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Flags: testcase+
verified fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.