Closed Bug 1124265 Opened 10 years ago Closed 10 years ago

[Keyboard] Cannot switch to installed Marketplace Keyboards


(Firefox OS Graveyard :: Gaia::System::Input Mgmt, defect)

Gonk (Firefox OS)
Not set


(blocking-b2g:2.2+, b2g-v2.0 unaffected, b2g-v2.1 unaffected, b2g-v2.2 verified, b2g-master verified)

2.2 S4 (23jan)
blocking-b2g 2.2+
Tracking Status
b2g-v2.0 --- unaffected
b2g-v2.1 --- unaffected
b2g-v2.2 --- verified
b2g-master --- verified


(Reporter: onelson, Assigned: timdream)




(Keywords: regression, Whiteboard: [3.0-Daily-Testing][p=1])


(1 file)

** created after c#7 from bug 1045814 **
When a user downloads a new keyboard from the marketplace, they will observe that they will unable to use it. From Settings > Keyboards, downloaded keyboards can be selected to be used from any keyboard and then they cannot be found (hold down the language button to the left of the space bar to select from active keyboards).
Tested against 5 keyboards in marketplace:
* LOL keyboard
* Smiley Keyboard
* Thai keyboard - 4 line
* Greek Alphabet Keyboard
* Bulgarian Keyboard   

