Bug 15436 – Wrong proximity positions for XPath reverse axes

• Component: XML
• Status: RESOLVED FIXED

[nanto_vi (TOYAMA Nao)]

In XPath 1.0, the context position of a node in a node-set for a reverse axis is defined by reverse document order [1].  But WebKit uses document order for ancestor, ancestor-or-self, and preceding axes and arbitrary order for preceding axis.  Think the following code:

<ul>
  <li id="li1">foo</li>
  <li id="li2">bar</li>
  <li id="li3">baz</li>
</ul>
<script type="text/javascript">
alert(document.evaluate('preceding-sibling::*[1]',
                        document.getElementById('li3'), null, 8, null)
              .singleNodeValue.id);
</script>

WebKit alerts "li1" while Gecko and Opera alerts "li2".  This is revealed by amachang's XPath test (see the URL field).

[1] http://www.w3.org/TR/1999/REC-xpath-19991116#predicates

[Alexey Proskuryakov]

Created attachment 16597 [details]
test case (for fast/xpath)

[Alexey Proskuryakov]

Created attachment 16598 [details]
proposed fix

[Anders Carlsson]

Comment on attachment 16598 [details]
proposed fix

r=me

[Alexey Proskuryakov]

Committed revision 26174 (feature branch).

It would be nice to include the whole test in our regression suite. I tried to find the author and sent an e-mail asking for permission, but I could have got it wrong...