Closed simongilmurray closed 5 years ago
The actual element visibility value is returned by XCTest. I don't think there is anything that can be done on Appium side there. Just do not work with web views in native context
The actual element visibility value is returned by XCTest. I don't think there is anything that can be done on Appium side there. Just do not work with web views in native context
But this has worked fine for all versions previously, it is just an issue since iOS12.
Each iOS version uses different SDK, which may affect these attribute values.
Installed the appium@beta via CLI as per @imurchie recommendation.
Result appears to be the same, elements are visible: false and can't interact with them via Accessibility iD.
Other people having the same issue on Appium discuss and Gitter.
Can anyone look in to this please? Currently breaking existing automation.
https://discuss.appium.io/t/having-problems-scrolling-to-offscreen-items-with-1-9-1/23848
The scrolling operation in WebDriverAgent is a hacky feature, which uses a lot of private APIs and some black magic, like visibility detection. This API is not documented anywhere and officially does not exist, so Apple is not going to support that.
Fixes in this area usually require to perform reverse engineering and are very expensive effort- and timewise.
You could either try to dig deeper into the topic yourself or hire a consultant, who is capable to do the necessary changes in the framework. Good luck with that
Mykola, the issue isn't with the scrolling operation. The issue is that the visible flag on elements has changed since iOS12 and now comes back as false when it should be true.
Is anyone else able to assist please?
https://github.com/appium/WebDriverAgent/blob/master/WebDriverAgentLib/Categories/XCUIElement%2BFBIsVisible.m - just that you can understand the level of complexity
Not sure if this helps. This issue has been causing numerous headaches for me as well. I'm actually seeing items with a visible state false on page load. I manually click on the item in simulator so that the item is selected and the visible state remains false. On the scroll I think there could be something within Appium. When I use @driverAppium.execute_script('mobile: scroll', name: element.name) the visible state does not change to true but if I manually scroll the visible state will change:
set binging.pry find_element(name: element).displayed? This will return false manually scroll in the simulator find_element(name: element).displayed? This will return true
I am also facing the similar issue unable to find the Web-view elements on the latest Appium version , Xcode 10 , OS 12 .Looking for some workaround please ?as my scripts execution starts with web elements .
I'm experiencing the same issue with my hybrid app in NATVIE context. Appium returns 200 but no action really takes place. Everything worked fine with Xcode 9.4.1 and Appium 1.8.1. And just to clarify, these elements had the same visibility attributes ('false') in 1.8.1 as well as previous versions. A workaround that worked for me was to downgrade XCUITestDriver to v2.84.0.
So my current setup looks like this: Appium 1.9.1 XCUITestDriver v2.84.0 Java Client 6.0.1 Xcode 10
Thanks for the info Pdubzzz, hopefully it can be fixed going forwards so we don't have to downgrade though.
We also face these problems in the native context, especially in combination with XCUIElementTypeCell. I face the issue with appium@1.9.1 and also 1.9.2-beta.2.
@Pdubzzz: How do you selectively downgrade a dependency via npm?
I am also intrigued by the fact that the PageSource shows visible=false (for the first XCUIElementTypeCell) and the inspector shows isVisible=true. Does this difference make any sense or can you rework this to use the logic of the inspector in an easy way?
@lanzelot1989 I've had to do it manually, by going to ".../npm-global/lib/node_modules/appium/node_modules/appium-xcuitest-driver" with Appium 1.8.1 installed, copying appium-xcuitest-driver folder and saving it elsewhere. Then installing Appium 1.9.1 and replacing the appium-xcuitest-driver folder with the one you saved previously. I'm sure there is a better way to do this, but this worked for me.
@Pdubzzz Oh, I get it. The good old "save-away-and-replace" :-D, as I stated I had a nifty npm command in mind. I'll try that workaround first thing in the morning on Monday, thanks a lot.
who can tell me what happened when I use inspector to get page source as the pic shows.Nothing to show and it keeps loading
@Pdubzzz I have replaced my appium xcuitest driver to 2.84.0 but when i tried to open appium desktop application (1.7.1) its throwing error ( A javscript error occured in the main) and i am unable to launch appium with 2.84.0. Please help in this.
@prateeksomani try deleting old xcuitest driver (instead of renaming it)
And just FYI, above will only fix the appium desktop client and will allow you to use inspector again.
If you are starting your selenium server through command line you would also need to replace xcuitest driver inside of the npm-global folder: (eg."/Users/
@Pdubzzz I have tried that way also . I have deleted the old one and replaced it by 2.84.0.Also i am using appium desktop client only and not invoking appium through command line. Still i am getting same error. @simongilmurray is it working for you i am getting below error in ios 11.1
@prateeksomani Ok, I did some more digging and tried to download xcuitest driver 2.84.0 from git and got the exact same error:
Can you try installing a previous version of desktop client that worked for you and copying the xcuitest driver folder from there?
Closed as third party issue
I love when things that make Appium unusable are closed as third party. Does anyone think to maybe reference the third party issue rather than just close. Basically I'm dead in the water using Appium in this situation. I tried to find a valid workaround. Kind of irks me every time I see this on something that blocks me.
@mthompsonpop have you tried the workaround I've posted above by downgrading version of xcuitest driver? It seems that I'm the only person who was able to use this method successfully. Perhaps if there will be more reports of this workaround being a viable solution, Appium contributors can look into this issue more and/or downgrade xcuitest driver in the next version of Appium?
I did try. Didn't work for me but granted I didn't spend lots of time on it. I have plenty of other things to do and just bypassed this because it wasn't in my code. I had already spent too much time on it. My comment was more to give me something I can watch so when it works I can utilize the fix rather than just close it and leave everyone with no solution.
I love when things that make Appium unusable are closed as third party. Does anyone think to maybe reference the third party issue rather than just close. Basically I'm dead in the water using Appium in this situation. I tried to find a valid workaround. Kind of irks me every time I see this on something that blocks me.
Totally agree on this, how can you be closing this issue? It has broken entire suites of automation as it has changed the way Appium interacts with the app.
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.
The problem
Previously before iOS 12, when interacting with webviews, elements would come back as enabled: true and visible: true. Now that we have upgraded to XCode10 and iOS12, elements inside a webview are coming back as enabled: true but visible: false...so I am unable to interact with them via the Accessibility ID as we have done previously. Have chatted about this in Gitter discussion and it seems to be affecting other users also.
Environment
Details
Unable to interact with webview elements as the visible flag is coming back as false since iOS12.
Link to Appium logs
-
Code To Reproduce Issue [ Good To Have ]
Example:
.waitForEnabled("~Auto-Load", 30000) .element("~Auto-Load").click()
This worked previously, but now it does nothing.