UiAutomator bug while inspecting WebView elements - android

I have recently started automation testing in android and was using UiAutomator tool for inspecting UI elements. Surprisingly, I came across two different responses for Webview elements for the same screen and same device [Genymotion MotoX 4.4.4]. Attached are the screenshots for the same. We all know that appium has an issue with inspecting webview elements who do not carry "setWebContentsDebuggingEnabled" to true. Is this a bug in UiAutomator?

We all know that appium has an issue with inspecting webview elements
who do not carry "setWebContentsDebuggingEnabled" to true. Is this a
bug in UiAutomator?
NO, its not a bug. Its an IMPLEMENTATION as is. Unless the setWebContentsDebuggingEnabled is set to true, you cannot debug or access any elements inside a webview.
To quote from developers.android.com
void setWebContentsDebuggingEnabled (boolean enabled)
Enables
debugging of web contents (HTML / CSS / JavaScript) loaded into any
WebViews of this application. This flag can be enabled in order to
facilitate debugging of web layouts and JavaScript code running inside
WebViews. Please refer to WebView documentation for the debugging
guide. The default is false.
You might be interested into these as well :
Migrating to WebView in Android 4.4

Related

Chrome Remote Debugging - how to inspect elements in hybrid app (webview)

I am trying to automate Gmail app for Android. In the "Compose" page, the part of the body of the message is a webview context. Using uiautomatorviewer i managed to retrieve the locator of the "body" element, but sending text to it - fails. Trying to switch context to "WEBVIEW" (i am using Appium) also fails. I wish to inspect elements in this page using chrome remote debugging. On my computer, i navigated to chrome://inspect/#devices and i launched the application on the android emulator. It looks alright.
But when i try to inspect elements, i see none.
What am i missing? (i made sure the to enable debugging and become a developer...)
To enable WebView debugging setWebContentsDebuggingEnabled should be set on the WebView class. You need to make this change in your app code and rebuild it.
Following these instructions was good enough for me

How can I get the layout xml from webDriver.io for android native app?

I'm using WebDriver.io to create tests.
In the Docs getSource doesn't support native apps.
Get source code of the page. This command won’t work in mobile
environments for native apps. If you are running hybrid tests make
sure that you are in the webview before calling this command.
For now, I use "client.source()" link which return the XML but can take up to 20 sec.
How can I get the layout XML from webDriver.io?
You are doing it the right way. Alternatively you can try the WD.js client and check if performance will be better with than the other one, or simply open an issue report on the WebdriverIO Github page.
The reason of why it may take so long:
UI of the app is constantly updating => Appium is hanging for a bit to retrieve it;
Lots of elements on your app page => leads to a big .xml file.

Android Webview caret disappears

I am in the process of testing a hybrid app for Android 4.4+. The app consists of
one custom plugin (my own effort)
the HTML UI created using Phonon.
Phonegap CLI v 6.4.2
My test device is a Huwaei Holly running Android 4.4.2
One of the issues I have run into is the fact that the caret in textarea and input controls stops working "after a while" and the soft keyboard does not popup when I tap the control.
By dint of some trial and error I pinned down the problem - it happens AFTER the app has displayed at least one vanilla HTML/JS alert box which I am using for my own debugging needs. Replacing that with a Phonon.alert box - which is simply an overlayed layer of HTML, not a new window as, I imagine, the bog standard alert is - "fixed" the problem.
Very good but the fact that this happens at all still bothers me - I will not use vanilla alerts in my release build but if it happened with alerts it might well happen with something else.
A spot of Googling revealed that is a known issue that appears to have been around for a while. This SO thread, for instance, suggests the Webview has to be set as being focussable and I have run into the same suggestion elsewhere too.
However, it is not at all clear to me just where I should do this. About the only configuration locations I have at my disposal are
The config.xml file for my Phonegap/Cordova project
The plugin.xml file for my custom Phonegap/Cordova plugin
The Phonegap docs related to config.xml do not mention anything about FrameworkLayout, android:focussable etc.
I'd be most grateful to anyone who might be able to either
explain just where the android:focussable bit should go or
suggest the root cause of the problem.

Android WebView accessibility in KitKat

I'm having some trouble getting TalkBack to work with a web view (testing with a Nexus 5 on Android 4.4.2). I read that TalkBack support was added to web views around the release of Android JellyBean by checking a preference titled "Enhance Web Accessibility." I can't for the life of me find this preference in the system settings.
Focusing on the web view in our application simply reads "WebView" and provides no other options. I've made sure and called getSettings().setJavaScriptEnabled(true); on the web view.
Was TalkBack support for web views removed in KitKat? If not, what am I missing here?
On 4.4, you need to have TalkBack/Explore by Touch enabled on the first run of your application. If you enabled it after that, it never seems to work. I figured this out by trial and error. I suspect scripts are being injected into your app/WebView on first launch to support it.
As an alternative, you could manually inject the ChromeVox scripts into your WebView and enable accessibility that way. Check out how the PhoneGap plugin does it - https://github.com/phonegap/phonegap-mobile-accessibility

How is 'reader mode' in Firefox triggered?

I'm using Firefox Mobile on an Android device and I'm fond of the 'Reader mode' features. However, the feature is not always available (e.g. Bash Guide).
So I'm looking for information on the mechanism of this feature, because it's still unpredictable.
Does it look for some semantic, #ids/#class values or something else ?
Firefox on Android uses readability.js as the basis for its "Reader Mode" support. Here is a content guide for making pages that are easy to extract content:
http://www.readability.com/developers/guidelines
The original readability code used in Firefox comes from:
http://code.google.com/p/arc90labs-readability/
Note that not all pages can be converted into Reader Mode, in fact, that's not the intention. If you come across a page that you think should be handled by Reader Mode, please file an issue in the github issue tracker:
https://github.com/mozilla/readability/issues
The developer of this features just reply via Twitter :
#edouard_lopez No docs, sorry. It finds for the main content of the
page based on a number of things (tag name, classes, id, etc).

Categories

Resources