819073 - Keyboard stops working after going back from Awesomescreen when "Don't keep activities" is enabled

Status: VERIFIED FIXED

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

Description

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

I suspect this is the cause of a lot of the keyboard not working bugs (e.g. Bug 806106)

Comment 1

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

Attachment: Set InputConnection during each focus notification (v1)

This patch moves the process of connecting GeckoInputConnection to LayerView from GeckoAppShell to GeckoEditable, during each focusing event. This way, the current LayerView is always associated with GeckoInputConnection.

As part of the change, this patch also makes GeckoEditable, instead of GeckoAppShell, manage GeckoInputConnection.

Comment 2

[Chris Peterson [:cpeterson]]

Comment on attachment 689825 [details] [diff] [review]
Set InputConnection during each focus notification (v1)

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

LGTM. This is a good improvement.

Comment 3

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/5ea7c2464e88

Comment 4

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/5ea7c2464e88

Comment 6

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

Comment on attachment 689825 [details] [diff] [review]
Set InputConnection during each focus notification (v1)

I think this is a good candidate for Aurora

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: Cannot input text anywhere, without any warning, if "Don't keep activities" system setting is on.
Testing completed (on m-c, etc.): Locally; m-c
Risk to taking this patch (and alternatives if risky): Very low; situations outside of the bug have previous behavior
String or UUID changes made by this patch: None

Comment 7

[bhavana bajaj [:bajaj]]

Comment on attachment 689825 [details] [diff] [review]
Set InputConnection during each focus notification (v1)

Approving on aurora as this is low risk and has duplicates/blockers which can be fixed with this patch.Also adding qawanted,verifyme for mobile qa to help with verification on this bug or the duplicate one.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Looks like this is going to need a branch-specific patch.

Comment 9

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

Attachment: Set InputConnection during each focus notification (Aurora)

Comment 10

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

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

Comment 11

[Adrian Tamas (:AdrianT)]

This is still reproducible on Firefox Mobile 19 beta 1 on the Samsung Galaxy Note running Android 4.0.4 but not on Nightly 21.0a1 2013-01-10. Waiting for beta 2 to confirm if this is still an issue

Comment 12

[Kevin Brosnan [Ex-Mozilla]]

Beta 1 should have had the fix. Waiting for beta 2 should not change anything. Is this reproducible on other devices or just the Galaxy Note?

Comment 13

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

(In reply to adrian tamas from comment #11)
> This is still reproducible on Firefox Mobile 19 beta 1 on the Samsung Galaxy
> Note running Android 4.0.4 but not on Nightly 21.0a1 2013-01-10. Waiting for
> beta 2 to confirm if this is still an issue

I was not able to reproduce on my Galaxy Note (4.0.3) using Beta. Can you describe your exact STR?

Comment 14

[Adrian Tamas (:AdrianT)]

Steeps:
1) Set don't keep activities to enable
2) Load google.com, tap in the search field and enter 2 characters
3) Tap in the URL bar and after the Awesomebar is opened go back
4) Tap again in the google search field and continue typing

Results:
No characters are typed unless the user taps outside of the field and then back in

Please see the videocapture: http://youtu.be/vC70lDyHTWw

I am able to reproduce this on Firefox Mobile 19 beta 2 and Nightly 21.0a1 2012-01-16 on the Samsung Galaxy Nexus(Android 4.1.1) and Samsung Note (Android 4.0.4)  so please disregard what I said in Comment 11 about not being able to reproduce the issue on Nightly

Comment 15

[Aaron Train [:aaronmt]]

Can we get a regression-range since this was fixed?

Comment 16

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

(In reply to Aaron Train [:aaronmt] from comment #15)
> Can we get a regression-range since this was fixed?

Bug 825120. Note that this new issue is different from the original one. The original issue was that the keyboard stops working completely and a restart is needed. The new issue is much less severe; the keyboard only stops working if an input field is already focused, and refocusing the input field makes keyboard work again.

Comment 17

[Alex Keybl [:akeybl]]

(In reply to Jim Chen [:jchen :nchen] from comment #16)
> (In reply to Aaron Train [:aaronmt] from comment #15)
> > Can we get a regression-range since this was fixed?
> 
> Bug 825120. Note that this new issue is different from the original one. The
> original issue was that the keyboard stops working completely and a restart
> is needed. The new issue is much less severe; the keyboard only stops
> working if an input field is already focused, and refocusing the input field
> makes keyboard work again.

Can we open up a separate bug for this less severe behavior? This behavior seems less critical to track/fix for FF19, given how uncommon it is to set "don't keep activities"

Comment 18

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

This looks to be fixed after several other bugs landed in the latest Aurora and Nightly. Still reproducible for latest Beta, but I don't think we will fix it, given the low severity and risk of uplifting all those other bugs in order to fix this one.

Comment 19

[Adrian Tamas (:AdrianT)]

Verified on Firefox Mobile 20 beta 5 and Aurora 21.0a2 2013-03-14 on the LG Nexus 4 (Android 4.2.2). I am not able to reproduce the original issue or the one discribed in Comment 14