Bug 30993 – Node.lookupNamespaceURI doesn't convert empty strings to null

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[nanto_vi (TOYAMA Nao)]

Although DOM3 Core says nothing about how to treat Node.lookupNamespaceURI(''), Mozilla treats empty strings in the same way as null.  Accepting empty strings as null also improves the compatibility with Opera, which only accepts empty strings.

To reproduce, execute the following JavaScript code:
var doc = new DOMParser().parseFromString('<root xmlns="http://example.org/"/>', 'application/xml');
alert(doc.lookupNamespaceURI(''));

Expected: http://example.org/
Actual: null

Confirmed on WebKit-r50095

[Alexey Proskuryakov]

Yeah, <http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0126.html>. If Gecko isn't going to make this behavior strictly compatible with the letter of DOM 3 Core, we should probably bite the bullet and implement their quirk.

[Boris Zbarsky]

You might be interested in https://bugzilla.mozilla.org/show_bug.cgi?id=312019

I'm also pretty sure the Gecko behavior for "" here is unintentional, for what it's worth.

[Rob Buis]

Created attachment 206117 [details]
Patch

[Build Bot]

Comment on attachment 206117 [details]
Patch

Attachment 206117 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/991244

New failing tests:
svg/batik/text/smallFonts.svg

[Build Bot]

Created attachment 206120 [details]
Archive of layout-test-results from webkit-ews-07 for mac-mountainlion

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-07  Port: mac-mountainlion  Platform: Mac OS X 10.8.3

[Rob Buis]

Created attachment 206152 [details]
Patch

[Sam Weinig]

Comment on attachment 206152 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=206152&action=review

> Source/WebCore/dom/Node.cpp:1446
>      // http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/namespaces-algorithms.html#lookupNamespaceURIAlgo

If we not longer plan on following DOM Level 3 here, we should update the comment.

[Sam Weinig]

What's with the two failing tests? Is DOM4 in conflict with DOM3? Is that an intentional diversion?

[Anne van Kesteren]

I don't recall the specifics. I guess I wrote down what Gecko implemented assuming the rule about null and the empty string in DOM Level 3 was also meant for prefixes and not just namespaces.

[Sam Weinig]

(In reply to comment #9)
> I don't recall the specifics. I guess I wrote down what Gecko implemented assuming the rule about null and the empty string in DOM Level 3 was also meant for prefixes and not just namespaces.

The test suite differs I guess.   Not sure how I feel here.

[Joseph Pecoraro]

Comment on attachment 206152 [details]
Patch

Sorry, this patch has grown stale.

I'm going to r- because, this should add a new test for the new expected behavior instead of just depending on the xhtml/level3 test failures. Perhaps this is now covered by `LayoutTests/imported/w3c/web-platform-tests/dom/nodes/Node-lookupNamespaceURI.html` and all we need to do is rebase the patch and re-run all tests.

[Rob Buis]

Closing, this was fixed by:
http://trac.webkit.org/changeset/204536

[Radar WebKit Bug Importer]

<rdar://problem/45883375>

[Lucas Forschler]

Mass moving XML DOM bugs to the "DOM" Component.