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
Related
I have installed on my android device (V 5.1.1) two package for Android System WebView:
com.android.webview
com.google.android.webview
I'm trying to use the second package, following different ways, deactivating or uninstalling (impossible) first, and now I want to force the second when I load my WebView directly by code.
Do you know any solutions?
PS: I know and in other cases, I'm used CustomTabs, but in this case, I can't Chrome or Chromium on my device.
Seems there is no way to change default WebView client without root on devices. Please check this answer.
I have a problem when using Xamarin.Forms in conjunction with Prism.Forms (Unity) on an Android 5.1.1 (Lollipop) device.
Specifically, if I navigate to/from forms with "animation: true" those forms do not always work correctly afterward - specifically, the forms are not always updated in response to a PropertyChanged event. The forms work perfectly on Android 6.0 and 7.1 (the only other devices I have available for testing).
If I change all of my calls to INavigationService.NavigateAsync so that "animation" is false, those forms behave properly as long as I do not use the hardware "back" button to exit a form (as this then animates again). I have even created an override of the "UnityPageNavigationService" that overrides the "animated" parameter on calls to "DoPop", "DoPush" and "GoBackAsync" (I am pretty sure that the NavigateAsync method eventually calls one of these for all requirements except in the case of changing the content of a MasterDetailPage).
I am pretty sure that this is a Xamarin problem and not a Prism
problem as having looked through the code on GitHub it appears to me
that the Prism INavigationService implementation eventually comes back
to the Page.Navigation.PushAsync(...) etc. methods and I am also
pretty sure that the Prism navigation service is not intercepting the
back button and interacting with it.
Is there any way to disable the animations when navigation is
instigated by the hardware back button?
Is there a way to override the INavigation implementation for a platform (obviously Android in this instance)?
Is there a known issue and/or work-around here for Xamarin Forms on
Lollipop 5.1.1?
I am using Xamarin Forms 2.3.4.231, Prism.Forms 6.3 and Prism.Unity.Forms 6.3.
I eventually resolved this and it was nothing to do with Prism Navigation nor Xamarin.Forms but was instead caused by the element of the AndroidManifest.xml not being the first child of the element.
I had sorted the children of the element alphabetically making the last element and this broke it (though not on later versions of Android).
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.
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
My app has a WebView and I want to configure it to use a proxy. Apparently Android doesn't have an API that I can use to achieve this but I found some a couple of articles on StackOverflow showing how to do it via reflection:
WebView android proxy
Android WebView set proxy programmatically on Android-L
Unfortunately the methods in the first article only work up to KitKat 4.4 and the Android L/5.0 way of doing it requires setting the application-wide proxy settings (via System.setProperty("http.proxyHost", ...) and System.setProperty("http.proxyPort", ...) which affects more than just the WebView. For example, the Apache HTTP client seems to pick up these settings too.
Is there a way to set proxy settings just for WebViews without affecting other components of the app?
In API>21 lollipop, it does not allow setting proxy settings in webviews. The methods have been removed.
So the only way now is to set system wide proxy as you mentioned, then clear the proxy on onPause and onStop methods of your activity.
The clear can be done by:
System.clearProperty("http.proxyHost");
System.clearProperty("http.proxyPort");
Hope you find this helpful.