Here is more information from Sascha. It provide a way of quick fix.

>>Hi,
>>
>>you need to medify the selenium-server.jar (a jar is a zip file, I assume you know that). In directory core there is a file RemoteRunner.html. You have to edit it and add the following line in the head:
>>
>> <script language="JavaScript" type="text/javascript" src="xpath/javascript-xpath-0.1.11.js"></script>
>>
>>I added it between the script tags loading xpath.js and user-extension.js.
>>
>>Have fun using it.
>>
>>Sascha

Fixed in r2351
Changes:

• Included javascript-xpath-0.1.11.js in RemoteRunner.html
• Extended TestUseXpathLibrary to execute an assertXpathCount after the first two library switches, thus assuring that not only the command execution, but also the switch was effective and correct.
• Changed htmlutils.js/eval_xpath to let javascript-xpath behave the same way ajaxslt can.

This fix does not really solve the problem.

You have included javascript-xpath in RemoteRunner - that's fine.

But the change in htmlutils.js disables javascript-xpath. inDocument is - as I understand it - the test application. There is of course no evaluate() available in Internet Explorer as we do not use this library in our application. But the document (which is the RemoteRunner.html I think) now has an evaluate() function - coming from javascript-xpath. And useDocumentEvaluate has to be set to true as this is what javascript-xpath is adding to the DOM tree.

Shorter: you have to reverse the changes you made in htmlutils.js as the correct code is:

if (xpathLibrary == 'javascript-xpath' && !useNativeXpath) { documentForXpath = document; useDocumentEvaluate = true; } else { documentForXpath = inDocument; }

BTW: is it correct that I cannot find something like a Reopen for this Bug ? (I'm new to Jira)

The following test terminates with success:
// Disable native XPath engine
selenium.allowNativeXpath("false");
selenium.useXpathLibrary("javascript-xpath");
assertEquals(selenium.getEval("this.browserbot.xpathLibrary"), "javascript-xpath");
selenium.open("http://www.google.com");
assertTrue(selenium.getXpathCount("/html").intValue() == 1);
selenium.type("q", "value");

If you have a failing test which shows that this test is insufficient to prove the correctness of the switching logic, then provide it along with all necessary information to be able to reproduce the issue.

Note: The before mentioned revision number is a Core revision number and as there are failing tests in the current RC builds this change hasn't been propagated into the the RC nightlies. This test only applies to local builds incorporating the latest Core nightly.

Your correct. The test will pass - but not using javascript-xpath at selenium.getXpathCount() but the slow ajaxslt implementation. I cannot provide a failing test as XPath is falling back to ajaxslt - so there is nothing that can fail.

Let's have a little try. If javascript-xpath would be used the line 1180 in htmlutils.js could not be reached (as javascript-xpath is handled above and its results are returned in line 1178. You may put an alert() there. In your opinion it should not be reached, but it is ... After line 1180 ajaxslt is used.

I may describe you what happens:

Line 1136: nativeXpathAvailable is set to false as inDocument is the page under test which has no document.evaluate() because IE does not have this function.
Line 1137: useNativeXpath is set to false as both allowNativeXpath and nativeXpathAvailable are false
Line 1138: useDocumentEvaluate is set to false as useNativeXpath is false

Now there is the if. We are in the then part and setting documentForXpath to inDocument (that's wrong, I described this in my last post). useDocumentEvaluate keeps set to false.

Now the next if. We should go in there to get javascript-xpath used, but we couldn't, useDocumentEvaluate is false. We are skipping the if and going directly to the ajaxslt implementation.

The reason for changing the extra lines in htmlutils.js was that even the simple test described in my previous comment fails with 'Invalid xpath: /'.
I think you're right with your reasoning, but unfortunately restoring the two lines doesn't solve the real problem; see SEL-617 for further symptoms.
Apparently this issue needs much more effort than originally planned; thus if you have a patch along with further unit/integration tests don't hesitate to upload.

Unfortunatly I cannot provide a solution working in every environment. The lines I have written in my first comment with the fixed RemoteRunner work on my setup (Selenium RC testing webapps on browsers FF2/3 and IE6/7) - native XPath on FF and javascript-xpath on IE. I've never worked directly with Selenium Core and don't know in detail what the difference could be in XPath handling. But I'll spend some time looking at the problem.

Just to make sure that we're on the same page:
1. Native XPath isn't subject to this issue
2. With javascript-xpath activated
a. Some of the Core integration tests fail (SEL-617)
b. The before mentioned basic RC test case fails.
According to what you wrote there is no problem with javascript-xpath - on IE. Thus, I'll start looking into it (IE 8 on Windows 7).

Two things which would be helpful in the analysis from you are:

• comparison of the execution time in IE with both, the old and the new JS library (ideally along with test characteristics)
• execution of the same tests in Firefox 3 with native XPath disabled [selenium.allowNativeXpath("false");].
  I appreciate your input!

Reverted changes in htmlutils.js/eval_xpath in r2352 as although a basic test fails in Firefox it doesn't matter as Firefox has its own engine, thus none of the JS XPath libraries should be used. The same test succeeds on Windows 7 / IE 8.

The same missing script element was added in r2593 in org.openqa.selenium.server.InjectionHelper, too, for the proxy injection mode.