XCUITestDriver returns StaleElementReferenceError: Element does not exist in cache #18839
Comments
ilendemli
added
Bug
|
Maybe the internal elements cache is refreshed every time the web view context is switched. Try to locate elements instead of using cached ones as a workaround |
mykola-mokhnach
added
Mobile Safari
|
Also, it is not possible to help more without the full server log |
|
We are already using locators as far as i know. I will try to provide a log but have to redact a lot. |
sorry, I don't get that. Locators are required anyway. What I am talking about is instead of using something like: change it to |
|
Closed because of no response |
|
@mykola-mokhnach Hey, sorry I haven't had any time looking into this. In the meantime I downgraded nodejs to 16.20.1 and npm to 8.19.4 because I had some issues connecting to my phone. We still have the problem so please reopen this. Here is the server log with our informations redacted: https://gist.github.com/ilendemli/30afdc6719755648466c9036d5dcb0cb. If you need any assistance regarding this please contact me and I can share more information privately. We are basically doing the same test twice in one run, it hangs during the second run, where there is a new WebView context. EDIT: Also this gets printed when logging to a file: Safari can inspect page with no issues after appium server is closed. |
|
The log above shows that Appium 1 is used, which we don't support. Please upgrade to Appium 2 first. Also, have you applied the above workaround in your client code? |
|
I will try to get this running with Appium 2 again soon and provide you a log. Afaik I had the same issue with it back when I managed to run this. We also tried the workaround, but in our case we first switch the context when try to find elements using the locator, so it's basically: |
|
@mykola-mokhnach here is the server log from appium 2 running the same test: https://gist.github.com/ilendemli/c89c0ba717e0fe5284c0daa9c6d69702 |
|
The element you're trying to get the text of is an alert? Alerts are typically native elements (not webview ones), so I would work with the alert in the native context. |
|
@jlipps no, line 6433 i get current contexts, 6440 i set the context, 6481 i try to find the element using css selector in webcontext, fails, but should not, ignore the infobubble alert stuff for the moment follow from line 1867, it's literally the same test flow twice in code, second time does not go through EDIT: when i log the server to a file, i get the this error printed EDIT: this makes no sense |
mykola-mokhnach
added
Needs Triage
|
OK, the error appears to be happening when Appium is checking whether an alert is obscuring the webview. @mykola-mokhnach can you tell whether this error is coming from WDA or the driver? |
|
This error is coming from the remote debugger or the atom itself. I cannot say for sure. |
|
@mykola-mokhnach are you sure? This looks like it's being proxied to WDA |
|
Yes, I am 100% sure.
This error might only come from the remote debugger. Also the stacktrace is pretty obvious |
|
I would love to help but I am not sure how to setup the IDE to run and debug appium and its node_modules. My breakpoint that I set in the module do not trigger. |
|
Is the element you're trying to locate deeply nested? The only time I see the StaleElementReferenceError on iOS is because of this issue |
|
@scottpage1317 Not sure that is the reason, as it works for the first run, but does not for the second. To get an overview: One Test case, where the same steps are run a second time. Presses a button natively to open a webview, navigates through a form setting the fields, submits, does a purchase, all while switching between native and web context for each input, then dismisses the WebView. And then repeats the same steps. Goes trough up to until this issue happens. Edit: Anyway i will try setting those attributes described there and will report back. |
|
I can reproduce the alert/text issue reliable, but I am not sure if that is related to this StaleElementReferenceError: it basically happens when you close the webview without switching to native context beforehand Steps to reproduce: Run app with appium inspector, open webview, switch context to webview, close webview, see server log |
|
I managed to get StaleElementReferenceError with the example project here. Create a test case where you
repeat steps 1-7 in a loop AppiumLocator webViewButtonLocator = new AppiumLocator(AppiumLocatorStrategy.XPATH, "//XCUIElementTypeStaticText[@name=\"OPEN WEBVIEW\"]");
ui.withLocator(webViewButtonLocator)
.whenClickableAfter(MobileConfig.getTimeoutConfig().tiny())
.clickIt();
ui.pause(MobileConfig.getTimeoutConfig().shorter());
String contextName = ui.getContextHandles().stream().filter(c -> c.startsWith("WEBVIEW")).findFirst().get();
ui.context(contextName);
AppiumLocator frameLocator = new AppiumLocator(AppiumLocatorStrategy.CSS, "iframe");
ui.withLocator(frameLocator)
.switchToFrame(MobileConfig.getTimeoutConfig().tiny());
AppiumLocator identifierLocator = new AppiumLocator(AppiumLocatorStrategy.CSS, "#identifier");
ui.withLocator(identifierLocator)
.whenVisibleAfter(MobileConfig.getTimeoutConfig().tiny())
.getText();
ui.context("NATIVE_APP");
AppiumLocator closeButtonLocator = new AppiumLocator(AppiumLocatorStrategy.XPATH, "//XCUIElementTypeButton[@name=\"Close\"]");
ui.withLocator(closeButtonLocator)
.whenClickableAfter(MobileConfig.getTimeoutConfig().tiny())
.clickIt(); |
|
thanks @ilendemli a repro is useful. the investigation/solution might take some time as there is a lot of updating work that needs to be done on the remote debugger code and the selenium atoms. |
|
Can you try setting your |
mykola-mokhnach
added
Bug
|
Sorry for the late response, we were in the process to move everything to Appium 2. We now have a Selenium Grid 4 running with Appium 2 and we still have the issue. |
Have you discovered a solution to the problem you've described? I've been encountering the same issue for a while and haven't been able to find a resolution or workaround. |
|
Same issue here! |
Do I have the most recent component updates?
Is the component officially supported by the Appium team?
Is there an existing issue for this?
Current Behavior
For some reason, after quickly switching back and forth between the NATIVE_APP and WEBVIEW context (doing getContexts before switching) in our test cases, locating elements fail because of StaleElementReferenceError.
getPageSourcefails withMethod threw 'org.openqa.selenium.WebDriverException' exception.The webpage is shown in a hybrid app. It is inspectable through Safari.
Expected Behavior
Getting Element after switching context to WEBVIEW should not fail.
Minimal Reproducible Example
I have no example to provide at the moment but will try to create one to reproduce the issue.
Environment
appium --version): 2023.5.2node --version): 20.2.0npmversion (output ofnpm --version): 9.6.6Link to Appium Logs
No response
Futher Information
No response
The text was updated successfully, but these errors were encountered: