Closed Bug 1030094 Opened 6 years ago Closed 6 years ago

Skip and Done buttons not translated in the Enter PIN screen

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:2.0+, b2g-v2.0 verified, b2g-v2.1 verified)

VERIFIED FIXED
2.0 S6 (18july)
blocking-b2g 2.0+
Tracking Status
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: iacchi, Assigned: iliu)

References

Details

(Keywords: regression)

Attachments

(6 files)

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?
Keywords: qawanted
(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)
blocking-b2g: --- → 2.0?
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.
Component: Gaia::System → Gaia::System::Window Mgmt
Attached file 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.
Attachment #8446068 - Flags: review?(iliu)
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.
Attachment #8446068 - Flags: review?(iliu)
blocking-b2g: 2.0? → 2.0+
Comment on attachment 8446068 [details] [review]
patch

r+ with me, thanks for your effort.
Attachment #8446068 - Flags: review?(iliu) → review+
Duplicate of this bug: 1031276
2.0: https://github.com/mozilla-b2g/gaia/commit/2be065513239de415ed1d9ba1f10959e0cbeec07
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
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.
Flags: needinfo?(gmarty)
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.
Flags: needinfo?(gmarty)
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!
Flags: needinfo?(iliu)
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.
Flags: needinfo?(iliu)
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.
Duplicate of this bug: 1032961
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.
Duplicate of this bug: 1032998
Any updates here?
Hi Zibi, are you still working on this? Thanks.
Flags: needinfo?(gandalf)
(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.
Flags: needinfo?(gandalf)
Ian, could you take over?
Flags: needinfo?(iliu)
Okay, I try to make the issue reproduced locally. Or try to find some way for the test failed issue remotely.
Assignee: gandalf → iliu
Flags: needinfo?(iliu)
Target Milestone: --- → 2.0 S6 (18july)
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
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
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.
Flags: needinfo?(gandalf)
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
Attached image Buri 2.0, French
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
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...
Depends on: 1052299
Attachment #8472862 - Attachment mime type: text/plain → image/png
Flags: needinfo?(gandalf)
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
Status: RESOLVED → VERIFIED
Attached video VIDEO0090_Compress.MP4
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.