Summary: | W3C XPath test Text_Nodes.svg fails | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Alexey Proskuryakov <ap> | ||||||
Component: | XML | Assignee: | Alexey Proskuryakov <ap> | ||||||
Status: | RESOLVED WONTFIX | ||||||||
Severity: | Normal | ||||||||
Priority: | P2 | ||||||||
Version: | 420+ | ||||||||
Hardware: | Mac | ||||||||
OS: | OS X 10.4 | ||||||||
Bug Depends on: | |||||||||
Bug Blocks: | 12450 | ||||||||
Attachments: |
|
Description
Alexey Proskuryakov
2007-02-03 07:49:33 PST
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. |