Bug in android when finding elements in the xpath

[alvillaflor]

Noticed that I can get the text by:
findElementsByXPath("//text[1]")
but would see duplicates/triplicates when doing this
findElementsByXPath("//linear[2]/text[1]")
Was expecting to get lesser data since I am specifically asking for the linear[2] path.

Also if I use what the inspector shows, I get an error as well.

d.findElementsByXPath("//linear[1]/window[1]/linear[1]/window[1]/viewflipper[1]/linear[1]/list[1]/linear[7]/linear[1]/linear[1]/linear[2]/text[1]").getText()
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'java.util.ArrayList' object has no attribute 'getText'

And this is the xpath as shown on the inspector:
content-desc:
class: android.widget.LinearLayout
text: close
index: 1
enabled: true
clickable: false
xpath: //linear[1]/window[1]/linear[1]/window[1]/viewflipper[1]/linear[1]/list[1]/linear[7]/linear[1]/linear[1]/linear[2]/text[1]

[jlipps]

I think the bug is because you're using findElements rather than findElement. findElements always returns an array even if there's just one element.

[alvillaflor]

Hi. In this case nothing is returned. Just an err

[jlipps]

Then that means appium couldn't find the element with that xpath selector.

[alvillaflor]

Right that is what i am trying to show what the bug is. The appium inspector shows what the xpath is but when using it I get an err

[jlipps]

@penguinho any chance the inspector is wrong about this android xpath? it looks way long and unwieldy to me.

FWIW, I would never want to put an XPath like this in an actual test. It's much more maintainable to get a handle on it by content-description if you can have the devs add it.

[penguinho]

so, the long and unwieldy part of it is probably correct (which is why my team is using content-desc on everything for android, or relative xpath from an element with content-desc)

I think the problem may be with the shorthand, bootstrap noticed that some of the elements like webview don't derive from android widget, so I think our xpath code assumes everything derives from android.widget

[paymand]

I have been struggling with selecting elements using XPaths in Appium. In my experience, running find_elements_by_xpath('/frame[1]') and find_elements_by_xpath('/frame[100000]') returns the same number of elements. Isn't this true that '/frame[1]' means the first FrameLayout child of the root element and therefore it should only return one element at most?

[bootstraponline]

xpath in Appium has a number of limitations and open bugs. There are better
ways to locate elements.

On Mon, Jul 29, 2013 at 9:40 AM, Payman Delshad notifications@github.comwrote:

I have been struggling with selecting elements using XPaths in Appium. In
my experience, running find_elements_by_xpath('/frame[1]') and
find_elements_by_xpath('/frame[100000]') returns the same number of
elements. Isn't this true that '/frame[1]' means the first FrameLayout
child of the root element and therefore it should only return one element
at most?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/677#issuecomment-21720255
.

[paymand]

Here's my XML source: https://gist.github.com/paymand/6104530 and I'm trying to select the browser's tab container:

<node index="2" text="" class="android.widget.FrameLayout" package="com.opera.browser" content-desc="" checkable="false" checked="false" clickable="false" enabled="true" focusable="false" focused="false" scrollable="false" long-clickable="false" password="false" selected="false" bounds="[0,218][720,729]" />

(Adding a content-desc is not possible, since content-desc is also used for accessibility services like TalkBack and we'd like to add it only when it makes sense.)
So is there any way to achieve this other than converting the tab container to a custom view?

[bootstraponline]

Have you tried finding all elements of that type and then selecting the
index on the client side?

find_elements(:tag_name, 'frame')[0]

On Mon, Jul 29, 2013 at 10:15 AM, Payman Delshad
notifications@github.comwrote:

Here's my XML source: https://gist.github.com/paymand/5576503 and I'm
trying to select the browser's tab container:

(Adding a content-desc is not possible, since it is also used for
accessibility services like TalkBack and we'd like to add content-desc only
when it makes sense.)
So is there anyway to achieve this other than converting the tab container
to a custom view?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/677#issuecomment-21722583
.

[paymand]

That does not work in our app, since we load layout files in runtime which means len(opera.driver.find_elements_by_tag_name('frame')) returns different numbers depending on which parts of the app have been visited.

[bootstraponline]

When the XPath bugs are fixed then that's probably the best option.
uiautomator API 18 has real support for ids, similar to Selendroid, so that
may help in the future.

On Mon, Jul 29, 2013 at 10:49 AM, Payman Delshad
notifications@github.comwrote:

That does not work in our app, since we load layout files in runtime which
means len(opera.driver.find_elements_by_tag_name('frame')) returns
different numbers depending on which parts of the app have been visited.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/677#issuecomment-21725031
.

[paymand]

Support for resource id is definitely awesome! You are referring to https://developer.android.com/tools/help/uiautomator/UiSelector.html#resourceId(java.lang.String), right? Hope we get the Appium support for the new features soon...

[bootstraponline]

On Mon, Jul 29, 2013 at 11:21 AM, Payman Delshad
notifications@github.comwrote:

Support for resource id is definitely awesome! You are referring to
https://developer.android.com/tools/help/uiautomator/UiSelector.html#resourceId(java.lang.String),
right? Hope we get the Appium support for the new features soon...

Yes. I'll be adding Appium support soon.

[bootstraponline]

Fixed in appium 1.0.

[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.