Repro Steps:
1) Update a Flame device to BuildID: 20150121010204
2) Open 'Marketplace' app.
3) Search for 'keyboard'.
4) Download keyboard application X (names of tested listed above).
5) After download finishes, ensure it's an active keyboard via Settings > Keyboard.
6) Open Messages and compose new message.
7) Hold tap on the language button.
8) Observe keyboards.
No third party keyboard is avaiable to type from.
All active keyboards are displayed and useable.
Environmental Variables:
Device: Flame 3.0 Master
BuildID: 20150121010204
Gaia: 5e98dc164b17fd6decb48a9eaddef0e55b82e249
Gecko: 540077a30866
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 38.0a1 (3.0 Master)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
Repro frequency: 5/5
See attached: 
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Whiteboard: [3.0-Daily-Testing]
Summary: [Keyboard] Third-Party Keyboards from Marketplace do not appear when installed → [Keyboard] Cannot switch to installed Marketplace Keyboards
Requesting a branch check to find earliest branch to block to, will also need a window.  See bug 1045814 for additional details.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: qawanted, regression
QA Contact: pcheng
This issue occurs on Flame 2.2. Unable to switch to 3rd party keyboard after installing it and enabling it via installation dialog (and later confirmed in Settings that it's indeed enabled). Tested with LOL keyboard.

Device: Flame 2.2 (shallow flash, 319MB mem)
BuildID: 20150120214039
Gaia: e4f9b5da3751798f9cc5d95f302c30722cc11fca
Gecko: 75a462a58d7a
Version: 37.0a2 (2.2)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0


This issue does NOT occur on Flame 2.1 or Flame 2.0. LOL keyboard can be correctly switched to from built-in keyboard and can be utilized (although it doesn't seem to be able to type anything the first time it's switched to. It only starts to work if I switch back to English and switch to LOL keyboard again) in Messages app.

Device: Flame 2.1 (shallow flash, 319MB mem)
BuildID: 20150120214032
Gaia: 77c57eb8a985d5cbd34a597fb1b978ba6e205af6
Gecko: 4c28bb3be0c6
Version: 34.0 (2.1)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.0 (shallow flash, 319MB mem)
BuildID: 20150120212734
Gaia: 736933b25ded904f0cb935a0d48f1f3cf91d33ad
Gecko: 6a7c0eba2aa3
Version: 32.0 (2.0)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0


Working on getting the window now.
Flags: needinfo?(ktucker)
Flags: needinfo?(ktucker)
b2g-inbound regression window:

Last Working Environmental Variables:
Device: Flame
BuildID: 20141111015805
Gaia: 7befe4fc692f66d5f3b8981290ec59ab83741435
Gecko: 9d79d14354e2
Version: 36.0a1 (2.2 Master)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

First Broken Environmental Variables:
Device: Flame
BuildID: 20141111022805
Gaia: 848b7b74a698d1472151f122e59f85ad07da407c
Gecko: bab51f5dc39f
Version: 36.0a1 (2.2)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

First Broken Gaia & Last Working Gecko - issue DOES repro
Gaia: 848b7b74a698d1472151f122e59f85ad07da407c
Gecko: 9d79d14354e2

First Broken Gecko & Last Working Gaia - issue does NOT repro
Gaia: 7befe4fc692f66d5f3b8981290ec59ab83741435
Gecko: bab51f5dc39f

Gaia pushlog:

Caused by Bug 1094561.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Tim, can you take a look at this please? It looks like the work for bug 1094561 might be the culprit here.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(timdream)
Ouch. Thanks for the window!
Blocks: 1094561
blocking-b2g: --- → 2.2?
Flags: needinfo?(timdream)
Assignee: nobody → timdream
Component: Gaia::Keyboard → Gaia::System::Input Mgmt
After investigation with break points, I realized |app.manifest| is not available to me in the 'install' event function loop, nor some time afterwards.

When an app is installed, we go through _isInputApp() to see if we want to care about it, and the unavailability of |app.manifest| makes the function early return to false:

The function is called through handleEvent() and _addInputApp() in these locations:

I can confirm if I wrap the code in handleEvent() with setTimeout(1000) this can be fixed.

Fabrice, it looks like the 'install' event does not signal the availability of manifest in DOMApplication. Is this a bug or a intended behavior? Can we get a real install event instead?

(De-assign myself since I will probably not be helpful in App API)
Assignee: timdream → nobody
Component: Gaia::System::Input Mgmt → DOM: Apps
Flags: needinfo?(fabrice)
Product: Firefox OS → Core
Actually -- there isn't a manifest because the DOMApplication is still being downloaded.

I can provide a minimal patch and wait for downloadsuccess event in the InputAppList.
Assignee: nobody → timdream
Component: DOM: Apps → Gaia::System::Input Mgmt
Flags: needinfo?(fabrice)
Product: Core → Firefox OS
Comment on attachment 8552982 [details] [review]
[PullReq] timdream:input-mgmt-layout-download to mozilla-b2g:master

John, could you do a quick review of this smallish patch? Thanks.

[Approval Request Comment]

[Bug caused by] (feature/regressing bug #): 
This bug is caused by bug 1094561. In that bug, I made a wrong assumption about DOMApplication instances returned by the API and attempt to inspect it's manifest object before it's being downloaded. The patch here accounts that by wait for the downloadsuccess event of the said app.

I wasn't aware of this because previous manual testing was done by pushing apps into the phone with App Manager -- in which the zip was pushed rather than downloaded.

[User impact] if declined: 
User will not be able to use the newly installed input app until reboot

[Testing completed]:
Manually tested on Flame and unit tested added to assert the added flow.

Unfortunately we can't create integration test for this case because reproduce this require network.

The integration test done in bug 1010021 already covered the general install-without-download case.

[Risk to taking this patch] (and alternatives if risky):

This patch is quite small and localized. The interfaces between objects are not changed, and there isn't any possible smaller approach.

[String changes made]:

Attachment #8552982 - Flags: review?(jlu)
Attachment #8552982 - Flags: approval-gaia-v2.2?(bbajaj)
Comment on attachment 8552982 [details] [review]
[PullReq] timdream:input-mgmt-layout-download to mozilla-b2g:master

Looks good, but as discussed please move one line of test script to reflect testing against the offending behavior.
Attachment #8552982 - Flags: review?(jlu) → review+
waiting for master landing before getting to branch approval here.
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [3.0-Daily-Testing] → [3.0-Daily-Testing][p=1]
Target Milestone: --- → 2.2 S4 (23jan)
Attachment #8552982 - Flags: approval-gaia-v2.2?(bbajaj) → approval-gaia-v2.2+
Clearing the blocking nom for 2.2? as this is already fixed/verified on that branch per the status flag
blocking-b2g: 2.2? → ---
Actually -- we still need a blocking decision in case there is a backout/reopen.

To save everyone's time I will just going to plus this regression.
blocking-b2g: --- → 2.2+
This patch did NOT fix the issue and is breaking 3rd party keyboard in another way. On 2.2 branch I tested with latest as well as a build on 1/24 (one day after patch landed) and the behavior is the same, which further confirms that it's this patch causing the issue.

Observed behavior: No keyboard is displayed after switching to 3rd party keyboard. User will have NO keyboard displayed anywhere until they disable the 3rd party keyboard in Settings.

See video:

Tested on bug occurs on:

Device: Flame 2.2 (shallow flash)
BuildID: 20150124133137
Gaia: 0518f4581a0925c0b703d730ef289ab15cbd1216
Gecko: c6aa604a7967
Version: 37.0a2 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Device: Flame 2.2 (full flash)
BuildID: 20150202002507
Gaia: d6141fa3208f224393269e17c39d1fe53b7e6a05
Gecko: be206fa2fb60
Version: 37.0a2 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Device: Flame 3.0 (shallow flash)
BuildID: 20150202042034
Gaia: 4171327fce4803c52b2fae8071b114a70a3a68a7
Gecko: 3bf7ed413e87
Version: 38.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?][failed-verification]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(ktucker)
Resolution: FIXED → ---
(Setting NI on Tim in case he misses this)
Flags: needinfo?(timdream)
I will investigate if we need a backout here.
Flags: needinfo?(timdream)
I am seeing the following error when following comment 16:

W/LOL Keyboard( 2071): [JavaScript Error: "TypeError: window.navigator.mozInputMethod is undefined" {file: "app://{635dcfeb-c110-40de-b006-2825db47c627}/js/main.js" line: 7}]

Which means the LOL Keyboard did not show up because it didn't receive mozInputMethod permission. It's bad but it's unrelated to this bug. I will clone another bug for investigation.
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
    Per Comment 19 and Comment 20,add "See also".

    This bug has been successfully verified on latest Flame v2.2&3.0 in and
    Set "Status" as "Verified".
See Also: → 1129315
You need to log in before you can comment on or make changes to this bug.