Last Comment Bug 554016 - setAttributeNS("unknown", "align") after setAttributeNS(null, "align") changes return value of getAttribute("align")
: setAttributeNS("unknown", "align") after setAttributeNS(null, "align") change...
Status: NEW
: testcase
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
: -- normal with 5 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://samples.msdn.microsoft.com/iet...
Depends on:
Blocks: ietestcenter
  Show dependency treegraph
 
Reported: 2010-03-22 06:09 PDT by :Gavin Sharp [email: gavin@gavinsharp.com]
Modified: 2011-12-01 01:15 PST (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description :Gavin Sharp [email: gavin@gavinsharp.com] 2010-03-22 06:09:05 PDT
I don't know what the justification is for this test's expected results ("DOM L2 Core" is all that's listed), but apparently we're the only browser that fails it:

http://samples.msdn.microsoft.com/ietestcenter/#domcore
Comment 1 :Ms2ger 2010-03-22 06:22:04 PDT
This only happens for "mapped attributes". DOM 2 Core doesn't actually define the correct behavior here.
Comment 2 Alex Vincent [:WeirdAl] 2010-03-22 08:21:00 PDT
The second attribute of setAttributeNS (or createElementNS, for that matter) is a qualified name - prefix plus local name.

DOM 3 Core backs us up on this.
http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#ID-ElSetAttrNS
Comment 3 Alex Vincent [:WeirdAl] 2010-03-22 08:26:17 PDT
Oh, I see... it's because they're using getAttribute() (DOM Level 1) with setAttributeNS() (DOM Level 2).  The getAttribute() method isn't particularly well suited to work with setAttributeNS, because the latter uses namespaces, and the former doesn't.

"Calling Element.getAttribute(name)  with that nodeName could then return any of those attributes. The result depends on the implementation."
http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#Namespaces-Considerations
Comment 4 Boris Zbarsky [:bz] 2010-03-22 11:35:23 PDT
Yeah, this test is bogus, imo.  At least pending some sort of errata to the DOM specs defining the behavior.
Comment 5 d 2010-03-23 01:03:25 PDT
So, if the conclusion is that the test is invalid, we should ask Microsoft to remove it, right?
Comment 6 Olli Pettay [:smaug] 2010-03-23 02:34:29 PDT
I sent an email to my MS contact.
Comment 7 Boris Zbarsky [:bz] 2010-03-23 22:54:39 PDT
What this test is _actually_ testing is that a certain ordering is imposed on attributes with the same localname but different namespace URIs (at least in terms of the lookup order for getAttribute).  The DOM does not guarantee such an ordering.  So yes, we should ask Microsoft to remove the test.
Comment 8 Olli Pettay [:smaug] 2010-03-24 02:52:17 PDT
I did send this information to Travis, and he promised to forward it to whoever
maintains that page.
Comment 9 d 2010-03-26 07:36:49 PDT
It's still there... but of course that is expected. Every second of showing a faulty score to our disadvantage makes IE9 seem better.
Comment 10 Olli Pettay [:smaug] 2010-03-26 08:22:59 PDT
That is unfortunate indeed, but what can we do if MS decides to put invalid
testcase to their web page, and not react too fast to comments to fix the pages.
Comment 11 Anne (:annevk) 2011-12-01 01:15:51 PST
The current DOM specification does impose some kind of ordering for what it's worth. setAttribute/setAttributeNS calls append attributes to an ordered list.

Note You need to log in before you can comment on or make changes to this bug.