WebView hides soft keyboard during loadUrl(), which means a keyboard cannot stay open while calling javascript

Question

Since the way you call javascript on a WebView is through loadUrl("javascript: ... "); The keyboard cannot stay open.

The loadUrl() method calls loadUrlImpl() , which calls a method called clearHelpers() which then calls clearTextEntry(), which then calls hideSoftKeyboard() and then we become oh so lonely as the keyboard goes away.

As far as I can see all of those are private and cannot be overridden.

Has anyone found a workaround for this? Is there a way to force the keyboard to stay open or to call the javascript directly without going through loadUrl()?

Is there anyway to override the WebView in a way to prevent (the private method) clearTextEntry() from being called?

Answer 1

I could implement cottonBallPaws's idea to use the internals of WebView with reflection, and got it to work for my 4.2 device. There are gracious fallbacks for Android versions older than KitKat.

The code is written in Xamarin, but it should be easily adaptable to native Java code.

/// <summary>
/// Executes a JavaScript on an Android WebView. This method offers fallbacks for older
/// Android versions, to avoid closing of the soft keyboard when executing JavaScript.
/// </summary>
/// <param name="webView">The WebView to run the JavaScript.</param>
/// <param name="script">The JavaScript code.</param>
private static void ExecuteJavaScript(Android.Webkit.WebView webView, string script)
{
    if (Android.OS.Build.VERSION.SdkInt >= Android.OS.BuildVersionCodes.Kitkat)
    {
        // Best way for Android level 19 and above
        webView.EvaluateJavascript(script, null);
    }
    else
    {
        try
        {
            // Try to do with reflection
            CompatExecuteJavaScript(webView, script);
        }
        catch (Exception)
        {
            // Fallback to old way, which closes any open soft keyboard
            webView.LoadUrl("javascript:" + script);
        }
    }
}

private static void CompatExecuteJavaScript(Android.Webkit.WebView androidWebView, string script)
{
    Java.Lang.Class webViewClass = Java.Lang.Class.FromType(typeof(Android.Webkit.WebView));
    Java.Lang.Reflect.Field providerField = webViewClass.GetDeclaredField("mProvider");
    providerField.Accessible = true;
    Java.Lang.Object webViewProvider = providerField.Get(androidWebView);

    Java.Lang.Reflect.Field webViewCoreField = webViewProvider.Class.GetDeclaredField("mWebViewCore");
    webViewCoreField.Accessible = true;
    Java.Lang.Object mWebViewCore = webViewCoreField.Get(webViewProvider);

    Java.Lang.Reflect.Method sendMessageMethod = mWebViewCore.Class.GetDeclaredMethod(
        "sendMessage", Java.Lang.Class.FromType(typeof(Message)));
    sendMessageMethod.Accessible = true;

    Java.Lang.String javaScript = new Java.Lang.String(script);
    Message javaScriptCodeMsg = Message.Obtain(null, 194, javaScript);
    sendMessageMethod.Invoke(mWebViewCore, javaScriptCodeMsg);
}

Answer 2

Regarding older APIs (pre 19), I used a similar method to the excepted answer, but slightly different.

First, I keep track of if the keyboard is displayed by using javascript in the webview roughly like so:

document.addEventListener( "focus", function(e){        
    var el = e.target;
    reportKeyboardDisplayedToJava( isInputElement( el ) );
}, true);

document.addEventListener( "blur", function(e){        
    reportKeyboardDisplayedToJava( false );
}, true);

If the keyboard is displayed, and a js injection is attempted by the Android Java layer – I “defer” that injection. I add it to a string list, allow the user to finish up their input, and then upon the keyboard disappearing, I detect that and execute the backlog of injections.

Answer 3

Update

KitKat added a public method for invoking javascript directly: evaluateJavascript()

For older apis, you could try a solution like below, but if I had to do this again I'd look at just building an compatibility method that on KitKat uses the above method and on older devices, uses reflection to drill down to a inner private method: BrowserFrame.stringByEvaluatingJavaScriptFromString()

Then you could call javascript directly without having to deal with loadUrl and adding "javascript: " to the script.

Old Answer

As requested by Alok Kulkarni, I'll give a rough overview of a possible workaround I thought of for this. I haven't actually tried it but in theory it should work. This code is going to be rough and is just to serve as an example.

Instead of sending the calls down through loadUrl(), you queue your javascript calls and then have javascript pull them down. Some thing like:

private final Object LOCK = new Object();
private StringBuilder mPendingJS;

public void execJS(String js) {
    synchronized(LOCK) {
        if (mPendingJS == null) {
            mPendingJS = new StringBuilder();
            mPendingJS.append("javascript: ");
        }
        mPendingJS
            .append(js)
            .append("; ");
    }
}

Instead of calling loadUrl() call that method. (For making this simple I used a synchronized block, but this might be better suited to a different route. Since javascript runs on its own thread, this will need to be thread safe in some way or another).

Then your WebView would have an interface like this:

public class JSInterface {

    public String getPendingJS() {
        synchronized(LOCK) {
            String pendingCommands = mPendingJS.toString();
            mPendingJS.setLength(0);
            mPendingJS.append("javascript: ");
            return pendingCommands;
        }
    }

}

That returns a String with the pending commands and clears them so they don't get returned again.

You would add it to the WebView like this:

mWebView.addJavascriptInterface(new JSInterface(), "JSInterface");

Then in your javascript you would set some interval in which to flush the pending commands. On each interval it would call JSInterface.getPendingJS() which would return a String of all of the pending commands and then you could execute them.

You could further improve this by adding a check in the execJS method to see if a EditText field exists in the WebView and is in focus. If there is one, then you would use this queueing method, but if there wasn't one in focus then you could just call loadUrl() like normal. That way it only uses this workaround when it actually needs to.