Closed Bug 1030094 Opened 6 years ago Closed 6 years ago
Skip and Done buttons not translated in the Enter PIN screen
29.21 KB, image/png
46 bytes, text/x-github-pull-request
|Details | Review|
21.71 KB, image/png
30.48 KB, image/png
31.66 KB, image/png
2.83 MB, video/mp4
Hi, this happens on a GP Keon, build of the 23rd of June (but it's the same for the ones before). When you're asked for the SIM PIN, the screen is translated except for the two buttons - Skip and Done. Francesco assures me that the string is translated, so this is either a GP build bug or a FFOS 2.0 bug.
I can confirm: this happens also on Flame with 2.1 where I flash my own build, so repo for strings is definitely correct and complete.
This should be the file https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/system_simcard_dialog.js#L94-L95 I don't see history changes recently that justify this change. Related to l10n.js refactor?
Component: Gaia::L10n → Gaia::System
Does this reproduce on a 2.0 Flame device? Can we get a screenshot of the bug?
(resetting target milestone, doesn't make much sense)
Target Milestone: 2.0 S4 (20june) → ---
(In reply to Francesco Lodolo [:flod] from comment #2) > I don't see history changes recently that justify this change. Related to > l10n.js refactor? Let's see... taking
Assignee: nobody → gandalf
Status: NEW → ASSIGNED
Some notes. Hamachi 1.4: screen is correctly localized Hamachi 2.0: buttons are not localized (title and label at the top are localized, like on master)
Ok, this is a regression from bug 964653. Both new dialogs - FXA and SimPIN are not waiting for l10n. I'm working on a patch.
This patch makes SIMCard and FXA code wait for l10n before they inject HTML. This fixes the bug on master. For 2.0 we will need to addtionally use mozL10n.translate in render because MutationObserver is not there. I'd like to first land this on master and then backport to 2.0. I also filed bug 1030280 which should allow us to remove the blocking on once in the future.
Ok, so I will need to update tests for that because they also don't wait for l10n. In a long term, I'd actually like to fix it properly by observing nodes injected before l10n resources are available. I filled bug 1030334. But for now and for 2.0 we need this patch.
Comment on attachment 8446068 [details] [review] patch Basically, the patch should be working fine as before. Because system dialog module will be ready and faster than Fxa, SimPin creating the instance of system dialog. System dialog does not wait l10n event during init state. This patch is okay for me, if the unit tests(3 test script) is still passed. Please set the review request to me, if these tests are ready. Thanks.
Comment on attachment 8446068 [details] [review] patch Tests passed, https://tbpl.mozilla.org/?tree=Gaia-Try&rev=c701603a0d5e - rerequesting r
Comment on attachment 8446068 [details] [review] patch r+ with me, thanks for your effort.
Attachment #8446068 - Flags: review?(iliu) → review+
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Additional fix for 2.0 bustage: v2.0: https://github.com/mozilla-b2g/gaia/commit/2cfd8b86765d537615deaa718bb27cfe51bed2df
It seems that the there's a bustage on 2.0 because of my patch: https://tbpl.mozilla.org/php/getParsedLog.php?id=42658915&tree=Mozilla-Aurora&full=1 I don't understand why someone is firind SimPinDialog.close and I can't find any place in our tests where it may happen and marionette log is absolutely not helpful (empty stack).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Reverted on 2.0 - https://github.com/mozilla-b2g/gaia/commit/91958625774ebe6c425adf322b09f1edf906578d It works on master. May need help to understand why it fails on 2.0.
Of the files your patch to 2.0 touched, one difference between master and 2.0 are that master also has bug 1007948 and bug 984146 landed. Of those, bug 1007948 seems more likely to be related. Maybe it needs uplifting to 2.0 as well? Needinfoing the auther of that other bug's patch.
Do you need me to provide a patch for the code fixing Bug 1007948 for v2.0? I can do that, but AFAICT it shouldn't have any impact on the bug discussed here.
I still can't reproduce this bug on my machine. I can't get marionette to test on the device, I'm not sure how to launch the particular test on desktop B2G, I can't find emulator builds and I can't build emulator builds (I filed bug 1032536). I have a solid idea on what's going on here - some code fires SimPinDialog.close before SimPinDialog is initialized. With the patch from this bug I postponed initialization of that until l10n is ready. Some code (maybe test?) attempts to close it without waiting for l10n. If anyone can help me debug this, or even get the stack trace to understand what launches this code, I'd appreciate it.
Ian, do you have time to help :grandalf on this? Thanks!
A quickly tracing for some code fires SimPinDialog.close. SimLock received 'ftuopen' event to close SimPinDialog(https://github.com/mozilla-b2g/gaia/blob/v2.0/apps/system/js/sim_lock.js#L58-L59). And 'ftuopen' event is fired from FtuLauncher(https://github.com/mozilla-b2g/gaia/blob/v2.0/apps/system/js/ftu_launcher.js#L59-L67). Looks like FtuLauncher/SimLock does not wait l10n event to init. But I don't see any code needed l10n in FtuLauncher/SimLock. I feel wired why Gaia/master is passed the test. The code base is not diff too much. Basically, a module which is no l10n function call, no needed to wait l10n for init. But, if the module will need to call a UI module(with l10n function call), do we have a better solution control the calling sequence? I think this kind of timing issue is more easily to occur in system app.
Maybe we should just allow for SimPinDialog.close to exit when this.simPinSystemDialog is null because the goal of that function is fulfilled?
Agree with the goal. Because SimPinDialog is not inited yet, it means there is no any layout needed to be closed. But I still feel wired for the failed test on tbpl. There are two directions we can speculate. 1) The callback of l10n once() is coming slowly on tbpl. 2) Other module(which is not waiting l10n once for init) init more quickly on tbpl. The better solution might be finding a way for handling calling sequence for a module with/without l10n init.
My guess is that it's #2. We can either try to identify which code is trying to close SimPinDialog before it started, and block that code as well, or accept that some test is closing the dialog without waiting for l10n, which is still ok.
Any updates here?
Hi Zibi, are you still working on this? Thanks.
(In reply to howie [:howie] from comment #31) > Hi Zibi, are you still working on this? Thanks. So, I fixed in on master, and I provided a patch for 2.0. The patch breaks one test and I cannot figure out how to reproduce this test locally. Which means that I cannot fix it. I can de-assign myself from the bug unless someone can help me reproduce it locally.
Ian, could you take over?
Okay, I try to make the issue reproduced locally. Or try to find some way for the test failed issue remotely.
Assignee: gandalf → iliu
Do a little bit change and run on TBPL test. https://github.com/mozilla-b2g/gaia/pull/21673
Looks Gaia unit test is passed on TBPL. But the JS integration test is failed in 'Homescreen navigation'. It should not be relative with the pr, I think. Because test failed of 'Homescreen navigation' is existed in recently build. I leave some comment for checking on GitHub. Gaia/v2.0: 5f8b1b8a2da9e3b531eee817a669f57fa4d9b9c6
The bug has been marked as fixed for Gaia 2.0, but with the 2.0 Keon builds (20140726), the texts are still in English.
ni? on myself to check that.
I do a manual test with following build version on Flame. It works for me. Steps: 1. after flashed device, go into FTU for language selection 2. select 繁體中文, click 'Next' ==> (Actual result 1) 3. see 'Enter PIN code' page, then click 'Skip' 4. finish FTU and go into home screen 5. click Dialler app ==> (Actual result 2) Actual result 1: Will see 'Enter PIN code' page with correct localised strings in FTU. Actual result 2: Will see 'Enter PIN code' page with correct localised strings in system dialog. ================= version ===================== Gaia 2e85678de2c8e13e585288d4cec7d6673cee17ee Gecko https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/6e37ecf873da BuildID 20140729160209 Version 32.0 ro.build.version.incremental=108 ro.build.date=Tue Jun 10 19:40:40 CST 2014 B1TC20011210
I've been able to reproduce on Buri 2.0: Gaia 2e85678de2c8e13e585288d4cec7d6673cee17ee Gecko https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/6e37ecf873da BuildID 20140730000206 Version 32.0 ro.build.version.incremental=324 ro.build.date=Thu Dec 19 14:04:55 CST 2013 Here are my STR: 1. Flash 2.0, the SIM prompt on FTU is properly localized. 2. Select French, go through the FTU 3. Reboot 4. Skip and Done buttons are not localized at reboot See attached screenshot. I also reproduced on Peak with latest 2.0 build
Duplicate of this bug: 1052295
I met this issue again on latest Flame v2.0 build: --> Skip and Done buttons not translated in the Enter PIN screen after reboot device. Test build: Gaia 6155d46822edc6f799141caa8cf86209fb623c34 Gecko https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/017e9d274f08 BuildID 20140812160201 Version 32.0 ro.build.version.incremental=109
Still problem in latest 2.0 build (Flame), at least for Czech locales...
Attachment #8472862 - Attachment mime type: text/plain → image/png
I tried to reproduce it on 2.0 branch from today, but it looks localizable on Flame, using pseudolocale. Can you guys confirm?
The build version works for me today. Gaia 59a670d40ad7f5966ec7fafcab0f05009bea97ab Gecko https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/de70f9a40834 BuildID 20140908160201 Version 32.0 ro.build.date Tue Jun 10 19:40:40 CST 2014 ro.bootloader L1TC20011210 ro.build.version.incremental 108
This issue has been successfully verified on Flame 2.0: Gaia-Rev 8d1e868864c8a8f1e037685f0656d1da70d08c06 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/c756bd8bf3c3 Build-ID 20141201000201 Version 32.0 Device-Name flame FW-Release 4.4.2 This issue has been successfully verified on Flame 2.1: Gaia-Rev ccb49abe412c978a4045f0c75abff534372716c4 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/18fb67530b22 Build-ID 20141201001201 Version 34.0 Device-Name flame FW-Release 4.4.2
You need to log in before you can comment on or make changes to this bug.