Closed Bug 998106 Opened 9 years ago Closed 8 years ago
[B2G][Gaia][FTE][Keyboard] Selecting languages other than English during the FTE causes the associated keyboard not to load
33.69 KB, application/zip
2.86 MB, video/3gpp
87.27 KB, text/plain
799.17 KB, text/plain
46 bytes, text/x-github-pull-request
|Details | Review|
40.37 KB, image/png
3.06 MB, video/mp4
Description: If the user selects a language other than English during the FTE, such as "Magyar", the keyboard will not show up in the FTE when entering WIFI information etc. The language will load if the user goes to Settings->Languages and picks another language, accepts, then selects the original language again. Repro Steps: 1) Update a Buri to BuildID: 20140417000204 2) During the FTE pick a language other than English (Magyar) 3) Proceed through the FTE until reaching the Wifi settings. 4) Select a network and attempt to enter the Wifi password. Actual: The keyboard will not appear. It will remain in unusable until re-selected from Settings->Languages Expected: Keyboards from languages other than English load properly and are usable in the FTE and afterwards. 1.4 Environmental Variables: Device: Buri 1.4 MOZ BuildID: 20140417000204 Gaia: 00a9d55a3e7463cecfb5dde185c0ee1f4c4d9e54 Gecko: d3d40652aaa2 Version: 30.0a2 Firmware Version: v1.2-device.cfg Repro frequency: 100% See attached: http://youtu.be/XRPLJ8wf8Zk
The result is the same for 1.3 1.3 Environmental Variables: Device: Buri 1.3 MOZ BuildID: 20140416004000 Gaia: 11d027ec28d8e8f09c76b35661222499e124abc8 Gecko: ab227cdd984c Version: 28.0 Firmware Version: v1.2-device.cfg
Lionel, Could you please help check if "Myanmar" keyboard is available in, Settings app. > keyboards > Selected Keyboards > Add more ... If not, this should be a build issue because we would opt-in the layouts during build time. Thanks.
Sending to qawanted as I can't currently check this.
(In reply to Rudy Lu [:rudyl] from comment #2) > Lionel, > > Could you please help check if "Myanmar" keyboard is available in, > Settings app. > keyboards > Selected Keyboards > Add more ... > > If not, this should be a build issue because we would opt-in the layouts > during build time. > Thanks. Myanmar keyboard is not available in the Settings App. menu. 1.4 Environmental Variables: Device: buri 1.4 MOZ BuildID: 20140423000203 Gaia: 25d53d442cbf17c150575c98979e957ae040e023 Gecko: 2d1b4d36eef9 Version: 30.0a2 Firmware Version: v1.2-device.cfg
According to comment 4, then I think this is an issue about the build, that the build should include Myanmar keyboard if the language is listed in the FTU.
Component: Gaia::Keyboard → Gaia::Build
Lionel, this looks like a build configuration issue, we should add Myanmar layout and Myanmar language pack if we need them both. there are two variables which should be configed on build time: keyboard: GAIA_KEYBOARD_LAYOUTS language pack: LOCALES_FILE and LOCALE_BASEDIR and please reference this page for more information: https://developer.mozilla.org/en-US/Firefox_OS/Building#Gaia and I think you should add GAIA_KEYBOARD_LAYOUTS in http://hg.mozilla.org/mozilla-central/file/b6408c32a170/b2g/config/hamachi/config.json for buri. and it should not be a gaia build issue, so change it to FirefoxOS::General. Jason, do you know the right componment if we need to modify mozilla-central/b2g/config/hamachi/config.json?
Component: Gaia::Build → General
Maybe rel eng?
Component: General → General Automation
Product: Firefox OS → Release Engineering
The RelEng people who know most about b2g are on PTO this week, but I'll take stab at this. Could you please clarify why early comments talk about Magyar and imply a general problem, but we started focusing on Myanmar from comment #2 ? FWIW, the hamachi builds are using locales/languages_dev.json, which already includes Magyar (hu) but not Myanmar (my). Is GAIA_KEYBOARD_LAYOUTS being suggested because we don't want to modify the locale list for all devices, just hamachi ? If I take a recent-ish flame build (which uses locales/languages_all.json) then there is a long list of locales which either * don't show localised strings after being selected (eg Magyar, Hrvatski), and keyboard doesn't work at the wifi password page * don't show localised strings and but do show a keyboard (eg Espanol) * do show localised strings and do show a keyboard (eg Italiano, Deutsch) Which suggests to me we have various states of completeness for locales, and possibly a mismatch between strings and keyboard layouts in the gaia build system.
I'm moving this back to Fx OS. The gaia languages and keyboards need to be independent choices, I don't see any reason why one would require the other. I think this is that there's no default keyboard if there's no matching keyboard for the UI language. We should use the English keyboard as fallback in that case. Based on that, I'm moving this to the keyboard app.
Component: General Automation → Gaia::Keyboard
Product: Release Engineering → Firefox OS
(In reply to Axel Hecht [:Pike] from comment #9) > > We should use the English keyboard as fallback in that case. i agree totaly with this, now a user have a real bad FUE when there is no keyboard when they choose for excample dutch a language
[Blocking Requested - why for this release]: This was originally no'md for 2.0 blocking in bug 1088013. moving it to this bug to track work and needed fix. Triage, please consider this blocking because non-en keyboard users will not get input. Full list of affected locales are listed in: https://bugzilla.mozilla.org/show_bug.cgi?id=1088013#c20 ni on rudylu and tim to track the bug over here and not the dupe.
blocking-b2g: --- → 2.0?
Please also note that this can only happen on the Nightly config which does not impact the production device. See bug 1088013 for discussion. Also carrying over assignee and affected flags.
Hi Norry, qawanted. Please try reproduce this on Woodduck 2.0M and Flame 2.0
(In reply to Josh Cheng [:josh] from comment #14) > Hi Norry, > qawanted. > Please try reproduce this on Woodduck 2.0M and Flame 2.0 Josh, is this really necessary? Per previous comment, this bug only affects build that wasn't properly configured.
Issue DOES occur in Flame 2.0 (Full Flash, nightly build). Actual Results: The correct keyboard does not load in the FTE after selecting a language such as Magyar. Device: Flame 2.0 Build ID: 20141027000202 Gaia: 2183b4f3ec0eb47ab1f133c31732ec53b08ad253 Gecko: 43bee45176c4 Version: 32.0 (2.0) Firmware Version: v188 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 NOTICE: My QA Team does not have the resources to test this issue against a Woodduck device.
QA Whiteboard: [QAnalyst-Triage?]
Hi Josh, Issue still exists in Flame 2.0, while does not exist in woodduck 2.0m(There are just 6 language option to select in FTE, and we have tried every language, issue does not exist) Flame 2.0 versions: Gaia-Rev 9f5b6f025e528fabfcc068782cb9b492cb51a7f9 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/de8cfd54bf93 Build-ID 20141028160208 Version 32.0 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141028.193612 FW-Date Tue Oct 28 19:36:27 EDT 2014 Bootloader L1TC00011840 ------------------------- Woodduck version: Gaia-Rev 4a100d50c9d0345f69699407d3c14cbfbdcf2f60 Gecko-Rev f43ad50634bd01fa047563736d59ad1bbf435b03 Build-ID 20141029050313 Version 32.0 Device-Name soul35 FW-Release 4.4.2 FW-Incremental 1414530320 FW-Date Wed Oct 29 05:05:43 CST 2014
Found time: 20:37
I'm on it.
This patch is to solve this issue from build steps. [Background] We would create a "language -> keyboard layouts" mapping in Gaia build process, and this needs to happen in build just because we need to get manifestURL at this stage. [Solution] This patch would add a checking to filter out the layouts that are not preloaded, so that Gaia system (precisely, the keyboard manager), would not try to swictch to a non-existing layout when the user changes the UI language. -- George, could you please help review this change? Please let me know if you need to discuss this in more detail.
Attachment #8514132 - Flags: review?(gduan)
Status: NEW → ASSIGNED
Target Milestone: --- → 2.1 S8 (7Nov)
Comment on attachment 8514132 [details] [review] Patch V1 r=gduan, does the Gu failure relate to your patch?
Attachment #8514132 - Flags: review?(gduan) → review+
Thanks, I'll take a look at the Gu failure.
Patch updated to address the Gu (unit test) part. Please have a look if needed.
master, https://github.com/mozilla-b2g/gaia/commit/fb0cba5ff4724b9ad264dc6fdd7a2813ef3a91d7 -- Thanks for the review.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Triage: taking this as it stops non-english users to complete FTE, it's a pretty bad FTE.
blocking-b2g: 2.0? → 2.0+
Please request Gaia v2.0 and v2.1 approval on this when you get a chance.
Comment on attachment 8514132 [details] [review] Patch V1 [Approval Request Comment] [Bug caused by] (feature/regressing bug #): N/A, this is a new requirement. [User impact] if declined: With "wrong" build config, non-English users may not see keyboard show up. [Testing completed]: Yes, unit tests and build tests. [Risk to taking this patch] (and alternatives if risky): Low. [String changes made]: N/A
Requesting QA verification here and/or bug 1088013 on trunk before uplifting this on branches..
Qa-wanted: to check in the latest Central build
Issue DOES occur in latest Flame 2.2 build (Full Flash, nightly, 319 MB memory). Actual Results: Selecting a language in the FTE that has a Non-English keyboard will not summon the correct keyboard when user attempts to enter a Wifi network password during the FTE set-up. Screenshot attached: "loc_keyboard.png" Note: I used the STR listed in Comment 0. Device: Flame 2.2 BuildID: 20141112040208 Gaia: 5ae28ff11b982e2bd7d1aa097cda131536952bdc Gecko: 688f821edcd4 Gonk: 48835395daa6a49b281db62c50805bd6ca24077e Version: 36.0a1 (2.2) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
Issue still repro's
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(bbajaj)
QA Contact: ddixon
NI Rudy to help here.
Flags: needinfo?(bbajaj) → needinfo?(rlu)
Since the corresponding keyboard layout is not preloaded, it would fall back to English layout. So, if the keyboard would pop up with an English, it means this fix works. Note: the actual result in the original desc. is "The keyboard will not appear.". Duane, Would you mind to verify it again? Thank you.
Flags: needinfo?(rlu) → needinfo?(ddixon)
I apologize for the confusion. Issue is verified fixed in Flame 2.2 (Shallow Flash, tinderbox engineering build, 319 MB memory). Actual Results: Keyboard in FTE behaves correctly when language such as Magyar is selected. Device: Flame 2.2 BuildID: 20141112125016 Gaia: 65d593cdd9d88648045a30a63fc329b7bb5d340b Gecko: 66cdb18f36da Version: 36.0a1 (2.2) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
Verify passed, this issue can't be repro on Woodduck 2.0;Flame2.0&2.1. Attached: Verify_Woodduck_FTEkeyboard.mp4 Reproducing rate: 0/5 Woodduck 2.0 Build: Gaia-Rev 60146ec47cd38a8be8ed22e0116902eceb9ac067 Gecko-Rev cdfbe9866cf0b71b33454926638ce0cd8bb1fb00 Build-ID 20141117050313 Version 32.0 Flame 2.0 build: Gaia-Rev 086a668942292168f312b3bb53e275fa0886fab1 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/a57b299c5cf2 Build-ID 20141117000200 Version 32.0 Flame 2.1 build: Gaia-Rev 81160ad79e5b4c21967418dd63f1a1d08d77924e Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/3572aa3e6766 Build-ID 20141117001201 Version 34.0
You need to log in before you can comment on or make changes to this bug.