Description: ** 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. Actual: No third party keyboard is avaiable to type from. Expected: 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: video- http://youtu.be/O85V_uXIOhs logcat

Requesting a branch check to find earliest branch to block to, will also need a window. See bug 1045814 for additional details.

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.

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: https://github.com/mozilla-b2g/gaia/compare/7befe4fc692f66d5f3b8981290ec59ab83741435...848b7b74a698d1472151f122e59f85ad07da407c Caused by Bug 1094561.

Tim, can you take a look at this please? It looks like the work for bug 1094561 might be the culprit here.

Ouch. Thanks for the window!

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: https://github.com/mozilla-b2g/gaia/blob/966b3a7/shared/js/input_mgmt/input_app_list.js#L304 The function is called through handleEvent() and _addInputApp() in these locations: https://github.com/mozilla-b2g/gaia/blob/966b3a7/shared/js/input_mgmt/input_app_list.js#L197 https://github.com/mozilla-b2g/gaia/blob/966b3a7/shared/js/input_mgmt/input_app_list.js#L280 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)

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.

Comment on attachment 8552982 [details] [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]: None.

Comment on attachment 8552982 [details] [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.

waiting for master landing before getting to branch approval here.

master: https://github.com/mozilla-b2g/gaia/commit/3b69ea13268f028e9220c51627a247d7c5938a8c

v2.2: https://github.com/mozilla-b2g/gaia/commit/34f1dd6c7cbea23b858879dc1cbfb923c3bd42b4

Clearing the blocking nom for 2.2? as this is already fixed/verified on that branch per the status flag

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.

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: https://www.youtube.com/watch?v=a-RrhcVUSX4 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

(Setting NI on Tim in case he misses this)

I will investigate if we need a backout here.

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.

Bug 1129315 filed.

Per Comment 19 and Comment 20,add "See also". This bug has been successfully verified on latest Flame v2.2&3.0 in https://bugzilla.mozilla.org/show_bug.cgi?id=1129315#c24 and https://bugzilla.mozilla.org/show_bug.cgi?id=1129315#c25. Set "Status" as "Verified".