There needs to be some documentation around the intended behavior of interacting with webview elements on android.
I’ve been testing against a Nexus 5 with 4.4.2 and a Nexus 5 with 4.4.4. The xpath for elements when running against 4.4.4 reference WebView names, but on 4.4.2 they reference what look like native widget names. From my perspective the xpath names should not be changing regardless of android version.
4.4.2 example //android.view.View[2]/android.widget.Button[1]
4.4.4 example //android.view.View[1]/android.webkit.WebView[2]/android.view.View[1]/android.widget.Button[1]
How is chromedriver involved in this process?
I’d really like to understand what’s going on here and what the expected xpath naming convention should be so I can correctly write my test harnesses and file bugs.
I’ve also ran into situations where the appium inspector won’t show any information at all for webviews.
We need better webview automation examples, in my case python specifically.
Somehow I’ve partially automated webview testing without switching to webview context (except for the fact that UI navigation sporadically breaks for a while and then suddenly start working again).
My app has lots of fragments and activities that use webviews. Is there a global webview context, or would each webview be different and require restarting chromedriver several times?
On top of that I’ve never yet had chrome driver start successfully, and the appium server log doesn’t have any useful information.
Sorry to hear you’re having issues with contexts. I’ve been doing some testing with them in the last couple days with good success, so hopefully we can unblock you.
When is the appium GUI going to be updated for mac os x? It’s a critical tool for allowing our less technical users (QA team) write automated tests without knowing all the details of the code. They need the inspector to discover resource-id and/or xpath information. We’re stuck on 1.2.1 as the last working build of appium GUI (1.2.2 had send_keys issues on android).
I’m still at a loss for WHY context switching is supposedly required. If I can already access and manipulate webview widgets without it, why do I need it?
Why would xpaths change between different versions of android? Same apk.
Can you provide some initial feedback on these questions rather than just trying to get me to run the latest appium version? I expect my current tests will continue to work, but that’s not answering these fundamental questions. Maybe this issue is somehow specific to the python bindings? How easy/hard are executing the js tests?
Apologies I came across as just trying to get you to use the latest Appium version, that wasn’t my intention. I was trying to help you move forward by removing static (eg, bugs that might distract us from problems you’re experiencing) and provide links to some examples as you requested on GitHub. I’m hoping that will put you on firmer footing
You ask some great questions.
I do not know the timing on the OSX GUI. That project is maintained separately from the Appium server. I asked the maintainer and will let you know if I hear anything. You can also inquire here: https://github.com/appium/appium-dot-app. The Appium ecosystem is open source, so if you’re able, I encourage you or your employer to contribute to updates, esp if it’s business critical.
A “context” is a metaphor used as an abstraction for views. The context-switching API provides a way for Appium to target different views regardless of their visibility. In a hybrid app, this allows you to send commands or query the native view or the web view, regardless of which is displayed. In an app where there are multiple webviews/webframes displayed at the same time (eg, a web page with iframes), then you may have multiple contexts visible at the same time. In the former case, the context API is the only means to switch focus between views. In the latter case, there may be more than one way to switch focus between views.
Regarding “How is chromedriver involved in this process?”, I’m not exactly certain what the antecedent for “this” is, though I’m guessing you mean the generation of XPaths. Unfortunately, I’m not very familiar with the chromedriver code–it’s part of the Chromium project. It’s effectively a “black box” as far as Appium is concerned. We send it JSONWP queries and it responds. Afaik, the XPaths are generated by the browser itself.
Some people recommend avoiding XPaths on Android, but that’s a (very unsatisfying) non-answer to your question. I’ll do some more research and update the thread if I get additional info.
As for why the XPaths should change, there are a few reasons.
You need to ensure compression is enabled for XPath to work properly (you can control this in Appium 1.2.3).
Google may change how items are rendered between API versions.
There may be a bug in Appium’s component chain (eg, chromedriver) or in Appium itself.
If you want a deeper understanding, I encourage you to to ask the chromedriver community as well and let us know what you find out.
Great. Maybe I can help build the dmg if they need assistance!
As far as contexts I understand this is the intended use of context switching. The biggest question for me is why can I automate webviews without switching context? It seems this renders context switching unnecessary. Can you see my confusion here? In theory these widgets can’t be accessed via UIAutomator and that’s why chromedriver is supposed to be required for webview automation?
Okay, so instead of issuing UIAutomator commands, once context is switched appium sends these JSONWP requests to chromedriver? Seems reasonable, but also seems unnecessary per my comments in 2). As far as using xpath, right now it seems to be required for various widgets that don’t have text that can be searched for and aren’t specifying resource-ids. I’d love to avoid using xpath altogether and I’m trying to find ways not to.
So the XPath information is provided by UIAutomator in the native context? I wonder why this would change between android versions. Specifically if you refer to the post I referenced previously it seems the layout of the XPath is the same, but webview elements on android 4.4.2 seem to use the same format as native widgets, but in 4.4.4 they actually specify ‘webview’ and ‘webkit’ and appear to use a format that allows the user to tell they are webviews. Maybe this was intentional to make it clearer when navigating the UI?
How is this xpath compression setting controlled? Something in the capabilities?
The main problem with chromedriver is it’s never successfully started and there’s never anything useful in the appium server log.
May I suggest using relative xpath instead of using an absolute xpath as you are doing. Relative xpath is more robust and simple changes in the layout or changes from Google side won’t break the test. I am relying on relative xpath in all my webview tests and they are working fine
The only problem now is that relative xpath is working only in webview context. Any idea if such feature would be implemented in the native context any time soon??? I am relying on ID or class name in native context as a workaround until a more robust locator is implemented.
Okay, so I finally had a chance to attempt to switch context to webview using appium 1.2.4 on nexus 5 running both 4.4.2 and 4.4.4. Both failed with (unhelpful?) output:
error: Chromedriver create session did not work. Status was 200 and body was {“sessionId”:“a5f313acba6c874cfd1a52763a52faf4”,“status”:100,“value”:{“message”:“chrome not reachable\n (Driver info: chromedriver=2.10.267517,platform=Mac OS X 10.9.5 x86_64)”}}
info: [debug] Responding to client with error: {“status”:13,“value”:{“message”:“An unknown server-side error occurred while processing the command. (Original error: Did not get session redirect from Chromedriver)”,“origValue”:“Did not get session redirect from Chromedriver”},“sessionId”:null}
info: <-- POST /wd/hub/session/34a2dfc3-678f-4a93-b53a-fe3b15158d4c/context 500 61471.250 ms - 246
I have been playing with appium for the past few days. I too am able to access the elements inside a web view without actually switching contexts, infact as soon as i switch contexts those elements are no longer visible. The question here is that my app has opened a webview and displays three different contexts, two of which are WEBVIEW contexts . so i dont understand why i can access those elements without even switching contexts.I wanted to know if you were able to get a clear understanding as to why this was happening, if so you could maybe explain the reasoning behind this.
I finally no longer feel alone in the world!! I test on a bank of android devices, mixed between 4.4.2 and 5.x. I seriously thought I was going insane. I would get locators from the inspector from one device only to discover that they didn’t work on across identical devices! They of course weren’t identical. The difference was android OS version.
I found that ‘native’ xpaths work in webviews on versions 4.4.2 and earlier but don’t in subsequent versions. I suspect this change was introduced in 4.4.3 (see here).
I don’t have a good solution but wanted to let you know there is one more person the universe pulling their hair out over this.
