XPath parser fails on $var/foo but not $var//foo

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use an xpath expression that has a variable containing a node list.
2. Reference a child of this node list using the absolute '/' operator
3. JS exception is thrown about how the expression can't be parsed.

What is the expected output? What do you see instead?

Expect to see the string $var/foo parsed. Instead a js exception is thrown.

What version of the product are you using? On what operating system?

Tried using the latest from trunk (ajaxslt v7) still an issue. OS X 10.4

Please provide any additional information below.

Stepping through the source with a js debugger the issue is resolving
precedence with the '/' operator. In the xpathTokenRules object, '//' has a
prec of 19 and '/' of 30. Inside of xpathReduce() when calculating the prec
of the candidate and ahead, will fail to pop the stack. It is comparing the
prec of XPathFilterExpr which is set to 20 and '/' which is 30.

Modifying line 1927: 

[ XPathFilterExpr, [ XPathPrimaryExpr, XPathPredicate, Q_MM ], 31,
makeFilterExpr ],

to use a prec value of 31 instead of 20 solved the issue for me and allowed
the expression to be parsed. However I am not sure of all the consequences
of changing this prec value.

Original issue reported on code.google.com by dr.seamu...@gmail.com on 29 Jan 2007 at 6:31

[GoogleCodeExporter]

Sorry, forgot to mention that I ran the unit tests for xpath and it returned 
success.

Original comment by dr.seamu...@gmail.com on 29 Jan 2007 at 6:45

[GoogleCodeExporter]

Original comment by steffen....@gmail.com on 12 Feb 2007 at 5:07

• Changed state: Accepted

[GoogleCodeExporter]

There is a similar problem with functions that return a nodeset.

E.g. id('foo')/bar doesn't work though id('foo')//bar does.

Original comment by jonhanna...@gmail.com on 20 May 2007 at 10:10

[GoogleCodeExporter]

Oops. My point in making the above comment was that it fails for id('foo')/bar 
even
after the fix suggested in the initial report here. That it fails in the same 
way
would seem to indicate it's the same issue, but that the fixed precedence is 
still
incorrect.

Original comment by jonhanna...@gmail.com on 21 May 2007 at 10:24