inject <hierarchy> element into xpath root expressions

[Jonahss]

We add the node at the root element to the xml hierarchy, since Android doesn't supply a root element. Problem with that is, a query like this /android.widget.FrameLayout or this /* will fail, since the node doesn't exist in the UI. This works though: /hierarchy/android.widget.FrameLayout.

Proposed fix: Auto inject the hierarchy node into absolute xpath expressions. so:
/android.widget.FrameLayout' ->/hierarchy/android.widget.FrameLayout`

Curious about @bootstapOnline's thoughts

[bootstraponline]

I don't think we should be automagically injecting stuff into the xpath expression. The source output is what it is. People should write xpath that is valid.

[jlipps]

related: #3801

[0x1mason]

@bootstraponline I would agree, except I'm not sure users have a good way to figure out what the real XPath is. In UI Automator Viewer, eg, there's no name provided for the root element. If we go with @Jonahss's suggestion, we could apply it selectively, eg

if (xpath[0] === '/' &&
   !xpath.startsWith(['//', '/*', '/hierarchy']) {
     xpath.prepend('/hierarchy');
}

The other option is to simply doc it. That might be the simplest option for now, since as @bootstraponline implies, there's nothing really wrong with the way we're doing it.

It would def help to have better error messaging in this case. Maybe something like

// try to locate element
...

if (element == null && isAbsPathMissingHierarchyOrWC(xpath)) {
  // return meaningful msg:

  // "It looks like you were using an absolute path.
  // Here's why it may not have worked: yada yada."
}

[bootstraponline]

In UI Automator Viewer, eg, there's no name provided for the root element.

uiautomator doesn't support xpath. uiautomatorviewer thus has no support for it either. Appium specific feaures require the appium inspector.

[bootstraponline]

Maybe we could do something like

I'm pretty sure we'd have to update the mobile spec.

If someone downloads the xml and runs xpath client side (as was done in the ruby_lib), I would expect that to be the same as the server. Magic prepending doesn't seem like a good idea to me because people can write valid xpath.

[0x1mason]

@bootstraponline if they have to use the inspector to know what to expect, we should add that to the error message. Also make it clear in the docs, if it isn't already. Eg, it didn't occur to me to use the inspector (in fact, it never occurs to me to use the inspector, but that's a good lesson).

[bootstraponline]

users have two options

• invoke page_source and figure out the xpath by reading the xml
• use the appium inspector

we should add that to the error message. Also make it clear in the docs, if it isn't already.

I agree.

[0x1mason]

@bootstraponline has swayed me. I think we should just doc this and improve our error messaging.

[JessicaSachs]

The .app inspector doesn't show the hierarchy element anywhere. I use it to test all my locators. Should open ticket for that if that's the proposed solution

[bootstraponline]

The .app inspector doesn't show the hierarchy element. I use it to test all my locators.

That's true it doesn't show the hierarchy element. You'd only know about hierarchy by looking at the XML source. Possibly viewing the xml could be an enhancement request.

The inspector generates xpaths that start with // which work properly even with the hierarchy element.

[JessicaSachs]

Yeah that would be a good enhancement.

Other absolute path things that are weird to me: hierarchy/* returns elements, ./* does not.

If I'm looking at an xpath doc and trying out the different supported syntaxes -- Appium's behavior confuses me.

What would be the most helpful thing I could do? Document what I'm seeing vs. expected?

[bootstraponline]

I recommend trying the following:

• download the xml
• run the search against this client side xml
• run the search against the server and compare

If appium produces something different then it's potentially a bug. If not then it's probably just how xpath works. A REPL is great for trying out locators.

[JessicaSachs]

I was doing that last night and I found some discrepancies. Where would you like the list of them?

[bootstraponline]

A new issue would be great.

[JessicaSachs]

K I'll add them later today.

[Jonahss]

I'm for improving error codes.
Right now, an invalid xpath expression, and a valid one which does not return any elements both result in "unknown sever-side exceptions"

[jlipps]

ok, added to a milestone to fix the error message. i agree that's all we should do (or if the inspector wants to add the root element in its output, that's up to the maintainers--but we should alter the way the server handles xpath)

[sebv]

Fixed error message, see PR above.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.