InputMethodManager: Display ID mismatch found

[svillar]

We've been getting InputMethodManager errors since I remember. They don't seem to affect negatively Wolvic but it's worth investigating. This is the trace

W/InputMethodManager: b/117267690: Display ID mismatch found. ViewRootImpl displayId=498 InputMethodManager displayId=0. Use the right InputMethodManager instance to avoid performance overhead.
    java.lang.Throwable
        at android.view.inputmethod.InputMethodManager.getFallbackInputMethodManagerIfNecessary(InputMethodManager.java:552)
        at android.view.inputmethod.InputMethodManager.restartInput(InputMethodManager.java:1594)
        at android.widget.TextView.setText(TextView.java:6169)
        at android.widget.TextView.setText(TextView.java:6102)
        at android.widget.EditText.setText(EditText.java:122)
        at mozilla.components.ui.autocomplete.InlineAutocompleteEditText.setText(InlineAutocompleteEditText.kt:272)
        at android.widget.TextView.setText(TextView.java:6054)
        at androidx.databinding.adapters.TextViewBindingAdapter.setText(TextViewBindingAdapter.java:80)
        at com.igalia.wolvic.databinding.NavigationUrlBindingImpl.executeBindings(NavigationUrlBindingImpl.java:2720)
        at androidx.databinding.ViewDataBinding.executeBindingsInternal(ViewDataBinding.java:473)
        at androidx.databinding.ViewDataBinding.executePendingBindings(ViewDataBinding.java:445)
        at androidx.databinding.ViewDataBinding$7.run(ViewDataBinding.java:197)
        at androidx.databinding.ViewDataBinding$8.doFrame(ViewDataBinding.java:291)
        at android.view.Choreographer$CallbackRecord.run(Choreographer.java:965)
        at android.view.Choreographer.doCallbacks(Choreographer.java:791)
        at android.view.Choreographer.doFrame(Choreographer.java:722)
        at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:952)
        at android.os.Handler.handleCallback(Handler.java:886)
        at android.os.Handler.dispatchMessage(Handler.java:102)
        at android.os.Looper.loop(Looper.java:227)
        at android.app.ActivityThread.main(ActivityThread.java:7436)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)

[javifernandez]

The root cause of these exceptions is the fact that we use an virtual display, implemented in our OffscreenDisplay class, for the widgets that are part of the BrowserWindow and dealing with the GeckoView component.

The InputMethodManager instance is created by the VRBrowserActivity instance via the getSystemService API and associated to it as a Context subclass (see NativeActivity.onCreate for details). When this instance is created, it receives the display form the context that requires it; in our case the VRBrowserActivity.

Every time a TextView derived class (eg, the NavigatorURLBar's urlTextEdit view) performs an operation, the previously registered InputMethodManager instance is used to perform the operation. The InputMethodManager class is implemented to support multiple displays, but it has some checks to ensure the View instance that requires it has the same displayId than the one it's associated to.

As I commented before, some widgets are associated to an offscreen display, but their context's is still the one provided by the VRBrowserAcvitity, which is the default display (displayId 0).

I'm not sure there is an easy way to avoid this exception, which in any case it's just informative. The fallaback (the one associated to the view's context) InputMethodManager will be provided, even if the displayIds don't match.

[HollowMan6]

Investigated this a little bit. The code that generates this exception originated from here:
https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/view/inputmethod/InputMethodManager.java;l=537-538;drc=54a709b513872269ddc36caa4d1eb3f8c6c861e2;bpv=1;bpt=0

Since we use VirtualDisplay, "Use the right InputMethodManager instance to avoid performance overhead." here doesn't apply to us at all. We will need to have a distributor to transfer the events that are collected from the VRBrowserActivity context to the corresponding widget context that uses a different virtual display anyway. Even if we decide to implement something here by ourselves, we will just do similar things, so I don't think we need to do anything here.

In addition, I find that Flutter also has this issue when using Virtual Displays, so this is a general problem. flutter/flutter#90207 (comment) If there should be a fix, I would say the Android side should implement something instead so that it stops giving this exception when it finds that the view's display is actually a virtual one.

[svillar]

Fair enough, I think @javifernandez and @HollowMan6 provided a quite good rationale. Thanks

I'll close as wontfix