dom/svg/level3/xpath/Text_Nodes.svg The test is supposed to verify that the implementation only returns the first text node in a chain of siblings, but its condition is actually inverted! This is not a conversion artifact, see <http://dev.w3.org/cvsweb/2001/DOM-Test-Suite/tests/level3/xpath/Text_Nodes.xml?rev=HEAD&content-type=text/x-cvsweb-markup> for the original. Fixing the condition makes the test pass in Opera, but not in Firefox, which apparently doesn't implement this behavior.
Created attachment 12901 [details] proposed fix This behavior looks pretty weird, and is not supported by Firefox, so I have certain doubts about this patch. But at least Opera passes the test.
Comment on attachment 12901 [details] proposed fix + if ((node->nodeType() == Node::TEXT_NODE || node->nodeType() == Node::CDATA_SECTION_NODE)) { isCharacterDataNode() is another way to do the same check -- maybe we should use that. + * dom/svg/level3/xpath/Text_Nodes.js: Invert the success condition, as the test appears incorrect. Should we report this to the W3C? Please add comments to the test to indicate that we've made local modifications. r=me
Committed revision 19389. (In reply to comment #2) > isCharacterDataNode() is another way to do the same check -- maybe we should > use that. Hmm... Seems to be less than 100% clear that this includes Text nodes (at least, I had to look that up), so I left the check as is. > Should we report this to the W3C? Sure, will try to report this via mailing list. > Please add comments to the test to indicate that we've made local > modifications. Done.
(In reply to comment #3) > Sure, will try to report this via mailing list. Actually, seems like Bugzilla is the right way: <http://www.w3.org/Bugs/Public/show_bug.cgi?id=4297>.
I'd like to take this back. After a more detailed examination, it turns out that we don't match Opera anyway in many cases, and the (draft) spec doesn't fully define the behavior. I cannot figure out what the intended behavior is when the context node is an arbitrary text one. For example, in a fragment such as "<elem>a<![CDATA[b]]>c</elem>", going by "ancestor-or-self" axis from the last text node clearly shouldn't produce [elem, first-text-node]. The situation for "preceding" and "following" axes is similar. Given the above, and the fact that this behavior isn't implemented in Firefox (including today's Minefield), I suggest that we drop it.
Created attachment 13586 [details] undo the fix
Committed revision 20110, marking WONTFIX.