What does the 'autoWebview' desired capability "really" do?

This option seems to trigger webview context on HTC with android 4.4 but not other phones.

Anybody knows why?

Is there a different automation package on those phone that would allow webview access without setting “automationName”: “selendroid”?

It would help to have more details on what this desired capability does.

Thanks a bunch.


The autoWebview desired capability is just a simple shortcut provided for interacting with Webviews in Hybrid apps.

When you are using appium, you normally operate in something called the Native Context. When in the native context, you use all the regular appium commands to interact with the native elements of the mobile UI.

If the UI contains any embedded webviews, there are other contexts available. You can see all the available contexts by calling the contexts() method provided by your appium client.

This call typically yields a list of contexts like this:


If you want to automate parts of the UI which are inside the webview, you need to tell appium to switch contexts to the webview. setContext("WEBVIEW_1")

Once set to a Webview Context, all commands sent by your test will apply to elements inside the webview, instead of elements which are part of the native UI.

In a Webview context, you can use regular Selenium commands, like get('http://example.com') or CSS selectors for locating elements.

If you want to control part of the Native UI again, you need to return to the Native Context setContext("NATIVE_CONTEXT").

For projects which are testing Hybrid Apps, which are basically 100% webview apps, it can be inconvenient to remember to switch to using the Webview Context before every test. Sending the autoWebview capability tells appium to automatically switch to the WEBVIEW_CONTEXT as soon as the test starts. Appium adds some additional logic for waiting until the webview has loaded, which can be a common source of errors.

Recently, in the master branch of appium, we have added a feature that sends some appium commands to the Native context, even when you are in a Webview. For example: chromeDriver does not support changing orientation, so sending an Orientation command when you are inside a webview will not work. Rather than making you switch to the Native context and back to the Webview context, appium now automatically forwards the Orientation commands to the Native context.

As a separate issue:

You should not be setting automationName:"selendroid" you definitely want the default automation to be used. For android 4.4, the chromeDriver is used to automate webviews. Selendroid is only used for older versions of Android.


Thanks very for the detailed explanation. It was very helpful.

I guess I’m still wondering why a webview context would be available on HTC api19 and not other devices (according to the return response of the contexts() method). Could it be that setWebContentsDebuggingEnabled is enabled by default on the HTC?

Thanks again.

That could be it, or it’s possible that the phone is running some background activity that has a webview. There’s a lot of funky things that happen across different device vendors…

What do you mean by “contexts() method provided by your appium client”? What is the class of that method? I tried driver.contexts()

Every language implements appium api endpoints differently, and the names are different.
Examples for each language are provided in the documentation:

Thanks. But I don’t find any code examples there. But after poking around I found this page: http://appium.io/slate/en/master/?ruby#automating-hybrid-ios-apps. What it says there is at the bottom of this post.

It says to make GET and POST calls, but the sample code on the right of the page shows this call being made:

However, my instantiation of AppiumDriver does not include that method.

Is there a capability I need to set first?

**** URL content
One of the core principles of Appium is that you shouldn’t have to change your app to test it. In line with that methodology, it is possible to test hybrid web apps (e.g., the “UIWebView” elements in an iOS app) the same way you can with Selenium for web apps. There is a bit of technical complexity required so that Appium knows whether you want to automate the native aspects of the app or the web views, but thankfully, we can stay within the WebDriver protocol for everything.

Here are the steps required to talk to a web view in your Appium test:

Navigate to a portion of your app where a web view is active
Call GET session/:sessionId/contexts
This returns a list of contexts we can access, like ‘NATIVE_APP’ or ‘WEBVIEW_1’
Call POST session/:sessionId/context with the id of the context you want to access
(This puts your Appium session into a mode where all commands are interpreted as being intended for automating the web view, rather than the native portion of the app. For example, if you run getElementByTagName, it will operate on the DOM of the web view, rather than return UIAElements. Of course, certain WebDriver methods only make sense in one context or another, so in the wrong context you will receive an error message).
To stop automating in the web view context and go back to automating the native portion of the app, simply call context again with the native context id to leave the web frame.

BTW, I am using java-client-1.3.0.jar

Tried 1.6.2 as well. There are many methods in the sample code on the right side of the page at http://appium.io/slate/en/master/?java#appium-client-libraries that I don’t have after building with java-client-1.6.2

MY BAD: I had instantiated a WebDriver object, not an AppiumDriver object!!

But now that I am instantiating an AppiumDriver object, I am getting this error:
java.lang.UnsupportedClassVersionError: io/appium/java_client/AppiumDriver : Unsupported major.minor version 51.0

Fixed by installing Java 1.7.0_67

1 Like

In my case …I am Automating Hybrid iOS Application Using Appium.
But when I am trying to Click on a Button To Navigate On Next Screen its
not Working Properly as it is supposed to Load Next Screen.
Next Screen to be Loaded is PDF Viewer Screen.


  1. While Attempting Same Scenario Manually(Without Opening
    Application through Appium Inspector or Appium Server) its working fine.
  2. I can see data fetching from server on Appium Console too.


What I found worked for Android devices was this:

js.executeScript("$(’# pageElement .elementClassName’).trigger(‘touchstart’)");

I’m running into the same problem using cordova. Have you resolved this issue?

Is this what are you looking for

mActivity.loadUrl("javascript:(function(){" +
                        "l=document.getElementById('page1');" +
                        "e=document.createEvent('HTMLEvents');" +
                        "e.initEvent('click',true,true);" +
                        "l.dispatchEvent(e);" +