RESOLVED INVALID 77000
XHTML getElementsByTagName searches on localName, not QName 
https://bugs.webkit.org/show_bug.cgi?id=77000
Summary XHTML getElementsByTagName searches on localName, not QName
Joel Ray Holveck
Reported 2012-01-25 03:23:36 PST
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.
Attachments
Test case (1.09 KB, application/xhtml+xml)
2012-01-25 03:27 PST, Joel Ray Holveck 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Joel Ray Holveck
Comment 1 2012-01-25 03:27:39 PST
Created attachment 123912 [details] Test case
Alexey Proskuryakov
Comment 2 2012-01-25 11:20:11 PST
> The DOM 2 Core spec doesn't actually have a definition for "tag name" I almost sent a comment saying the same, but now I think that we can see Element.tagName definition as a definition of tag name.
Eric Seidel (no email)
Comment 3 2012-01-25 13:47:00 PST
https://developer.mozilla.org/en/DOM/element.getElementsByTagName doesn't seem to show prefix support either, but it's unclear.
Eric Seidel (no email)
Comment 4 2012-01-25 13:49:38 PST
I believe this bug is invalid. getElementsByTagNameNS is how you would look up prefixed elements. The prefix is just help for hte parser to get the elements into the right namespace, it seems the DOM just uses the namespaces and forgets about the prefixes for the most part.
Eric Seidel (no email)
Comment 5 2012-01-25 13:50:21 PST
I'm happy to support prefixed lookups if we have a spec to back up such a choice.
Alexey Proskuryakov
Comment 6 2012-01-25 14:41:06 PST
DOM Core appears to be a spec saying that this bug is valid.
Eric Seidel (no email)
Comment 7 2012-01-25 14:49:33 PST
(In reply to comment #6) > DOM Core appears to be a spec saying that this bug is valid. I must haved missed it. Could you do me a favor and cite the line in the bug, so we don't forget? Thanks!
Alexey Proskuryakov
Comment 8 2012-01-25 15:01:32 PST
"getElementsByTagName Returns a NodeList of all the Elements in document order with a given tag name and are contained in the document" "[Element.]tagName of type DOMString, readonly The name of the element. If Node.localName is different from null, this attribute is a qualified name." I think that it's not much of a stretch to say that "Element tag name" and "Element.tagName" are one and the same.
Eric Seidel (no email)
Comment 9 2012-01-25 15:39:52 PST
OK. Seems reasonable. Thanks for the report.
Lucas Forschler
Comment 10 2019-02-06 09:02:49 PST
Mass moving XML DOM bugs to the "DOM" Component.
Ahmad Saleem
Comment 11 2022-08-01 15:22:14 PDT
I am getting following outputs across browsers: *** Safari 15.6 on macOS 12.5 *** Elements matching foo:bar: [ foo:bar ] Elements matching bar: [ ] *** Chrome Canary 106 *** Elements matching foo:bar: [ foo:bar ] Elements matching bar: [ ] *** Firefox Nightly 105 *** Elements matching foo:bar: [ foo:bar ] Elements matching bar: [ ] ________ I am not sure on web-spec but all browsers are matching on attached test case and does not have any console error as well to indicate that the test case is working fine. Is it something still a bug to fixed or DOM3 spec redefined this behavior and above is expected behaviour. Appreciate if someone can mark this bug accordingly. Just wanted to share updated test results. Thanks!
Ryosuke Niwa
Comment 12 2022-08-01 21:11:23 PDT
This is working as expected now.
Note You need to log in before you can comment on or make changes to this bug.