Problem selecting WebElements with XPath (works with FF)

[andywuest]

Hi,
i am having problem with getting WebElements using XPath. The XPath expression works fine with firefox,
however it fails with Opera and returns just nothing. The expression is:

//select[@id='stammdatenForm:userTypeInput']/option

final List elements = driver.findElementsByXPath(xpathExpression);

Basic question: is the findElementsByXPath already implemented in the opera driver?
If you need more information about the html page causing the problem, please tell me.

cheers,
Andy

[Stuk]

Yep, findElementsByXPath is implemented. And a bit more information about the page or the page itself would be really useful!

[andywuest]

Hi,
with the xpath expression i want to select the select box options with the given id. the select box is contained in a modal dialog that will is opened via an ajax request. the app is an jsf richfaces application. you can find the source of the displayed html page (saved with ff) at http://pastebin.com/7d3EQcee
using the experimental dragonfly debbugger and the xpath does not work either (at least not reliable). almost most of the times it does not work. if you need more information tell me.

cheers,
andy

[Stuk]

It seems to work for me here with v0.5.2 on Ubuntu Linux with Opera 11.50. I'm using this script: https://gist.github.com/1113494 with your html file above. It outputs:

Experte(1)
Neuling(2)
Gelegenheitsnutzer(3)

[andywuest]

i have created a two litte projects to show the problem with a running application. using only a html snippet is not really suitable to reproduce the problem i guess. what is the best solution to share the projects with you? can i sent them to you via email or should i upload the two zip files somewhere ?

[andywuest]

found a place to upload the files:
http://minus.com/m1sc8D
http://minus.com/mcmOS6K
those are the files.
some instructions: just unzip the operaapp.zip und execute
mvn clean package jetty:run
maven will probably download the internet, if you do not have all the dependencies. the application will be accessable
via
http://localhost:8080/opera/pages/index.jsf
The testcase will click on the "show modal panel" button and then wait for 3 seconds before executing the xpath
to count the elements in the select box contained in the modal dialog.

Testcase:
unzip the other zip file as well and execute
mvn eclipse:eclipse
to generate the eclipse configuration files. then import the project into eclipse. the two contained jars for
the opera driver have to be added to the project manually, because they cannot be resolved via a maven repository.
Then just execute the IndexTest.java file via junit. The text will fail in both cases, however it succeed.

[Stuk]

Does this problem only occur when running the jetty server? Or can you reproduce it using a static html page? If so could you just send me the html for the static page, because Maven can't find the following dependencies:

org.richfaces.ui:richfaces-ui:jar:3.3.3.Final
org.richfaces.framework:richfaces-impl:jar:3.3.3.Final
javax.faces:jsf-api:jar:1.2_12
el-impl:el-impl:jar:1.0
javax.faces:jsf-impl:jar:1.2_12

[andywuest]

the problem only occures when running against a server (in my case jetty). using the static html file works fine in my test.
i have updated the pom.xml so it should now be possible to resolve all dependencies. if you encounter any problems, tell me.
https://gist.github.com/1120701

[Stuk]

First of all, I had more luck prepending your xpath with //: //select[@id='stammdatenForm:userTypeInput']/option.

It appears the JS that is ran when the "Show Modal Panel" is clicked messes up something in Opera. I can reproduce the problem using your Jetty server and this simple script: https://gist.github.com/1122315/9b41df4452786165e0829583d69643659941ad8d . If you comment out line 18 then all the XPath expressions work. Do you have any idea what the script might be doing to cause this?

Oh and the XPath can be tested in Dragonfly/Firebug/Inspector with this line: document.evaluate("//select[@id='stammdatenForm:userTypeInput']/option", document, null, XPathResult.FIRST_ORDERED_NODE_TYPE, null ).singleNodeValue

[andywuest]

no, unfortunately i have no idea what the javascript is doing. the used jsf component is a standard richfaces component that provides all the javascript and works out of the box. The only thing one has to do is to make sure that after tha ajax call is finished the modal dialog will be displayed by providing some callback functionality:

oncomplete="#{rich:component('panel')}.show();"

in order to display the modal dialog some DOM manipulations need to happen (hidden -> visible), so something definitely need to happen. Is it possible to serialize the dom before clicking and after clicking. this way it would be possible to find out the differences by comparing the two dom trees. strange is the fact, that if you save the html page after the click and load the static page the xpath expression works again.

since i cannot see any javascript errors and the page works as expected in the browser, i guess the problem must be something within the opera browser and/or the xpath execution engine or the way the dom is provided. i guess you have to check with the developers why the xpath cannot be evaluated after the click on the button.

[lkende]

I've also had issues with Opera and finding elements by xpath. Depending on the version of Opera (I use some 10.xx versions), and the version of OperaDriver, it's been flaky enough that I just use a javascript method for sending keys to login fields. This has worked well for me:

js.executeScript("var _xpathResult = document.evaluate(""+xpathSelector+"",document,null,XPathResult.FIRST_ORDERED_NODE_TYPE,null); _xpathResult.singleNodeValue.value='"+inputValue+"';");