Introduce ThreadedInputConnection behind a switch

content/public/android/java/src/org/chromium/content/browser/input/InputMethodManagerWrapper.java

Index: content/public/android/java/src/org/chromium/content/browser/input/InputMethodManagerWrapper.java
diff --git a/content/public/android/java/src/org/chromium/content/browser/input/InputMethodManagerWrapper.java b/content/public/android/java/src/org/chromium/content/browser/input/InputMethodManagerWrapper.java
index 6a26dbc9c6c65082496000c280bbe6bbbf5e5713..673a3740925a1196b1510e37e49277531ec95aec 100644
--- a/content/public/android/java/src/org/chromium/content/browser/input/InputMethodManagerWrapper.java
+++ b/content/public/android/java/src/org/chromium/content/browser/input/InputMethodManagerWrapper.java
@@ -15,6 +15,9 @@ import android.view.inputmethod.InputMethodManager;
 
 import org.chromium.base.Log;
 
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
+
 /**
  * Wrapper around Android's InputMethodManager
  */
@@ -88,4 +91,23 @@ public class InputMethodManagerWrapper {
             getInputMethodManager().updateCursorAnchorInfo(view, cursorAnchorInfo);
         }
     }
+
+    /**
+     * Notify that a user took some action with the current input method. Without this call
+     * an input method app may wait longer when the user switches methods within the app.
+     */
+    public void notifyUserAction() {
+        // On N and above, this is not needed.
+        if (Build.VERSION.SDK_INT > Build.VERSION_CODES.M) return;
+        Log.d(TAG, "notifyUserAction");
+        InputMethodManager manager = getInputMethodManager();
+        try {
+            Method method = InputMethodManager.class.getMethod("notifyUserAction");
+            method.invoke(manager);
+        } catch (NoSuchMethodException | IllegalAccessException | IllegalArgumentException

[palmer, 2016/02/25 23:49:55]

These are all subclasses of RuntimeException, right? You could just catch that
type to make the code more general and perhaps to catch more types of errors,
should they happen. (One the other hand, maybe you'd definitely want the
application to die in that case. I don't know.)

Also, if such an exception does happen, doesn't that mean something very odd
about the platform is happening? That is, if there is an InputMethodManager that
doesn't provide a notifyUserAction method, is it a super broken IMM? Maybe log
it more verbosely, or UMA it...? I dunno, maybe it doesn't matter.

Anyway, no action required; just a thought.

[Changwan Ryu, 2016/02/26 02:41:19]

Hmm... I think it is a matter of readability and discoverability of hidden
condition vs. general stability. I personally prefer exceptions to be stated
explicitly to understand the risks better.

+                | InvocationTargetException e) {
+            Log.d(TAG, "notifyUserAction failed");
+            return;
+        }
+    }
 }