1030094 - Skip and Done buttons not translated in the Enter PIN screen

Status: VERIFIED FIXED

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

Description

[Iacopo Benesperi [:iacchi]]

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.

Comment 1

[Francesco Lodolo [:flod]]

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.

Comment 2

[Francesco Lodolo [:flod]]

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?

Comment 3

[Jason Smith [:jsmith]]

Does this reproduce on a 2.0 Flame device? Can we get a screenshot of the bug?

Comment 4

[Francesco Lodolo [:flod]]

Attachment: Screenshot on Flame master (2.1)

Comment 5

[Francesco Lodolo [:flod]]

(resetting target milestone, doesn't make much sense)

Comment 6

[Zibi Braniecki [:zbraniecki][:gandalf]]

(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

Comment 7

[Francesco Lodolo [:flod]]

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)

Comment 8

[Zibi Braniecki [:zbraniecki][:gandalf]]

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.

Comment 9

[Zibi Braniecki [:zbraniecki][:gandalf]]

Attachment: 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.

Comment 10

[Zibi Braniecki [:zbraniecki][:gandalf]]

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 11

[[e-mail], [e-mail]]

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 12

[Zibi Braniecki [:zbraniecki][:gandalf]]

Comment on attachment 8446068 [details] [review]
patch

Tests passed, https://tbpl.mozilla.org/?tree=Gaia-Try&rev=c701603a0d5e - rerequesting r

Comment 13

[[e-mail], [e-mail]]

Comment on attachment 8446068 [details] [review]
patch

r+ with me, thanks for your effort.

Comment 15

[Zibi Braniecki [:zbraniecki][:gandalf]]

Commit: https://github.com/mozilla-b2g/gaia/commit/755229ba41d76f385a43b9e5dcf2118a2094e24c
Merge: https://github.com/mozilla-b2g/gaia/commit/04a24ef022b1b7ea52fa21e943bed92ff09a0a77

Comment 16

[Zibi Braniecki [:zbraniecki][:gandalf]]

2.0: https://github.com/mozilla-b2g/gaia/commit/2be065513239de415ed1d9ba1f10959e0cbeec07

Comment 17

[Zibi Braniecki [:zbraniecki][:gandalf]]

Additional fix for 2.0 bustage:

v2.0: https://github.com/mozilla-b2g/gaia/commit/2cfd8b86765d537615deaa718bb27cfe51bed2df

Comment 18

[Zibi Braniecki [:zbraniecki][:gandalf]]

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).

Comment 19

[Zibi Braniecki [:zbraniecki][:gandalf]]

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.

Comment 20

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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.

Comment 21

[Guillaume Marty [: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.

Comment 22

[Zibi Braniecki [:zbraniecki][:gandalf]]

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.

Comment 23

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Ian, do you have time to help :grandalf on this? Thanks!

Comment 24

[[e-mail], [e-mail]]

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.

Comment 25

[Zibi Braniecki [:zbraniecki][:gandalf]]

Maybe we should just allow for SimPinDialog.close to exit when this.simPinSystemDialog is null because the goal of that function is fulfilled?

Comment 26

[[e-mail], [e-mail]]

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.

Comment 28

[Zibi Braniecki [:zbraniecki][:gandalf]]

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.

Comment 30

[Gregor Wagner [:gwagner]]

Any updates here?

Comment 31

[howie [:howie]]

Hi Zibi, are you still working on this? Thanks.

Comment 32

[Zibi Braniecki [:zbraniecki][: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.

Comment 33

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Ian, could you take over?

Comment 34

[[e-mail], [e-mail]]

Okay, I try to make the issue reproduced locally. Or try to find some way for the test failed issue remotely.

Comment 35

[[e-mail], [e-mail]]

Do a little bit change and run on TBPL test.

https://github.com/mozilla-b2g/gaia/pull/21673

Comment 36

[[e-mail], [e-mail]]

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

Comment 37

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

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.

Comment 38

[Zibi Braniecki [:zbraniecki][:gandalf]]

ni? on myself to check that.

Comment 39

[[e-mail], [e-mail]]

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

Comment 40

[Théo Chevalier]

Attachment: 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

Comment 42

[Peipei Cheng (needinfo if you need my action)]

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

Comment 43

[Marek Raida]

Attachment: 2014-08-14-07-15-30-pin-czech.png

Still problem in latest 2.0 build (Flame), at least for Czech locales...

Comment 44

[Zibi Braniecki [:zbraniecki][:gandalf]]

Attachment: screenshot from v2.0 on Flame

I tried to reproduce it on 2.0 branch from today, but it looks localizable on Flame, using pseudolocale.

Can you guys confirm?

Comment 45

[[e-mail], [e-mail]]

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

Comment 46

[Elie]

Attachment: 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