[Webkit-unassigned] [Bug 77000] New: XHTML getElementsByTagName searches on localName, not QName

Wed Jan 25 03:23:35 PST 2012

https://bugs.webkit.org/show_bug.cgi?id=77000

           Summary: XHTML getElementsByTagName searches on localName, not
                    QName
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Macintosh Intel
        OS/Version: Mac OS X 10.7
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: XML DOM
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: joelh at piquan.org

In an XHTML document with multiple namespaces, it seems that document.getElementsByTagName("prefix:localName") will return an empty list.  On the other hand, document.getElementsByTagName("localName") does return nodes, even ones with a prefix.  On the other hand, element.tagName returns the qualified name ("prefix:localName").

This is (in my testing at least) preventing Facebook from finding FBXML markup in a document served as application/xhtml+xml.

I've attached a test case, but here's an abbreviated example.  In the following document:
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:foo="http://webkit.org/example/namespace">
  <foo:bar/>
</html>

then you'll get these results:

getElementsByTagName("foo:bar") => []
getElementsByTagName("bar") => [ <Element foo:bar> ]
getElementsByTagName("bar")[0].tagName = "foo:bar"

The DOM 2 Core spec doesn't actually have a definition for "tag name", but the definition for createElementNS does make it clear that tagName is intended to be the qualified tag name.

As far as I can tell, there's no way for getElementsByTagName to return any elements from an XML document if there's a colon in the specified tag name.  Adding this capability would be unlikely to have any adverse effects.  However, getElementsByTagName("localPart") should only return elements with unqualified names, and this might break applications that expect the old behavior.  Nevertheless, the current behavior does seem clearly incorrect, and as multiple-namespace documents become more common, it's only going to get harder to change.

I tested this in Safari 5.1.2 (Webkit 534.52.7) and Chrome 17.0.963.38 (Webkit 535.11).  I saw the same bug in both.

Gecko (Firefox 9.0.1) seems to behave correctly.  I haven't tested Trident, but Facebook's code implies that MSIE 9 behaves correctly.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.