1211848 - Android 6.0: Keyboard does not always show up if form control is selected

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: Keyboards and IME, defect)

Description

[Sebastian Kaspari (:sebastian; :pocmo)]

On my Nexus 5 (Android 6.0) the keyboard often does not show up if I select a form control.

This does not happen all the time but very often on Bugzilla or Persona login pages, e.g.:
https://bugzilla.mozilla.org/page.cgi?id=mydashboard.html (Not logged in!)

Usually the keyboard appears if the app is paused, resumed and I click into the form field again.

From observation it looks like if this is triggered when form fields are already focused on page load, but that's just a guess.

So far I only can reproduce it on my phone running Android 6.0 but in all versions of Firefox (Nightly, Aurora, Beta, Release).

Comment 1

[Sebastian Kaspari (:sebastian; :pocmo)]

Attachment: Screenshot: Bugzilla login - no keyboard

Comment 2

[Sebastian Kaspari (:sebastian; :pocmo)]

Attachment: Screenshot: Persona login - no keyboard

Comment 4

[Sebastian Kaspari (:sebastian; :pocmo)]

Seems like more users are having this problem with Android 6.0 (See duplicate).

Critical: It's in all versions (including release).

Comment 5

[Joe Walker [:jwalker]]

Looks to me like all text input fields with suggestions have no keyboard. Fields without suggestions seem to work ok.

Comment 6

[:Margaret Leibovic]

Sebastian, have you been looking into this? It sounds like it's important enough that we should start investigating before triage next week.

Comment 7

[Sebastian Kaspari (:sebastian; :pocmo)]

