Attempting to .click() an element throws StaleObjectException when using UiAutomator2

The problem

When using UiAutomator2, I am not able to click on certain elements retrieved with .findElements() due to a mighty unhelpful StaleObjectException. UiAutomator seems to work fine.

Environment

• Appium version (or git revision) that exhibits the issue: 1.7.2
• Last Appium version that did not exhibit the issue (if applicable): I haven’t a clue.
• Desktop OS/version used to run Appium: Ubuntu 17.10 (Linux 4.13.0) on x86_64
• Node.js version (unless using Appium.app|exe): v6.11.4
• Mobile platform/version under test: Android
• Real device or emulator/simulator: Real Device, Samsung J7
• Appium CLI or Appium.app|exe: CLI, error occurs with the AppImage too, though

Some extra info:

• Using the java client and appium-desktop’s inspector
• Version of appium-android-bootstrap: 2.10.0
• Version of appium-uiautomator: 1.1.5
• Version of appium-uiautomator2-driver: 0.11.0
• Version of appium-uiautomator2-server: 0.3.0

<rant> I’d try updating appium-uiautomator2-driver and appium-uiautomator2-server, but sadly I have little knowledge of node and npm seems to be one of the least user-friendly and most badly designed pieces of package management software I have ever seen. </rant>

_{I really don’t like node, could you tell?}

Details

I am writing automated tests for one of our company’s apps. There, I have horizontal scroll view (android.widget.HorizontalScrollView) whose elements (android.widget.LinearLayouts) I each need to click, then check what is shown.

Finding these elements and iterating over them in order is not a problem, it works fine. When attempting to .click() each element, however, I consistently get a StaleObjectException (wrapped in the java client’s StaleElementReferenceException). This occurs both when simply running my code as well as when attaching to the session using appium-desktop’s inspector and clicking through that. It does not occur, however, when creating the session using the inspector.

The only difference between the two that I have been able to make out is that our code uses UiAutomator2 (and needs to use it, otherwise more stuff breaks) while the inspector defaults to the older UiAutomator.

Frustratingly, we have been using UiAutomator2 extensively to test our apps, and, while annoying StaleObjectExceptions pop up seemingly at random from time to time, this is the first and only instance where we have run into this issue every time.

Link to Appium logs

Here. appium_broken.log is the failing attempt using UiAutomator2, appium_unbroken.log is the successful attempt using UiAutomator. Both sessions were created and the elements clicked using appium-desktop’s inspector.

Code To Reproduce Issue

As mentioned, the issue is reproducible using appium-desktop’s inspector, and as such is likely not a product of my code. But here it is anyways:

        Set<WebElement> seen = new HashSet<>();
        List<Stop> stops = new ArrayList<>();

        for (;;) {
            List<WebElement> newElements = timeline.findElements(By.id("colorIndicator"));
            newElements.removeAll(seen);
            if (newElements.isEmpty()) break;
            else seen.addAll(newElements);
            // newElements will have two (seemingly valid) elements at the first and only iteration

            for (WebElement element : newElements) {
                element.click(); // this is what fails
                boolean isCheckOut = !pickupAddress.isDisplayed(); // a stop can be either for check-in or check-out of a passenger
                // if the .click() call is replaced by an alternative such as a touch action on the element's position, the following statement will still fail with the same exception
                String customer = element.findElement(By.id("taskTitleName")).getText();
                stops.add(new Stop(customer, isCheckOut));
            }

            // swipe the scroll view to see the next elements
        }

Edit: timeline is a WebElement created by the java client’s DefaultFieldDecorator, though I doubt that matters. it references the aforementioned android.widget.HorizontalScrollView.

Please git clone https://github.com/appium/appium and from the sample-code directory, use one of your favourite languages and sample apps to reproduce the issue.

In case a similar scenario is missing in sample-code, please submit a PR with one of the sample apps provided.

I’m afraid I don’t really have the time to do this, I hope the information I have given is sufficient to track down the problem.

Thanks in advance.

Cheers from a meltingly hot office in Berlin, Max

[MHajoha]

I don’t mean to be rude to you, but do you honestly think I spent upwards of 5 hours trying to figure out a fix for this issue, then wrote a lengthy and detailed issue description on it… And I didn’t think to Google the exception?

Well, whatever you may think of the users of your library, the heat hasn’t quite destroyed that many of my braincells. I did Google the exception. In fact, being a sane human being, it’s the first thing that I did. What I found was just as unhelpful as your comments: the underlying View has been destroyed, does not exist in the tree anymore and/or is replaced with an element with another internal id.

It may often be the case that the element has been cached for a while and it has changed in the App. It isn’t the case here, however. As I pointed out: The Element is ‘stale’ immediately after it has been found. Even if there were time for it, there is no state change in the element. Speaking to our Android developer, the view in question is refreshed periodically, but every few seconds, not microseconds as would need to be the case here.

Your suggestion of not storing the elements in a list also sadly made no difference (I don’t see why it would). The amount of time passing between the element being found and .click() being called is tiny. The issue here might not be in appium, but there is most certainly an issue, this can’t be desired behaviour.

Being involved in some smaller-scale open source work myself, I understand that you likely have a day job and haven’t a lot of time to devote to this, however some willingness, if not enthusiasm, to help the users of your software is generally there. “Google it” is not a helpful, but an insulting response to any question or discussion.

[lock[bot]]

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.