Bug 25931 – XPath' position() fails to match elements

• Component: XML
• Status: RESOLVED INVALID

[kangax]

Please, see attached url with a testcase. Only Firefox 3.0.x gets this right so far. I just checked it with latest WebKit nightly (r43887) and the test still fails.

Thank you.

[Alexey Proskuryakov]

Created attachment 30586 [details]
test case

Actually, I do not think that Firefox gets this nearly right. Here is what I think the expression in your test means:
//*[position() = 2] is an abbreviated syntax for /descendant-or-self::node()/child:*[position() = 2]. It is an absolute path, so the context you pass in Document.evaluate() will be completely ignored (thus, document.evaluate(xpath, el, ...) is exactly the same as document.evaluate(xpath, document, ...)).

The first step of this location path, obviously, selects all nodes in a document, including the document node itself. The next step selects all element children that have position 2 within their respective containers (NOT the second element in the document, and definitely not the second element in the test <div>). Since the position is computed respecting Text and other non-element nodes, it is entirely possible that no element will have position 2, even in a large container.

Note the following example in XPath 1.0 specification: "The location path //para[1] does not mean the same as the location path /descendant::para[1]. The latter selects the first descendant para element; the former selects all descendant para elements that are the first para children of their parents."

So, I think that your test case actually shows a bug in Firefox XPath implementation - namely, the absolute path there is treated as if it were relative.

Attaching a larger test I made while investigating this. I cannot explain some of WebKit's results on this test, so I need to look at this test deeper.

[kangax]

Alexey, thanks for an explanation; It definitely makes sense. I see that both - WebKit and Opera (10a) - return proper results when given a relative expression - "*[position()=2]".

I'm not sure if this is a bug per se (and if I should file it with them), or if Firefox just tries to be "unobtrusively helpful" by treating absolute expressions as relative ones when evaluating in a non-global context.

[Alexey Proskuryakov]

Please file a bug with Mozilla - if that's intentional, we'll learn the reasons, and would consider matching Firefox to make life easier for developers.

I'm going to keep this bug open to investigate the apparent mysteries in the attached test case (but to avoid confusion, I'll need to open new bugs if I find real problems).

[Alexey Proskuryakov]

(In reply to comment #1)
> Since the position is computed respecting Text and other
> non-element nodes, it is entirely possible that no element will have position
> 2, even in a large container.

I was wrong here - the node set as seen in predicates is one after applying the node filter.

[Alexey Proskuryakov]

Filed bug 26005 for a problem I found with my test, closing as INVALID since the originally reported issue is not a bug.

Please post a Mozilla bug URL here for future reference if you decide to file one.

[kangax]

Filed with Mozilla - <https://bugzilla.mozilla.org/show_bug.cgi?id=494842>

[Phred]

Created attachment 30707 [details]
test case showing before and after dom append

As best I can discern the spec http://www.w3.org/TR/xpath#path-abbrev :

"//para selects all the para descendants of the document root and thus selects
all para elements in the same document as the context node"

There exist no parent document for the context node in the original URL, thus
there should be no answer (null). Firefox 2 returned null and Opera currently
returns null in this case. However once it is appended to the document, the
answer refers to the root element as it should.

The bug here is that you are executing from the current document root
regardless of whether the context node exist in the document or not.