(In reply to :Margaret Leibovic from comment #6)
> Sebastian, have you been looking into this? It sounds like it's important
> enough that we should start investigating before triage next week.

No, not yet. But I can see if I can find what's causing this.

Comment 8

[Sebastian Kaspari (:sebastian; :pocmo)]

So far I do not have any idea what's causing this yet. Every selection of an input field is correctly delegated to GeckoInputConnection and from there we call into Android's InputMethodManager to show the soft keyboard. I also couldn't find any behavior changes in the changelog of InputMethodManager that might be related to that.

Comment 9

[donrhummy]

One extra piece of info:

* If it happens and won't come back up, turning off the device screen, turning it back on and unlocking the device will make it come back up (when you re-click in the form field)

The above is the ONLY thing that works. If I go into settings->apps->FF Beta and clear cache, force stop the app and restart, it still won't come back up. But turning the screen off, then on does allow the keyboard to show up again.

So something must be getting released when the screen's off that fixes the issue.

Comment 10

[Joe Walker [:jwalker]]

Comment passed on to me by someone else that has the problem:

> Something else that seems to release the keyboard is if you select from a drop-down box, the keyboard then functions for all the text boxes

Comment 11

[Sebastian Kaspari (:sebastian; :pocmo)]

My findings so far:

* The behavior on our side is not different on Android 6.0. All calls end up in GeckoInputConnection and are delegated to Android's InputMethodManager (showSoftInput, hideSoftInputFromWindow, restartInput).

* showSoftInput() returns a boolean. With some logging: On Android 6.0 we get false here when the soft keyboard is not shown.

* showSoftInput() also takes a ResultReceiver as optional parameter. The result receiver will be called with resultCode RESULT_UNCHANGED_SHOWN, RESULT_UNCHANGED_HIDDEN, RESULT_SHOWN or RESULT_HIDDEN. If they keyboard is not shown on Android 6.0 then the ResultReceiver is not called too.

* Looking at the source code of InputMethodManager.showSoftInput() the ResultReceiver might not be called because the method exits early (mServedView != view seems to be likely):

>    public boolean showSoftInput(View view, int flags, ResultReceiver resultReceiver) {
>        checkFocus();
>        synchronized (mH) {
>            if (mServedView != view && (mServedView == null
>                    || !mServedView.checkInputConnectionProxy(view))) {
>                return false;
>            }
> 
>            try {
>                return mService.showSoftInput(mClient, flags, resultReceiver);
>            } catch (RemoteException e) {
>            }
>             
>            return false;
>        }
>    }

* Following mServedView it seems to be set by focus events (via mNextServedView)

* Requesting to focus the view in GeckoInputConnection (requestFocus(), requestFocusFromTouch()) will show the keyboard on subsequent InputMethodManager.showSoftInput() calls. But never on the first one. (-> Touching the input field twice always shows the keyboard with this hack)

Comment 12

[Sebastian Kaspari (:sebastian; :pocmo)]

Some more observations:

If the keyboard does not show up then:

* InputMethodManager.isActive(view) returns false
* InputMethodManager.isActive() returns false too
* views.hasFocus() returns true

The view has focus but it is not set as view that is served by an input method. Basically anything that forces a clear focus and re-focus will fix that behavior.

Comment 13

[Sebastian Kaspari (:sebastian; :pocmo)]

Attachment: 1211848-keyboard-workaround.patch

This workaround fixes the issue on my Nexus 5.

GeckoInputConnection.showSoftInput(): If GeckoView has focus but is not the active view for the input method (InputMethodManager) then clear and re-request focus on the view.

Comment 14

[(inactive) Jim Chen [:jchen] [:darchons]]

Comment on attachment 8672645 [details] [diff] [review]
1211848-keyboard-workaround.patch

Review of attachment 8672645 [details] [diff] [review]:
-----------------------------------------------------------------

I'm okay with this being a workaround for Beta/Aurora. For Nightly, I think we should try finding the underlying cause.

Have you found what mServedView is in InputMethodManager? See if you can find it through reflection.

Can you check to see if removing the three lines here [1] changes anything?

[1] http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/GeckoApp.java?rev=0b69d304f861#1986

Comment 15

[Sebastian Kaspari (:sebastian; :pocmo)]

(In reply to Jim Chen [:jchen] [:darchons] from comment #14)
> I'm okay with this being a workaround for Beta/Aurora. For Nightly, I think
> we should try finding the underlying cause.

Yeah. I wrote a little test app and could not reproduce the issue. So I guess we are triggering this somehow.

> Have you found what mServedView is in InputMethodManager? See if you can
> find it through reflection.

I guess it is null because isActive() returns false. But I'll double-check.

> Can you check to see if removing the three lines here [1] changes anything?
> 
> [1]
> http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/GeckoApp.
> java?rev=0b69d304f861#1986

Interesting! I'll definitely try that. :)

Comment 17

[Sebastian Kaspari (:sebastian; :pocmo)]

(In reply to Sebastian Kaspari (:sebastian) from comment #15)
> (In reply to Jim Chen [:jchen] [:darchons] from comment #14)
> > Have you found what mServedView is in InputMethodManager? See if you can
> > find it through reflection.
> 
> I guess it is null because isActive() returns false. But I'll double-check.

* showSoftInput() returns false
* isActive(layerView) returns false
* isActive() returns false
* mServedView is null
* mNextServedView is null

Only after forcing a new focus (for example pausing and resuming the application, or with the patch attached):

* showSoftInput() returns true
* isActive(layerView) returns true
* isActive() returns true
* mServedView is the layerview
* mNextServedView is the layerview


(In reply to Sebastian Kaspari (:sebastian) from comment #15)
> (In reply to Jim Chen [:jchen] [:darchons] from comment #14)
> > Can you check to see if removing the three lines here [1] changes anything?
> > 
> > [1]
> > http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/GeckoApp.
> > java?rev=0b69d304f861#1986

Unfortunately this does not change anything.

Comment 18

[Sebastian Kaspari (:sebastian; :pocmo)]

As per comment #14 I'm going to land the workaround to get this tested and uplifted asap. Leave-open to find and fix the underlying cause.

Comment 19

[Sebastian Kaspari (:sebastian; :pocmo)]

I've been trying to debug whats happening under the hood. But I can't access most of the interesting things in InputMethodManager and logs are disabled in release builds.

However there have been some focus related changes in InputMethodManager in Android 6.0:
https://github.com/android/platform_frameworks_base/commits/master/core/java/android/view/inputmethod/InputMethodManager.java

This one and the surrounding changes are in particular interesting:
https://github.com/android/platform_frameworks_base/commit/5f05965f546fa42750f1a8314f8a2da01fd6bfb4

I can't remember ever seeing this in Preview 1-3 so I expect this to be a late change.

Comment 20

[Gian-Carlo Pascutto [:gcp]]

Patch fixes the issue with Google Search on my Nexus 9 / Android 6.

Comment 21

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/020fbe794499

Comment 22

[Sebastian Kaspari (:sebastian; :pocmo)]

Comment on attachment 8672645 [details] [diff] [review]
1211848-keyboard-workaround.patch

Approval Request Comment

[Feature/regressing bug #]: -

[User impact if declined]: On Android 6.0 the soft keyboard often does not appear after selecting an input field (web content). This state persist until a re-focus has been forced (e.g. rotating the device or turning screen off/on). OTA updates for Android 6.0 are rolling out to Nexus devices and new Nexus devices with Android 6 are in stores.

[Describe test coverage new/current, TreeHerder]: Local testing of the patch on N5 and N9 (gcp) - both with Android 6. Additionally I tested the patch on an Android 5 tablet and an Android 2.3 phone.

[Risks and why]: I expect the risk to be low. Non Android-6.0 phones should not run into the workaround case.

[String/UUID change made/needed]: -

Comment 23

[Sebastian Kaspari (:sebastian; :pocmo)]

snorp, jchen: I'm more and more lost here. Do you (or someone else with more deeper knowledge of GeckoInputConnection and LayerView) have an Android 6.0 device to help debugging this?

I tried to document all my observations in the comments above. But in a nutshell:

* LayerView has focus but is not set as view receiving input in Android's InputMethodManager (They should be in sync as far as I understand Android's code)

* Because of that InputMethodManager.showSoftInput() exists early, returns false and does not show the soft keyboard

* This can only be fixed by a user by forcing a re-focus of LayerView (e.g. turning screen off/on)

* Forcing a refocus is what my workaround does too if we run into this erroneous case.

* There have been some changes around window focus in Android 6 (See commit links in comments above). Unfortunately most interesting values to debug this are not accessible and I can't get to them via reflection.

STR:

* I can always trigger this bug by creating a new tab or restarting the app (We should not have messed with focus before)
* Then load bugzilla.mozilla.org (not logged in)
* Click any of the search fields, switch between them, whatever, the keyboard never shows up until we try force a re-focus


While it seems like a behavior change in Android is causing this, I could not reproduce this with a test app that has a custom view and triggers focus/show keyboard on that view.

Comment 24

[(inactive) Jim Chen [:jchen] [:darchons]]

I can upgrade one of my devices and take a look, but it'll be a few days. BTW, does the GeckoView example have the same bug?

Comment 25

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/020fbe794499

Comment 26

[Liz Henry (:lizzard)]

Tracking for 42+ since we'd like Firefox to work with Android 6.0. 
It's likely too late to fix this in 41 though. 

Ioanna does your team have a device with 6.0 on it and some time to help verify the fix in m-c? Thanks!

Comment 27

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8672645 [details] [diff] [review]
1211848-keyboard-workaround.patch

This is indeed a pretty serious regression as Nexus 5 are being updated to Android 6. Taking it. Should be in 42 beta 8.

Comment 28

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/d56873313019

Comment 29

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-beta/rev/66c365b5fff5

Comment 30

[Sebastian Kaspari (:sebastian; :pocmo)]

This bug is fixed with the workaround. Debugging and finding real cause continue in bug 1215209.

Comment 31

[Daniel C]

It's a shame this was WONTFIX-ed for the 41 branch. Over-The-Air updates to Android 6 started earlier this week for the Nexus 5 (as well as the new Nexus 5X starting to be delivered) and this bug makes Firefox essentially unusable, with sites such as Google broken. I expect the drop-off rate for Nexus devices will be non-negligible, as the workaround is quite tedious to do every time compared to just using the default browser.

Comment 32

[Jefferson]

A faster workaround for Firefox 41.0.2 users is menu > Reload

Related SuMo thread if anyone wants to read it or comment there: 

Bookmarked links for search engines not activating keyboard after updating to Marshmallow
https://support.mozilla.org/questions/1089432

(It's not just bookmarks and search engines: any page loaded from a home screen that has text inputs lacks a keyboard when those inputs are tapped on all sites I tested.)

Comment 33

[Sebastian Kaspari (:sebastian; :pocmo)]

Clearing NI here. Will NI in follow-up bug 1216563 again if needed. :)

Comment 34

[Ioana Chiorean]

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #26)
> Ioanna does your team have a device with 6.0 on it and some time to help
> verify the fix in m-c? Thanks!

We just updated a tablet and a Nexus 5 - I will look at it now. 

(In reply to Sebastian Kaspari (:sebastian) from comment #30)
> This bug is fixed with the workaround. Debugging and finding real cause
> continue in bug 1215209.

As per this comment I will set verify the flags and track the new bug.