1404111 - On some devices, IME doesn't appear when clicking into an input field after navigating away from about:home

Status: VERIFIED FIXED

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

Description

[[:philipp]]

[Tracking Requested - why for this release]:
regression on android affecting a major website (login to outlook/hotmail).

we got a user report about breakage at https://support.mozilla.org/questions/1177281 that i'm able to reproduce on fennec 57.0b3 on a sony z3c, android 6.0.1.

str:
- visit hotmail.com (or another microsoft service), you'll get redirected to https://login.live.com/login.srf
- in there the onscreen kexboard is not showing up when you tap into the username field, so it's not possible to log-into the site

Comment 1

[Bogdan Surd, QA [:bsurd, NI]]

They keyboard seems to appear if you tap in a certain area in the field, but it is not intuitive.

Video: https://goo.gl/k4HCBw

Comment 2

[Jan Henning [:JanH]]

This doesn't seem like a recent regression - I can reproduce this at least as far back as Nightly 55.

This also seems to coincide with the fact that - in builds predating pre bug 1400878 - when this behaviour happens, the keyboard doesn't pop up automatically after loading the page, either. Also, it seems that once the a click eventually succeeds in opening the keyboard, all subsequent click attempts work fine, too while the page is open.

Comment 3

[[:philipp]]

when loading the page with 55/56, the input field is focused and the keyboard pops up automatically. in 57 the keyboard isn't showing up at page load time.

Comment 4

[Jan Henning [:JanH]]

Maybe it happens more frequently on recent builds, but I'm definitively seeing this on 55/56 as well.

Comment 5

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Tracked  for now since it's a recent regression. David, Masayuki, would you be able to help find an owner for this.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Hmm, can somebody create a minimized testcase, first?

Comment 7

[David Bolter [:davidb] (NeedInfo me for attention)]

I was going to forward this NI to Masayuki and I see he has commented. (cc+ snorp)

Comment 8

[Nevin Chen(Not active on Bugzilla)]

Hi Jim.
Could you please help take a look?
I can also reproduce it in Nightly 58, Beta 57, 
It worked on Release 55

Comment 10

[Mike Taylor [:miketaylr]]

> Duplicate of this bug: 1405078

That bug contains links to 5 webcompat.com reports, FWIW.

Comment 11

[Mike Taylor [:miketaylr]]

Attachment: omegle.html

Here's a reduced TC for the omegle.com report that was duped to this.

Comment 12

[Mike Taylor [:miketaylr]]

Using that TC, mozregression exploded but I got as far as:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=37a5b7f6f101df2eb292b1b6baaf1540c9920e20&tochange=1fda52a1f3b81cf1a821155998dca637bb64e3d9

0:10.59 WARNING: Failed to uninstall org.mozilla.fennec (args: adb -s FA6CP0300594 wait-for-device uninstall org.mozilla.fennec, exitcode: 255, stdout: 
Exception occurred while executing:
java.lang.IllegalArgumentException: Unknown package: org.mozilla.fennec
	at com.android.server.pm.Settings.isOrphaned(Settings.java:4400)
	at com.android.server.pm.PackageManagerService.isOrphaned(PackageManagerService.java:21418)
	at com.android.server.pm.PackageManagerService.deletePackageVersioned(PackageManagerService.java:18492)
	at com.android.server.pm.PackageInstallerService.uninstall(PackageInstallerService.java:913)
	at com.android.server.pm.PackageManagerShellCommand.runUninstall(PackageManagerShellCommand.java:912)
	at com.android.server.pm.PackageManagerShellCommand.onCommand(PackageManagerShellCommand.java:134)
	at android.os.ShellCommand.exec(ShellCommand.java:96)
	at com.android.server.pm.PackageManagerService.onShellCommand(PackageManagerService.java:21717)
	at android.os.Binder.shellCommand(Binder.java:573)
	at android.os.Binder.onTransact(Binder.java:473)
	at android.content.pm.IPackageManager$Stub.onTransact(IPackageManager.java:2644)
	at com.android.server.pm.PackageManagerService.onTransact(PackageManagerService.java:3485)
	at android.os.Binder.execTransact(Binder.java:674))
