Bug 12560 – W3C XPath test Text_Nodes.svg fails

• Component: XML
• Status: RESOLVED WONTFIX

[Alexey Proskuryakov]

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.

[Alexey Proskuryakov]

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.

[Darin Adler]

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

[Alexey Proskuryakov]

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.

[Alexey Proskuryakov]

(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>.

[Alexey Proskuryakov]

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.

[Alexey Proskuryakov]

Created attachment 13586 [details]
undo the fix

[Alexey Proskuryakov]

Committed revision 20110, marking WONTFIX.