appium: click the same element twice or more, throw a uiautomator exception
@wenshi11019 commented on Thu Dec 01 2016
when I click the same element twice or more, use two of the same click on the statements, or use the for statement, it will throw a exception.
sometimes before i click the element, use Thread.sleep(1000),it can run success, but sometime it still throw the same exception
appium version:1.6.1 appium-uiautomator2-server version: 0.0.6
org.openqa.selenium.StaleElementReferenceException: android.support.test.uiautomator.StaleObjectException at android.support.test.uiautomator.UiObject2.getAccessibilityNodeInfo(UiObject2.java:629) at android.support.test.uiautomator.UiObject2.getVisibleBounds(UiObject2.java:210) at android.support.test.uiautomator.UiObject2.getVisibleCenter(UiObject2.java:251) at android.support.test.uiautomator.UiObject2.click(UiObject2.java:343) at io.appium.uiautomator2.model.UiObject2Element.click(UiObject2Element.java:42) at io.appium.uiautomator2.handler.Click.safeHandle(Click.java:39) at io.appium.uiautomator2.handler.request.SafeRequestHandler.handle(SafeRequestHandler.java:54) at io.appium.uiautomator2.server.AppiumServlet.handleRequest(AppiumServlet.java:201) at io.appium.uiautomator2.server.AppiumServlet.handleHttpRequest(AppiumServlet.java:192) at io.appium.uiautomator2.http.ServerHandler.channelRead(ServerHandler.java:44) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345) at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345) at io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:435) at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293) at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:267) at io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:250) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345) at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1294) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352) at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:911) at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131) at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:611) at io.netty.channel.nio.NioEventLoop.processSelectedKeysPlain(NioEventLoop.java:514) at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:468) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:438) at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:140) at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144) at java.lang.Thread.run(Thread.java:818)
@sravanmedarapu commented on Thu Dec 01 2016
Have you tried by setting implicit wait ?
@wenshi11019 commented on Thu Dec 01 2016
@sravanmedarapu it doesn’t work, and thorw the same exception. But use the Thread.sleep() can work.
@sravanmedarapu commented on Thu Dec 01 2016
@wenshi11019 is the element in scrollable view ?
@wenshi11019 commented on Thu Dec 01 2016
@sravanmedarapu yeah, I click the contacts elements twice, or click back button twice.
@sravanmedarapu commented on Thu Dec 01 2016
Unlike Google UiAutomator, UiAutomator2 throws StaleObjectException when the underlying view is changed.
Please refer this: https://github.com/appium/appium-uiautomator2-server/wiki#behavioral-changes-with-respect-to-existing-appium-android-driverbootstrap
However this is something we should look into and find optimal solution.
As a work around, you can try to re find the element when the underlying view is changed.
@wenshi11019 commented on Thu Dec 01 2016
Thanks, I try this way.
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 33 (1 by maintainers)
No The issue is still there.
I was trying to avoid the element caching but the suggested solution is the way how we work with PageObjects , the element is the Page’s property which is being initialised on the page’s creation.
By changing it to “driver.findElement” we are breaking the concept …
I was wonder if there a ways to “refresh” the initialised page object ?
so by doing that we are refreshing all the cached elements
@sravanmedarapu what do you think, should we have a mode for the server that re-finds an element using a cached locator strategy if we run into a stale element exception?