Closed Bug 1215209 Opened 6 years ago Closed 6 years ago

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

Categories

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

All
Android
defect
Not set
critical

Tracking

(fennec44+)

RESOLVED WONTFIX
Tracking Status
fennec 44+ ---

People

(Reporter: sebastian, Assigned: jchen)

References

Details

Attachments

(1 file)

+++ This bug was initially created as a clone of Bug #1211848 +++

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).
We landed and uplifted a workaround in bug 1211848. This bug is about finding (and fixing) the real cause. See comments in bug 1211848 for debugging history.
tracking-fennec: --- → 44+
Attached file geckoview-crashlog
(In reply to Jim Chen [:jchen] [:darchons] from bug 1211848 comment #24)
> 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?

I went back to b8fc552d0667 (The last commit before we disabled geckoview_example) but the example just crashes on startup when I set it to go to Bugzilla or Google (Modified gecko:url in the layout file).
What's interesting is that this is triggered after touching a different view: A top site, a bookmark or a search suggestion. It is not triggered when for example searching but pressing enter instead of a suggestion.

I tried to modify my sample app accordingly but I still can't reproduce this outside of Fennec.
jchen: I have not been able to find the root cause. Did you get an Android 6 device in the meantime? Can you help me debug this?

You can read my findings in bug 1211848. In a nutshell:

* Observation: GeckoView/LayerView has focus but is not the active view of InputMethodManager
* Clearing focus and re-requesting focus fixes the issue
* This issue happens after switching to GeckoView by touching a different view (!): Clicking on a top site, bookmark, a search suggestion.
* It does not happen when entering a search term / url and pressing enter.
* There have been some changes in how Android handles window focus (See links in 1211848) but I could not see how they are triggering this.
Assignee: s.kaspari → nchen
Thanks for your work! I'll take a look later this week.
Flags: needinfo?(nchen)
I used jdb to poke around the system calls, and I think this is an Android bug/regression introduced in M, specifically by this commit [1], which ironically is an attempt to fix an earlier regression. The chain of events is something like,

1) User is on about:home; both the focused view and the input view is one of the HomePager views
1) User navigates to a page from about:home
2) HomePager view loses focus (and GeckoView automatically gains focus)
3) InputMethodManager.focusIn is called for GeckoView, but this does not change the input view immediately. Instead, mNextServedView is set to GeckoView, and a checkFocus() call is scheduled for later.
4) In the meantime, we destroy the HomePager views through HomePager.unload because about:home is being hidden.
5) Because mServedView == "destroyed HomePager view" in InputMethodManager.onViewDetachedFromWindow, mNextServedView is set to null. Note that this negates the effect of InputMethodManager.focusIn call earlier.
6) InputMethodManager.checkFocus that was scheduled earlier is called, but because mNextServedView is null, input is deactivated.
7) At this point, the focus is on GeckoView, but there is no input view, i.e. there is a discrepancy between the focused view and the input view, which shouldn't happen. Therefore, I believe this is an Android bug.

[1] https://github.com/android/platform_frameworks_base/commit/b13f015ab519b3e553c03eba971ada89b472fbbc

Right now, I think our workaround that Sebastian found is the best way to fix it, so I'm tempted to mark this bug WORKSFORME. But I'll take the weekend to see if anything pops into my head :)
Flags: needinfo?(nchen)
(In reply to Jim Chen [:jchen] [:darchons] from comment #6)
> 4) In the meantime, we destroy the HomePager views through HomePager.unload
> because about:home is being hidden.
> 5) Because mServedView == "destroyed HomePager view" in
> InputMethodManager.onViewDetachedFromWindow, mNextServedView is set to null.
> Note that this negates the effect of InputMethodManager.focusIn call earlier.

I tried to reproduce this with my test app (unsuccessfully). Somehow only the chain of events (and the timing) in Fennec trigger this bug.
There is a working demo of this bug at [1]. IMO our current workaround is appropriate for this Android bug, so marking as WONTFIX.

[1] https://github.com/pocmo/1215209-focus-keyboard-debugging
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.