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

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.