This is normal if it is the first time the application is installed.
 0:18.62 ERROR: Unable to install '/var/folders/vx/1lx2ynfd46lb9rh4zbl9rchh0000gn/T/tmpfUKjx5/37a5b7f6f101--mozilla-central--target.apk'
 0:18.62 ERROR: Unable to install '/var/folders/vx/1lx2ynfd46lb9rh4zbl9rchh0000gn/T/tmpfUKjx5/37a5b7f6f101--mozilla-central--target.apk'
 0:18.63 INFO: Last good revision: 37a5b7f6f101df2eb292b1b6baaf1540c9920e20
 0:18.63 INFO: First bad revision: 1fda52a1f3b81cf1a821155998dca637bb64e3d9
 0:18.63 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=37a5b7f6f101df2eb292b1b6baaf1540c9920e20&tochange=1fda52a1f3b81cf1a821155998dca637bb64e3d9

 0:18.63 INFO: To resume, run:
 0:18.63 INFO: /Users/mitaylor/Library/Python/2.7/bin/mozregression --app=fennec --repo=mozilla-central --good=37a5b7f6f101df2eb292b1b6baaf1540c9920e20 --bad=1fda52a1f3b81cf1a821155998dca637bb64e3d9



Masayuki-san, does anything in https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=37a5b7f6f101df2eb292b1b6baaf1540c9920e20&tochange=1fda52a1f3b81cf1a821155998dca637bb64e3d9 look related?

Comment 13

[Jan Henning [:JanH]]

Note 1: Mike, are you sure that test case is correct? I cannot get it to work even on Firefox 41 (which was the oldest version I had lying around in my mozregression cache, so I took it as a starting point).

Note 2: Testing with https://m.realestate.com.au/buy, I'm seeing problematic behaviour even with the 2015-05-11 (i.e. FF 41) Nightly, that is the keyboard doesn't pop up automatically when loading the page and then it takes a number of attempts until clicking into the input field eventually triggers the keyboard.

