1181969 - Typing one letter hides the keyboard

Status: RESOLVED FIXED

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

Description

[Amir Aharoni]

To reproduce:
* Open a new tab.
* Tap the address bar. "about:blank" appears and is selected, and the keyboard appears at the bottom of the screen.
* Type 'g' on the keyboard.

Observed: 'g' appears, and the keyboard slides down and disappears.
Expected: 'g' appears and you can type further.

Tested in Firefox Nightly 42.0a1 2015-07-08, latest Nightly, on Samsung Galaxy S5. This doesn't happen in the stable Firefox 39.0 on the same device. And it can be any letter and not just 'g' :)

Comment 1

[Mark Capella [:capella]]

I'd seen this on my GS3 recently (a couple days ago), but building with the latest nightly m-c, the issue is currently resolved, so I didn't file.

Are you sure your repo is current?

Comment 2

[Amir Aharoni]

I didn't build this, I'm too stupid for that :)

It's an app I installed from nightly.mozilla.org and updates itself. I'm using the current one, see the date in the bug description.

It's been happening for a few days, for what it's worth. Maybe it will be gone with the next app update.

Comment 3

[Mark Capella [:capella]]

Aha! I repro'd it again, ( so you weren't crazy  :-) )

This message in logcat points the way:
E/GeckoConsole(29256): [JavaScript Error: "Error: Error in removeListener: There is no listener for message FindInPage:Find" {file: "resource://gre/modules/Messaging.jsm" line: 135}]

If that's not enough, the main regressing bug is:
https://bugzilla.mozilla.org/show_bug.cgi?id=1175434
Bug 1175434 - Quick search" bar overlaps with "Find in page" bar

cc:mcomella ... simple fix, too easy for a good first bug? or just squash it?

Comment 4

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(In reply to Mark Capella [:capella] from comment #3)
> cc:mcomella ... simple fix, too easy for a good first bug? or just squash it?

I'm unclear what your intended fix is here - I'm afraid that we might be hiding some initialization/race-condition bug so I think it'd require more investigation than a good first bug would offer.

Do you know much about the find in page bar, or is this something Sebastian or I should look into, as the ones who started this regression?

Comment 5

[Mark Capella [:capella]]

Attachment: bug1181969.diff

I've worked in here and on the gecko side (findhelper.js, etc) with wesj on several changes.

It's pretty easy. The previous patch needed to account for "previously inflated, but currently closed" find-in-page-bar state, else you wind up falling through and closing the ime needlessly.

Comment 6

[Mark Capella [:capella]]

So this bug is an issue after you use the find-in-page-bar once (open/close).

Now I see there's still an issue from earlier, if you open the FIPB, tap into the awsomebar and type a key, it'll still close the FIPB /and the keyboard/, so there'll still be a regression of sorts.

mmmm ... We'll have to condition the close of the IME on it's edittext being focused perhaps.

Comment 7

[Mark Capella [:capella]]

Attachment: bug1181969.diff

Try this ...

Comment 8

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Comment on attachment 8632988 [details] [diff] [review]
bug1181969.diff

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

Seems reasonable to me - thanks, Mark!

Comment 9

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Mark, can you flag for uplift to Aurora? We're chasing bug 1175434.

Comment 10

[Mark Capella [:capella]]

mmm, of course ... I'm waiting try results [0], and plan to push to fx-team in around 3-ish hrs.

If I wait to request uplift until then, does the timing work out?

[0] https://treeherder.mozilla.org/#/jobs?repo=try&revision=1862852a4384

Comment 11

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/4f939aa499b0

Comment 12

[Mark Capella [:capella]]

Comment on attachment 8632988 [details] [diff] [review]
bug1181969.diff

Approval Request Comment ... This fixes a regression (from bug 1175434) that's targeted for aurora.
[Feature/regressing bug #]: bug 1175434

[User impact if declined]: Noticeable UI failure during awesome bar searches for developer releases.
[Describe test coverage new/current, TreeHerder]: Local testing looks good, passed a TRY push, waiting on fx-team release to nightly.

[Risks and why]: Low risk to push. Simple changeset, easy to back-out or perform further corrections on. No permanent data changes.
[String/UUID change made/needed]: None.

Comment 13

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/4f939aa499b0

Comment 14

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

Comment on attachment 8632988 [details] [diff] [review]
bug1181969.diff

Seems like a non-invasive patch, let's checkin to Aurora. Also, appreciate the pretty awesome write-up on impact/risk associated with this patch.

Comment 15

[(PTO June 19-July 7) Ryan VanderMeulen]

https://hg.mozilla.org/releases/mozilla-aurora/rev/59154b48ee91