User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:220.127.116.11pre) Gecko/20070711 Camino/1.6a1pre (like Firefox/18.104.22.168pre)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a7pre) Gecko/2007071604 Minefield/3.0a7pre
Evaluating an XPATH expression using document.evaluate() throws an error if the contextNode is an empty text node.
Error: uncaught exception: [Exception... "Operation is not supported" code: "9" nsresult: "0x80530009 (NS_ERROR_DOM_NOT_SUPPORTED_ERR)" location: "http://tests.novemberborn.net/browsers/gecko/xpath/evalutation-exception.html Line: 20"]
The line number corresponds with the result argument.
Steps to Reproduce:
1. Open Firefox
2. Open the error console, make sure it's cleared
3. Go to the test case: http://tests.novemberborn.net/browsers/gecko/xpath/evalutation-exception.html
A NS_ERROR_DOM_NOT_SUPPORTED error is thrown.
No error is thrown. "[Object HTMLSpanElement]" is alerted.
This problem also occurs in Firefox 2.0.
Firefox 2.0 gives the following exception:
Error: uncaught exception: [Exception... "Object cannot be created in this context" code: "9" nsresult: "0x80530009 (NS_ERROR_DOM_NOT_SUPPORTED_ERR)" location: "http://tests.novemberborn.net/browsers/gecko/xpath/evalutation-exception.html Line: 22"]
This looks like intended behavior. Peter, could you explain why?
Is it because of http://www.w3.org/TR/xpath#section-Text-Nodes ?
The xpath implementation does no text node normalization, so http://www.w3.org/TR/xpath#section-Text-Nodes is not the reason.
In Xopus I catch these errors, and work around it by making the parent element the context node, and prefixing the xpath expression with "node()[x]/" where x is the number of preceding siblings of the text node. Then everything works as expected.
So I think this test should just go, as empty text nodes as context will probably work just fine.
This is because the DOM and the XPath data model differ: XPath doesn't have empty text nodes. We don't enforce that everywhere in Transformiix, but probably should do more of these checks instead of less. We could just not throw in this case and return an empty result.
"If the context node is a Text or a CDATASection, ..., unless the node is empty in which case it may not serve as the XPath context."
The same goes for document fragments.
This test fails for document fragments, but if I start at a child of the document fragment and add "../" to the xpath expression, everything works fine.