[Webkit-unassigned] [Bug 25931] XPath' position() fails to match elements

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=25931


ap at webkit.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|webkit-                     |ap at webkit.org
                   |unassigned at lists.webkit.org |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1




------- Comment #1 from ap at webkit.org  2009-05-22 11:48 PDT -------
Created an attachment (id=30586)
 --> (https://bugs.webkit.org/attachment.cgi?id=30586&action=view)
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.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You are the assignee for the bug, or are watching the assignee.