Closed Bug 1404111 Opened 5 years ago Closed 5 years ago
On some devices, IME doesn't appear when clicking into an input field after navigating away from about:home
1.98 KB, text/html
2.11 KB, text/html
59 bytes, text/x-review-board-request
59 bytes, text/x-review-board-request
5.35 KB, patch
|Details | Diff | Splinter Review|
[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
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
tracking-fennec: --- → ?
OS: Unspecified → Android
Hardware: Unspecified → ARM
Version: 57 Branch → Trunk
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.
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.
Maybe it happens more frequently on recent builds, but I'm definitively seeing this on 55/56 as well.
Tracked for now since it's a recent regression. David, Masayuki, would you be able to help find an owner for this.
Hmm, can somebody create a minimized testcase, first?
I was going to forward this NI to Masayuki and I see he has commented. (cc+ snorp)
Hi Jim. Could you please help take a look? I can also reproduce it in Nightly 58, Beta 57, It worked on Release 55
> Duplicate of this bug: 1405078 That bug contains links to 5 webcompat.com reports, FWIW.
Here's a reduced TC for the omegle.com report that was duped to this.
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?
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.
Bug 1402461 has a related problem, although for that one 55 is definitively unaffected, so it cannot be exactly the same problem as here.
See Also: → 1402461
(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.
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>.
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.
Depends on: 1402461
I think this is a dup of 1402461
Status: NEW → RESOLVED
tracking-fennec: ? → +
Closed: 5 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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)
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.
Oh, and the original reporter from bug 1402461 is using a Motorola phone as well, so there might be a pattern there...
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  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  is called and the GeckoView is set as mNextServedView. mNextServedView is promoted to mServedView as part of checkFocus , which isn't called directly from , though - instead, it is just queued up by calling scheduleCheckFocusLocked. - When things go wrong, onViewDetachedFromWindow for the View that is the current mServedView  happens inbetween the GeckoView getting focussed and the queued checkFocus call being executed. This has the effect of unfortunately clearing mNextServedView  and also queueing another checkFocus call. - Eventually checkFocus is called. Because mNextServedView is now null, it calls finishInputLocked , which then resets mServedView to null as well . 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.  http://androidxref.com/6.0.1_r10/xref/frameworks/base/core/java/android/view/inputmethod/InputMethodManager.java#297  http://androidxref.com/6.0.1_r10/xref/frameworks/base/core/java/android/view/inputmethod/InputMethodManager.java#1302  http://androidxref.com/6.0.1_r10/xref/frameworks/base/core/java/android/view/inputmethod/InputMethodManager.java#1389  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  http://androidxref.com/6.0.1_r10/xref/frameworks/base/core/java/android/view/inputmethod/InputMethodManager.java#1339  http://androidxref.com/6.0.1_r10/xref/frameworks/base/core/java/android/view/inputmethod/InputMethodManager.java#1379  http://androidxref.com/6.0.1_r10/xref/frameworks/base/core/java/android/view/inputmethod/InputMethodManager.java#822
Summary: Keyboard not appearing on some devices after navigating away from about:home → On some devices, IME doesn't appear when clicking into an input field after navigating away from about:home
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?
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 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.
Attachment #8917589 - Flags: review?(snorp) → review+
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.
Attachment #8917589 - Attachment is obsolete: true
Comment on attachment 8919469 [details] Bug 1404111 - Part 0 - Fix Javadoc. https://reviewboard.mozilla.org/r/190312/#review195570
Attachment #8919469 - Flags: review?(jh+bugzilla) → review+
Comment on attachment 8919470 [details] Bug 1404111 - Part 1 - Work around potential InputMethodManager bug when gaining focus. https://reviewboard.mozilla.org/r/190314/#review195582
Attachment #8919470 - Flags: review?(snorp) → review+
Pushed by firstname.lastname@example.org: 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 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
Attachment #8919470 - Flags: approval-mozilla-beta?
Comment on attachment 8919470 [details] Bug 1404111 - Part 1 - Work around potential InputMethodManager bug when gaining focus. Affects outlook/hotmail, severe enough, beta57+
Attachment #8919470 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
An import statement was missing on Beta.
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.
You need to log in before you can comment on or make changes to this bug.