Support of XPath selectors ?

[davidlinse]

Regarding the docs it's possible to use either css or xpath selectors to find elements. Allhough it looks like that the css selector is hard coded all-over the place in commands and assertions ?
e.g.

// lib/selenium/assertions/elementPresent.js
return this.client.element("css selector", cssSelector, function(result) {}

Is there already any support for XPath selectors ?
regards
~david

[beatfactor]

There is partial support for xpath expressions. Protocol actions and
commands do support them and commands use css selector as default method
of locating elements. You should be able to pass xpath as the first
argument to a command.

E.g.:

client.click('xpath', '/xpath/expression');

Assertions only support css selectors at the moment but I will add support for xpath too soon.

[davidlinse]

Thanks for the quick response, i'll give it a try.

Update:
passing css selector or xpath as first arguments fails.

.waitForElementVisible('css selector', 'body', 2500) 

Error while running waitForElementVisible command:
waitForElementVisible expects second parameter to be number; string given
FAILED:  1 errors and 1 skipped

I was able to quick patch the waitForElementVisible.js to make it work but
this would change the current API and break BC.

Looking forward to your implementation.
~ david

[beatfactor]

this was added in the features/v0.3-refactoring. There are two new methods:

client.useXpath(); // xpath will be used as the locating strategy so all the selectors you pass should be xpath selectors

client.useCss(); // switches back to css selector

By default css is used and you could even mix them in the same test. Let me know what you think.

[davidlinse]

Hi..
👍 for implementing this.

I'd like to see this either expressed in the API with methods like waitForElementVisibleXPath() or
via selector and an appropriate error handling..

It would also remove the additional "noise" from the tests when switching between styles.

What do you think ?
~david

[beatfactor]

You should be able to achieve that with:

client.useXpath().waitForElementVisible()

Does that work for you?

[mam-p]

Hi Andrei! Could you possibly reopen this issue, and eventually implement support such that the type of the locator is dynamically determined via its first characters? In other words, if the locator starts with "//" then treat it as an xpath locator; otherwise, treat it as a css one.

The reason I don't like the solution in your Mar 17 comment above is because the locators need to be located within page object files, not the tests themselves. A test dev s/b able to change the locator to whatever is needed for the latest page changes, without having to worry about the code in the tests that use that locator. So, the xpath-vs-css indication needs to be located within the PO hashes of locators, NOT the calls to the API that specify those locators. Make sense?

[davidlinse]

if the locator starts with "//" then treat it as an xpath locator; otherwise, treat it as a css one.

This is not the only valid xpath expression .. *//selector or ./*/selector are valid expressions too..
See the xpath refs

[webcodecs]

+1

[beatfactor]

Closing this as it is open for far too long and is really a priority for now. Will consider this for a future release.

[hon2a]

@beatfactor Switching through a global flag is quite painful. Is there some way to determine which of the strategies is being used at a particular moment? I'm writing commands that need to use a particular strategy, but I need them to be without side-effects (i.e. change the used strategy back to what it was before the command started).

[illegalnumbers]

I am in the same place as @hon2a, managing global state this way is kinda painful and especially in many page objects that could be doing their own selectors it would be nice to just be able to do this.click('xpath', '//selector', callback()) or an equivalent and not have it change global locator state.

[pushkalaP]

Hi I have Issue with XPAth :

My application is in react JS, I am using nightwatch JS for automation. This is my xpath : "(//div[@Class="Select-input"])[3]". When i try to locate the element with this xpath the application uniquely identifies it.

below code in nightwatch :

client .waitForElementPresent('(//div[@Class="Select-input"])[3]',10000)
.setValue('(//div[@Class="Select-input"])[3]', ['apples', "\uE007"])

does nightwatch support this kind of xpaths?

[kretschmannj]

+1 for getting this fixed. Seems that a 'locator strategy' argument should be added to allow specifying xpath or css. Also, the documentation is incomplete/misleading in this regard. See https://nightwatchjs.org/api/. There is mention that the selector can be CSS/XPath. However, there is no mention of the fact that css is used by default and that client.useXpath() must be used in order to switch to xpath and client.useCss() must be used to switch back to css.