So it could be that something recently made this worse (because so far on a current Nightly build I haven't been able to get the keyboard to open on https://m.realestate.com.au/buy at all) but there is also some (other/related/??) problem that's been present since quite some time.

Comment 14

[Jan Henning [:JanH]]

Bug 1402461 has a related problem, although for that one 55 is definitively unaffected, so it cannot be exactly the same problem as here.

Comment 15

[Mike Taylor [:miketaylr]]

(In reply to Jan Henning [:JanH] from comment #13)
> Note 1: Mike, are you sure that test case is correct? I cannot get it to
> work even on Firefox 41 (which was the oldest version I had lying around in
> my mozregression cache, so I took it as a starting point).

That's odd. It for sure works for me in <=55, and nothing above. I'm clicking on the div and expecting a kb to pop up:

[[  input ]  div   ]

If it matters, I'm using a Google Pixel.

Comment 16

[Jan Henning [:JanH]]

Maybe it's a question of screen size (I have a Motorola G4 Play)? Although for me it doesn't work on Desktop either - click as I may, I cannot even get the input cursor to appear in the input field in the first place, never mind test (on mobile) whether activating the input cursor also triggers the keyboard.

I did manage to turn it into an alternative testcase for bug 1402461, though (https://bugzilla.mozilla.org/attachment.cgi?id=8914517), by adding an onclick handler on the parent <div> that sets the focus on the <input>.

Comment 17

[Jan Henning [:JanH]]

Attachment: focustest.html

Uploading my modified test case here as well, since I can't get Mike Taylor's version to work and it's showing some interesting behaviour  as well.

To hopefully avoid some confusion:
Bug 1400878 caused a recent regression which breaks this test case completely. That problem is bug 1402461 for now.

This test case however is exhibiting buggy behaviour even before bug 1400878.
What I'm seeing is that after loading this test case, clicking into the input field doesn't trigger the keyboard, but after the tab and/or Firefox has been momentarily backgrounded (by sending Firefox into the background or selecting a different tab), things start working normally. So presumably there's some bug that fixes itself after a tab has been blurred and then focused again.

What's weird though is I can only reproduce this behaviour on my Moto G4 Play (Android 6.0.1), but not on an older S3 Mini (Android 4.1.2) from my family.
That might also explain why other people further up reported 55 and 56 as unaffected, because they've presumably been seeing only bug 1402461.

Comment 18

[James Willcox (:snorp) ([e-mail]) (he/him)]

I think this is a dup of 1402461

Comment 19

[Jan Henning [:JanH]]

Nope, I can still get https://bugzilla.mozilla.org/attachment.cgi?id=8914704 or login.live.com into a state where after loading the page, tapping into the input field won't trigger the keyboard. I'm not sure whether I was mistaken or this is some sort of Heisenbug, but switching tabs no longer fixes this condition. Momentarily backgrounding Firefox however still *does* fix the problem, i.e. afterwards tapping into the input field triggers the keyboard just fine.

Comment 20

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

Does that always happen or only sometimes? With the fix from bug 1402461, both the testcase and live.com work for me on a Nexus 5X (7.1.2) and on a Nexus 4 (4.4.3)

Comment 21

[Jan Henning [:JanH]]

I think not quite 100 % (especially on login.live.com), but definitively significantly more than 50 % of the time.

If nobody else can reproduce this, I can try investigating a little further when I can find some time.

Comment 22

[Jan Henning [:JanH]]

Oh, and the original reporter from bug 1402461 is using a Motorola phone as well, so there might be a pattern there...

Comment 23

[Jan Henning [:JanH]]

Given that this is a long-standing issue on affected devices, getting this into a 56.x is probably not worth it.

I've looked into it and the immediate cause seems to be that somehow during the transition from about:home to the GeckoView being shown, the InputMethodManager's mServedView [1] ends up as "null" instead of the GeckoView, so when we then try to show the keyboard in response to a NOTIFY_IME_OF_FOCUS notification from Gecko, that attempt is ignored by the IMM because as far it is concerned, the GeckoView isn't actually focussed.

As for why that happens, attempting to debug the framework code from Android Studio on a real device is a bit of a pain because the source code lines don't of course don't quite match up with the stored debug information from my phone, but I think this is what happens when things go wrong:
- As part of hiding the home pager, the GeckoView gains focus, which means that [2] is called and the GeckoView is set as mNextServedView. mNextServedView is promoted to mServedView as part of checkFocus [3], which isn't called directly from [2], though - instead, it is just queued up by calling scheduleCheckFocusLocked.
- When things go wrong, onViewDetachedFromWindow for the View that is the current mServedView [4] happens inbetween the GeckoView getting focussed and the queued checkFocus call being executed. This has the effect of unfortunately clearing mNextServedView [5] and also queueing another checkFocus call.
- Eventually checkFocus is called. Because mNextServedView is now null, it calls finishInputLocked [6], which then resets mServedView to null as well [7].

I've no idea why onViewDetachedFromWindow happens to be called with that particular timing only on some devices, though and even there not necessarily 100% of the time (and I've got a feeling that debugging can mess up the timings as well).

In any case that would explain why this fixes itself after momentarily background Firefox - doing so clears and then re-sets the focus on the GeckoView and with no onViewDetachedFromWindow calls interfering, this then reconciles the InputMethodManager's internal state with that of the rest of the app.
A possible workaround could therefore be to queue up an additional focus call when the GeckoView gains focus after the home pager is being hidden, though I'm not yet sure about the best way to do that.

[1] http://androidxref.com/6.0.1_r10/xref/frameworks/base/core/java/android/view/inputmethod/InputMethodManager.java#297
[2] http://androidxref.com/6.0.1_r10/xref/frameworks/base/core/java/android/view/inputmethod/InputMethodManager.java#1302
[3] http://androidxref.com/6.0.1_r10/xref/frameworks/base/core/java/android/view/inputmethod/InputMethodManager.java#1389
[4] At least with Top Sites as the default home panel, this usually seems to be the "activity_stream_main_recyclerview" when opening a new tab and then hitting "Paste & Go" for a URL from the clipboard
[5] http://androidxref.com/6.0.1_r10/xref/frameworks/base/core/java/android/view/inputmethod/InputMethodManager.java#1339
[6] http://androidxref.com/6.0.1_r10/xref/frameworks/base/core/java/android/view/inputmethod/InputMethodManager.java#1379
[7] http://androidxref.com/6.0.1_r10/xref/frameworks/base/core/java/android/view/inputmethod/InputMethodManager.java#822

Comment 24

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Hi Snorp, Jan, is this something that needs to be prioritized higher on the list? It seems like a must fix for 57 to me. Do you agree?

Comment 25

[Jan Henning [:JanH]]

Just so there's no confusion, the more pressing issue that affected everybody was resolved in bug 1402461.

This bug in its current state has been spotted on Motorola devices only and it's not a recent regression. Having said that, fixing this for 57 would of course still be nice and I think the potential fix (re-requesting focus for the GeckoView after about:home is hidden) shouldn't turn out too invasive for potential uplifting.

Comment 26

[Jan Henning [:JanH]]

Attachment: Bug 1404111 - Re-request focus after unhiding the layer view.

Review commit: https://reviewboard.mozilla.org/r/188518/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/188518/

Comment 27

[James Willcox (:snorp) ([e-mail]) (he/him)]

Comment on attachment 8917589 [details]
Bug 1404111 - Re-request focus after unhiding the layer view.

https://reviewboard.mozilla.org/r/188518/#review194872

I would prefer a generic solution inside LayerView or GeckoView itself, but if that's not possible I guess this will have to do.

Comment 28

[Jan Henning [:JanH]]

Comment on attachment 8917589 [details]
Bug 1404111 - Re-request focus after unhiding the layer view.

https://reviewboard.mozilla.org/r/188518/#review194872

Hmm, yes - now that you're mentioning it, I might have an idea on how this could be done from within the GeckoView. I'll try and see if that gets me anywhere before landing this as it is.

Comment 29

[Jan Henning [:JanH]]

Attachment: Bug 1404111 - Part 0 - Fix Javadoc.

Review commit: https://reviewboard.mozilla.org/r/190312/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/190312/

Comment 30

[Jan Henning [:JanH]]

Attachment: Bug 1404111 - Part 1 - Work around potential InputMethodManager bug when gaining focus.

Review commit: https://reviewboard.mozilla.org/r/190314/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/190314/

Comment 31

[Jan Henning [:JanH]]

Comment on attachment 8919469 [details]
Bug 1404111 - Part 0 - Fix Javadoc.

https://reviewboard.mozilla.org/r/190312/#review195570

Comment 32

[James Willcox (:snorp) ([e-mail]) (he/him)]

Comment on attachment 8919470 [details]
Bug 1404111 - Part 1 - Work around potential InputMethodManager bug when gaining focus.

https://reviewboard.mozilla.org/r/190314/#review195582

Comment 33

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/37a3dec05168
Part 0 - Fix Javadoc. r=JanH
https://hg.mozilla.org/integration/autoland/rev/666c3c19d562
Part 1 - Work around potential InputMethodManager bug when gaining focus. r=snorp

Comment 34

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/37a3dec05168
https://hg.mozilla.org/mozilla-central/rev/666c3c19d562

Comment 35

[Jan Henning [:JanH]]

Comment on attachment 8919470 [details]
Bug 1404111 - Part 1 - Work around potential InputMethodManager bug when gaining focus.

Approval Request Comment
[Feature/Bug causing the regression]: Android platform bug
[User impact if declined]: The IME might not appear after opening a new tab and loading an URL, until the user momentarily focuses some other UI element or backgrounds Firefox.
[Is this code covered by automated tests?]: no
[Has the fix been verified in Nightly?]: Yes.
[Needs manual test from QE? If yes, steps to reproduce]: no
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: Lowish.
[Why is the change risky/not risky?]: The workaround consists of just clearing and re-setting the focus, which is not fundamentally different from what happens when the user e.g. taps the phone's status bar to peek at some notifications. Additionally, the workaround is triggered only when actually necessary, i.e. if we wouldn't be able to interact with the IME otherwise.
[String changes made/needed]: none

Comment 36

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8919470 [details]
Bug 1404111 - Part 1 - Work around potential InputMethodManager bug when gaining focus.

Affects outlook/hotmail, severe enough, beta57+

Comment 37

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/f645623441b3
https://hg.mozilla.org/releases/mozilla-beta/rev/7a9e0869a2e6

Comment 38

[Ryan VanderMeulen [:RyanVM]]

Backed out from Beta for bustage.
https://hg.mozilla.org/releases/mozilla-beta/rev/1d56d3922195efcabe9807b8ec0ea216397f90b4

https://treeherder.mozilla.org/logviewer.html#?job_id=138000578&repo=mozilla-beta

Comment 39

[Jan Henning [:JanH]]

Attachment: bug1404111-p1-beta.patch

An import statement was missing on Beta.

Comment 40

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/ed1ece91fe04
https://hg.mozilla.org/releases/mozilla-beta/rev/fa442127041c

Comment 41

[Bogdan Surd, QA [:bsurd, NI]]

Verified this in both Nightly an Beta the issue is no longer reproducible. Tested on different sites and types of input boxes and everything worked as expected.