See attached test case (which also demonstrates bug 5262).
Created attachment 5248 [details] test case
> (which also demonstrates bug 5262). Hmm, maybe not.
Weird: with 10.4.9 WebKit, this test fully passes. With r20675, neither null not empty namespace works. Revision 20997 (bug 5262) fixes the null case. Not sure what changed since December 2005 in shipping WebKit, but now this looks like a regression. Reassigning to webkit-unassigned for for more visibility.
<rdar://problem/5159417>
Created attachment 14239 [details] patch with change log and layout test
Sending LayoutTests/ChangeLog Adding LayoutTests/fast/dom/namespaces-1-expected.txt Adding LayoutTests/fast/dom/namespaces-1.html Sending WebCore/ChangeLog Sending WebCore/dom/Node.cpp Transmitting file data ..... Committed revision 21167.
Comment on attachment 14239 [details] patch with change log and layout test >- return new TagNodeList(this, AtomicString(namespaceURI), AtomicString(name)); >+ return new TagNodeList(this, namespaceURI.isEmpty() ? nullAtom : AtomicString(namespaceURI), name); Is there a reason why the "name" parameter isn't "AtomicString(name)" anymore?
(In reply to comment #7) > (From update of attachment 14239 [details] [edit]) > >- return new TagNodeList(this, AtomicString(namespaceURI), AtomicString(name)); > >+ return new TagNodeList(this, namespaceURI.isEmpty() ? nullAtom : AtomicString(namespaceURI), name); > > Is there a reason why the "name" parameter isn't "AtomicString(name)" anymore? C++ will convert a String parameter automatically to an AtomicString; the explicit conversion syntax is not necessary. The reason I still need it in the other case is that the two side of a ?: expression have to have the same type.
Mass moving XML DOM bugs to the "DOM" Component.