988689 - [Sora][LABEL] "Start your phone tour" tutorial is in English

Status: RESOLVED FIXED

(Core :: IPC, defect, P1)

Description

[sync-1]

Defect description:
 ===================
 "Start your phone tour" tutorial is in English, Also part of Enable Geolocation text description is in English.
 
 
 Steps to reproduce:
 ===================
 1. First power up
 2. Phone in Spanish
 3. Follow instructions detailed on the different screens appearing during this first power up (like language, time & date & zone, Geolocation, Start your phone tour tutorial...)
 
 Expected result:
 =================
 All information must be displayed in Spanish according to language selected previously.
 
 
 Regards,
 Olga BALLEGA

Comment 1

[sync-1]

Attachment: TL-2

Comment 2

[sync-1]

Attachment: Start your phone tutorial _2

Comment 3

[sync-1]

Attachment: the picture of the Spaish

Comment 4

[sync-1]

Attachment: TL-4

Comment 5

[sync-1]

Attachment: TL-3

Comment 6

[sync-1]

Attachment: TL-1

Comment 7

[sync-1]

Attachment: TL-2

Comment 8

[sync-1]

Attachment: Start your phone tutorial _2

Comment 9

[sync-1]

Attachment: the picture of the Spaish

Comment 10

[sync-1]

Attachment: TL-4

Comment 11

[Mingming ZHAO]

Firefox OS v1.3
Mozilla build ID: 20140312164001

Please set the default language is Spanish. -> Press "Factory reset" -> the phone is reset -> The FTU is diaplayed -> The Spanish is checked by default -> the "Next" button and title is in English (KO) -> press "Next", all the FTU page is in English (KO) -> finish FTU, the homescreen is in Spanish

This is a strange issue. Only the PIO handset can reproduce, the proto handset is OK!

Comment 12

[sync-1]

Attachment: TL-3

Comment 13

[sync-1]

Attachment: Wizard_v10I.zip

Comment 14

[sync-1]

Attachment: Geolocation description

Comment 15

[sync-1]

Attachment: Start your phone tutorial _1

Comment 16

[sync-1]

Attachment: TL-1

Comment 17

[sync-1]

Attachment: Antonio V10I.png

Comment 18

[sync-1]

Attachment: TL-5

Comment 19

[sync-1]

Attachment: Wizard_v10I.zip

Comment 20

[sync-1]

Attachment: TL-2

Comment 21

[sync-1]

Attachment: Geolocation description

Comment 22

[Jason Smith [:jsmith]]

Can someone confirm this on the Moz side on 1.3?

Comment 23

[sarsenyev]

Couldn't reproduce it on Buri 1.3 from my side. 
After resetting the device in FTE all informaton is shown according chosen language, if Spanish is chosen all info will be on Spanish, If English is chosen in English

Leaving QA Wanted if this issue specific for Sora device

1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140328004002
Gaia: 523196662f4d19c7898d5f4773da020c39cfe57e
Gecko: aa1d48ab3715
Version: 28.0
Firmware Version: v1.2-device.cfg

Comment 24

[Viga]

per comment 23 
Leaving QA Wanted if this issue specific for Sora device

Just have someone test it on sora PIO device.

Comment 25

[Viga]

One more, It doesn't need to be PIO. Just Sora device can reproduce it.
At first start up, Spanish is select on default(Not centered, seprate bug 989322).
The button shows in English "Next".  
But when you long press the power key, the menu comes up with Spanish.
If you can't reporduce. Can someone points out tecnically where shuold I check?

Thanks

Comment 26

[Jason Smith [:jsmith]]

(In reply to weijia from comment #24)
> per comment 23 
> Leaving QA Wanted if this issue specific for Sora device
> 
> Just have someone test it on sora PIO device.

The Kirkland team doesn't have access to a Sora device. We don't have builds for them either, so we can't investigate this on our side.

Comment 27

[Viga]

If can't reproduce, can you please find someone to point out the problem base on 
what I described? 
"At first start up, Spanish is select on default(Not centered, seprate bug 989322).
The button shows in English "Next".  
But when you long press the power key, the menu comes up with Spanish."

Comment 28

[Beatriz Rodríguez [:brg]]

(In reply to Mingming ZHAO from comment #11)
> Firefox OS v1.3
> Mozilla build ID: 20140312164001
> 
> Please set the default language is Spanish. -> Press "Factory reset" -> the
> phone is reset -> The FTU is diaplayed -> The Spanish is checked by default
> -> the "Next" button and title is in English (KO) -> press "Next", all the
> FTU page is in English (KO) -> finish FTU, the homescreen is in Spanish
> 
I think Fernando Campo has some clues about the reason of the issue.

Comment 29

[Beatriz Rodríguez [:brg]]

(In reply to sarsenyev from comment #23)
> Couldn't reproduce it on Buri 1.3 from my side. 
> After resetting the device in FTE all informaton is shown according chosen
> language, if Spanish is chosen all info will be on Spanish, If English is
> chosen in English
> 

In order to reproduce this issue, you need to use a different language as "default" than English. Sora device work fine if default language is English.
This is not only reproducible in Sora but also other vendor devices that set a different "default" language.

Comment 30

[Fernando Campo (:fcampo)]

(In reply to Mingming ZHAO from comment #11)
> Firefox OS v1.3
> Mozilla build ID: 20140312164001
> 
> Please set the default language is Spanish. -> Press "Factory reset" -> the
> phone is reset -> The FTU is diaplayed -> The Spanish is checked by default
> -> the "Next" button and title is in English (KO) -> press "Next", all the
> FTU page is in English (KO) -> finish FTU, the homescreen is in Spanish
> 
> This is a strange issue. Only the PIO handset can reproduce, the proto
> handset is OK!
I don't have a Sora device to test with, but based on what I read here, I'd like you to test this:
- After factory reset, with spanish as default, and spanish chosen on the language list, change to English and back to Spanish. 
If then the FTU is properly translated to spanish, the reason for this bug might be that the localization ready event is not triggered properly, so the app is started on the wrong language.

[https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/ftu/js/app.js#L53]

Hope it helps!

Comment 31

[Viga]

(In reply to Fernando Campo (:fcampo) from comment #30)
> (In reply to Mingming ZHAO from comment #11)
> > Firefox OS v1.3
> > Mozilla build ID: 20140312164001
> > 
> > Please set the default language is Spanish. -> Press "Factory reset" -> the
> > phone is reset -> The FTU is diaplayed -> The Spanish is checked by default
> > -> the "Next" button and title is in English (KO) -> press "Next", all the
> > FTU page is in English (KO) -> finish FTU, the homescreen is in Spanish
> > 
> > This is a strange issue. Only the PIO handset can reproduce, the proto
> > handset is OK!
> I don't have a Sora device to test with, but based on what I read here, I'd
> like you to test this:
> - After factory reset, with spanish as default, and spanish chosen on the
> language list, change to English and back to Spanish. 
> If then the FTU is properly translated to spanish, the reason for this bug
> might be that the localization ready event is not triggered properly, so the
> app is started on the wrong language.
> 
> [https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/ftu/js/
> app.js#L53]
> 
> Hope it helps!

Thanks. I'll have a try.

Comment 32

[Mingming ZHAO]

(In reply to Fernando Campo (:fcampo) from comment #30)
> I don't have a Sora device to test with, but based on what I read here, I'd
> like you to test this:
> - After factory reset, with spanish as default, and spanish chosen on the
> language list, change to English and back to Spanish. 
> If then the FTU is properly translated to spanish, the reason for this bug
> might be that the localization ready event is not triggered properly, so the
> app is started on the wrong language.
> 
> [https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/ftu/js/
> app.js#L53]
> 
> Hope it helps!

Hi thanks for you help, the behavior of the handset as you said:

- After factory reset, with spanish as default, and spanish chosen on the
language list, change to English and back to Spanish, then the FTU is properly translated to spanish.

But how should we solve it?

Comment 33

[Mingming ZHAO]

> (In reply to Fernando Campo (:fcampo) from comment #30)

Hi, the localization ready event is not triggered indeed. this is the log: 

E/GeckoConsole(  918): Content JS LOG at app://communications.gaiamobile.org/ftu/js/app.js:52 in showBody: zmm:es:navigator.mozL10n.ready
E/GeckoConsole(  918): Content JS LOG at app://communications.gaiamobile.org/ftu/js/app.js:53 in showBody: zmm:es:navigator.mozL10n.language.code=en-US
E/GeckoConsole(  918): Content JS LOG at app://communications.gaiamobile.org/ftu/js/app.js:54 in showBody: zmm:es:navigator.mozL10n.language.direction=ltr
E/GeckoConsole(  918): Content JS LOG at app://communications.gaiamobile.org/ftu/js/app.js:56 in showBody: zmm:es:AppManager.isLocalized=undefined
E/GeckoConsole(  918): Content JS LOG at app://communications.gaiamobile.org/ftu/js/language.js:27 in onResponse: zmm:es:self._currentLanguage=es


We get the value "navigator.mozL10n.language.code=en-US", but indeed the default language vaule is "self._currentLanguage=es"

Please help to solve this. Thanks a lot!

Comment 34

[Beatriz Rodríguez [:brg]]

Thanks Fernando and Mingming for the investigation here.
I have changed the component to FTU (feel free to modify if I am wrong).
This is repored as certification blocker. Nominating accordingly.

Comment 35

[Fernando Campo (:fcampo)]

Taking a look.

But I'm gonna need a contact with a Sora device to test the patch, as I don't have access to any.

Comment 36

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

(In reply to Fernando Campo (:fcampo) from comment #35)
> Taking a look.
> 
> But I'm gonna need a contact with a Sora device to test the patch, as I
> don't have access to any.

Hi Fernando, if you can not find a sora device near you, you can just attach your patch here, I will ask our partner to help to test the patch

Comment 37

[isabelrios]

Hi Vance, 
Already talked with Fernando. I have a sora device, will help him to test the patch. Thanks

Comment 38

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

(In reply to Isabel Rios [:isabel_rios] from comment #37)
> Hi Vance, 
> Already talked with Fernando. I have a sora device, will help him to test
> the patch. Thanks

Oh that is great, thanks for your help Isabel!

Comment 39

[Fernando Campo (:fcampo)]

Attachment: Link to PR - https://github.com/mozilla-b2g/gaia/pull/18159

After testing different things, I don't think that the error is on FTU app.

The patch is changing shared/l10n.js, as I think is triggering the ready listener assuming that english is the default language.
Isabel already tested it and it seems to work. Any other testing with other devices is welcome.

I'm not familiar with the library, so maybe I'm missing something and doing a stupid thing by reading the setting apart from adding the listener, could you please check it, Stas.

Comment 40

[Staś Małolepszy :stas]

Comment on attachment 8404620 [details] [review]
Link to PR - https://github.com/mozilla-b2g/gaia/pull/18159

This doesn't look right, I'm afraid.  When FTU launches, the language.current settings and navigator.language should be the same.  In your patch | navigator.mozL10n.language.code = req.result[key]; | will simply rerun  | navigator.mozL10n.ctx.requestLocales(); |, which was just called inside of initLocale() a few lines before.

If this appears to fix the problem, maybe the language.current settings and navigator.language are not in sync on the tested device?

I only have a Keon to test with, so it's hard for me to know what's going on.

Also, is this broken on all branches, or just 1.3?  Note that a major refactor of l10n.js landed last week on master, so this will need two different patches if you want to uplift it to 1.3 and 1.4.

Comment 41

[Staś Małolepszy :stas]

(In reply to Staś Małolepszy :stas from comment #40)

> I only have a Keon to test with, so it's hard for me to know what's going on.

I tested 1.5, 1.4 and 1.3 on Keon and couldn't reproduce.

Comment 42

[Fernando Campo (:fcampo)]

(In reply to Staś Małolepszy :stas from comment #40)
> This doesn't look right, I'm afraid.  When FTU launches, the
> language.current settings and navigator.language should be the same.  
As seen in comment 33, this is not happening. I assumed it was a problem from l10n when loading the values.

> In your patch | navigator.mozL10n.language.code = req.result[key]; | will
> simply rerun  | navigator.mozL10n.ctx.requestLocales(); |, which was just
> called inside of initLocale() a few lines before.
> 
> If this appears to fix the problem, maybe the language.current settings and
> navigator.language are not in sync on the tested device?
I really have no idea of when this values are set, can you give me some guidance in here? 
Could it be a build thing instead of Gaia issue?

> 
> I only have a Keon to test with, so it's hard for me to know what's going on.
I think that it happens in any device, as long as the default language is set to any other than english.

Maybe Mingming Zhao can tell us how exactly are they testing it, so we follow the same process. 
In comment 11 I see there's a build number and 1.3 version, but I assumed it was happening also in master. Can we confirm this?
Can someone confirm this?

Comment 43

[Fernando Campo (:fcampo)]

Ok, Isabel just confirmed that is working nicely in master, so maybe that refactoring of l10n fixed it. I'm gonna try to check what is exactly happening, and if applying the refactor to 1.3 would solve the issue.

Stas, that refactor was the bug 914414, right? I'm afraid it is too big to uplift it to 1.3...

Comment 44

[Staś Małolepszy :stas]

Fernando: yes, it was bug 914414.  I know it's a big feature, but it would still be helpful to know if it fixes this bug on v1.3.  Applying the patch should be easy:  the changes outside of shared/js/l10n.js are minimal (you only need build/l10n.js and build/webapp-optimize.js).  Let's see if it helps, and if it does, it might be easier to pinpoint the cause in v1.3's l10n.js.

Comment 45

[Viga]

(In reply to Staś Małolepszy :stas from comment #40)
> Comment on attachment 8404620 [details] [review]
> Link to PR - https://github.com/mozilla-b2g/gaia/pull/18159
> 
> This doesn't look right, I'm afraid.  When FTU launches, the
> language.current settings and navigator.language should be the same.  In
> your patch | navigator.mozL10n.language.code = req.result[key]; | will
> simply rerun  | navigator.mozL10n.ctx.requestLocales(); |, which was just
> called inside of initLocale() a few lines before.
> 
> If this appears to fix the problem, maybe the language.current settings and
> navigator.language are not in sync on the tested device?
> 
> I only have a Keon to test with, so it's hard for me to know what's going on.
> 
> Also, is this broken on all branches, or just 1.3?  Note that a major
> refactor of l10n.js landed last week on master, so this will need two
> different patches if you want to uplift it to 1.3 and 1.4.
I think it's sync problem, Please see my Test log at 

http://pastebin.mozilla.org/4816704
The first run can re-produce this problem.(Button in English)
Do nothing, then restart, all the button translated to ES.

Comment 46

[Fernando Campo (:fcampo)]

Hi Stas,

After many conflicts, I've finally applied the patch to v1.3 [commit 89691d2d1a98aef25f3937fbe995413a5d943abe], without much luck. After a reset-gaia, doesn't fix the issue.

Also, I tried what weijia did (after first run, just reboot from phone), and this second time it worked.
So, as a second run of initLocale() fix the issue on my first patch, I'm more inclined to think now that is a sync issue.

Do you know when are this values set for the first time? Is it during the build creation or gaia?

As this is happening only in 1.3, and my hamachi can't reproduce it but other devices can (comment 22), maybe is the build process? I'm out of ideas if not.

Comment 47

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

I verified that your merge: https://github.com/fcampo/gaia/commit/52897aab585b7a0976ca3d7dd87779f42fa1d77e is correct.

I cannot reproduce it on Keon and I don't have access to Sora. If I can get my hands on Sora I should be able to help with this bug.

Comment 48

[Viga]

(In reply to Zbigniew Braniecki [:gandalf] from comment #47)
> I verified that your merge:
> https://github.com/fcampo/gaia/commit/
> 52897aab585b7a0976ca3d7dd87779f42fa1d77e is correct.
> 
> I cannot reproduce it on Keon and I don't have access to Sora. If I can get
> my hands on Sora I should be able to help with this bug.

Can you please check the log in my comment45 first?

Comment 49

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

(In reply to weijia from comment #48)
> Can you please check the log in my comment45 first?

It would be helpful to see which apps the log messages come from. 

Also, I see that you're testing "document.documentElement.lan" instead of "document.documentElement.lang".

Comment 50

[Viga]

(In reply to Zbigniew Braniecki [:gandalf] from comment #49)
> (In reply to weijia from comment #48)
> > Can you please check the log in my comment45 first?
> 
> It would be helpful to see which apps the log messages come from. 
> 
> Also, I see that you're testing "document.documentElement.lan" instead of
> "document.documentElement.lang".

It's in v1.3 branch. And It just at start up. I don't do anything ,touch any buttons.
Of course, it's in FTU(FTE).

Comment 51

[Viga]

sorry for the typo,
Updated one http://pastebin.mozilla.org/4825412

for the document.documentElement.lang log.

Comment 52

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

can you use ordinary console.log instead of consoleLog? That would give us app URI for each log message. It seems that you're loading 6 documents in your log and the last one does not have lang attribute assigned.

Comment 53

[Viga]

(In reply to Zbigniew Braniecki [:gandalf] from comment #52)
> can you use ordinary console.log instead of consoleLog? That would give us
> app URI for each log message. It seems that you're loading 6 documents in
> your log and the last one does not have lang attribute assigned.
OK, a minute please.

Comment 54

[Viga]

http://pastebin.mozilla.org/4825638

Comment 55

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Zbigniew -

The log you ask for is available per Comment#54, thanks!

Comment 56

[Viga]

From the log, we are so sure it's a sync problem. System can get navigator.language right
E/GeckoConsole( 1289): Content JS LOG at app://system.gaiamobile.org/shared/js/l10n.js:1168 in l10nStartup: l10n navigator.language  es

but 

E/GeckoConsole( 1397): Content JS LOG at app://communications.gaiamobile.org/ftu/gaia_build_index.js:133 in l10nStartup: l10n navigator.language  en-US   Not right

Comment 57

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

Yeah, exactly. system, keyboard and homescreen see es, communications sees en-US.

Comment 58

[Viga]

Thanks for your feedback.
So I think can we confirm that comment 46 is available?

Comment 59

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

it seems to my untrained eye that mozSettings (source for navigator.language) is inconsistent here, I'm not sure why it can be.

CC'ing Axel.

Comment 60

[Axel Hecht [:Pike]]

I wonder if this is a race between gaia setting the locale and gaia asking for the locale.

Could you try to set general.useragent.locale to 'es' and intl.accept_languages to 'es, en-US, en' before booting up?

Comment 61

[Viga]

Is it a uers.js prefs? or in the code. can you tell me more?

Comment 62

[Axel Hecht [:Pike]]

user.js should work.

Comment 63

[Viga]

Log with prefs in user.js
pref("general.useragent.locale", "es");
pref("intl.accept_languages", "es, en-US, en" );

http://pastebin.mozilla.org/4830747

The  navigator.language is null at first run.

Comment 64

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

wow. never saw empty navigator.language before.

Comment 65

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

(In reply to Zbigniew Braniecki [:gandalf] from comment #64)
> wow. never saw empty navigator.language before.

Hi, this issue can also be reproduced on Flame, do you have a Flame device with you?

Thanks

Comment 66

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

I do not have Flame device. I only have Keon/Peak.

Comment 67

[Viga]

Axel 
From log  http://pastebin.mozilla.org/4825638
Line 31 36 41 49 57. We can see navigator.language has different values.

Why this happen? Where I can check this problem?

Comment 68

[Fernando Campo (:fcampo)]

Could this have something to do with bug 999163?

Comment 69

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

It should not, l10n.js follows navigator.language, so this should not affect this bug, but until I get my hands on Flame, weijia, would you be able to test this patch?

Comment 70

[Viga]

(In reply to Zbigniew Braniecki [:gandalf] from comment #69)
> It should not, l10n.js follows navigator.language, so this should not affect
> this bug, but until I get my hands on Flame, weijia, would you be able to
> test this patch?

Still re-produced with that patch.
I think problem is that gaia gets wrong navigator.language 
In settings.json language.current set to 'es'. But navigator.language changes.

Comment 71

[Fernando Campo (:fcampo)]

(In reply to Zbigniew Braniecki [:gandalf] from comment #69)
> It should not, l10n.js follows navigator.language, so this should not affect
> this bug, but until I get my hands on Flame, weijia, would you be able to
> test this patch?
where exactly is 'navigator.language' set during the initializing process?
Is defaulted to some value?

(In reply to Axel Hecht [:Pike] from comment #60)
> I wonder if this is a race between gaia setting the locale and gaia asking
> for the locale.
I'm not familiar with the whole translating process, so sorry if I say something stupid, but shouldn't we check for the 'language.current' as a fallback if navigator.language' is undefined when we call 'initLocales()'?

Comment 72

[Albert [:albert]]

I've been reviewing the build process to ensure that it is ok and it seems to be fine. Doing more testing I'm not able to reproduce with hamachi but zte open does.

While hamachi gets es from 'navigator.language', zte gets en-US, so it is loading english locales. 'navigator.language' gets the value from the 'intl.accept_languages' localized property.
https://mxr.mozilla.org/mozilla-central/source/dom/base/Navigator.cpp#363

That property is defined as a localized resource, so it is obtained at Preferences.cpp through the GetComplexValue method of nsPrefBranch.cpp:
https://mxr.mozilla.org/mozilla-central/source/modules/libpref/src/Preferences.cpp#1460
https://mxr.mozilla.org/mozilla-central/source/modules/libpref/src/nsPrefBranch.cpp#213

Having a look to the GetComplexValue we can see that localized properties come from the default properties file or from the loaded preferences if it is defined.

In hamachi the property is loaded from preferences and its value is "es, en-US, en". On the other hand, the zte open didn't find the property and load it from the default file at https://mxr.mozilla.org/mozilla-central/source/toolkit/locales/en-US/chrome/global/intl.properties#33 which returns "en-US, en".

I think the problem is that settings are still not loaded when the ftu is launched, so 'navigator.language' has the default value "en-US, en".

I'll continue debugging..

Comment 73

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

I just got tarako device and tried to reproduce it here. No luck. It seems to work just fine in all scenarios.

Comment 74

[Axel Hecht [:Pike]]

No idea either.

Comment 75

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

I will get access to flame on Tue and I'll try to reproduce it there.

Comment 76

[sync-1]

Dears we are able to reproduce the issue in v127
 
 Please note that this is a BLOCKING issue for Telefonica Spain.
 
 We need to address it asap.

Comment 77

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

I'm one of the people best suited to debug this since I'm one of the owners of l10n.js mpdile in Gaia. If I can get any device that is affected I can work on that tomorrow. I'm in SF.

Comment 78

[Jack Liu]

Hi Vance, 

can you help to push it forward?

Thanks.

Comment 79

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

(In reply to Jack Liu from comment #78)
> Hi Vance, 
> 
> can you help to push it forward?
> 
> Thanks.

Hi Jack -

The thing is, this issue only happens on TCL devices(Sora, Flame), so now we are waiting for our guys in SF to get Flame to do further investigation

Thanks

Vance

Comment 80

[Albert [:albert]]

In open 2 I see a different problem than the one of comment 51.

For me the "navigator.language" is "en-US". It seems to be a bug with preferences API because it doesn't find a user pref at https://mxr.mozilla.org/mozilla-central/source/modules/libpref/src/nsPrefBranch.cpp#232 , so it is loading the default "intl.accept_languages" property

Comment 81

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

hi all, 

I just got a flame device and was able to reproduce this bug on gaia master!

My STR:

1) make clean && MOZILLA_OFFICIAL=1 GAIA_DEFAULT_LOCALE=fr make production
2) Wait for the FTU to start.

Current result:

Spanish is selected, but all the content is in English

Expected result:

Spanish selected, content in spanish

Fernardo: I can take this bug if you're ok with this.

Comment 82

[Viga]

Finally, it can be reproduced on your side. Anymore helps just let me know.
Thanks.

Comment 83

[Noemí Freire (:noemi)]

(In reply to Zbigniew Braniecki [:gandalf] from comment #81)

> Fernardo: I can take this bug if you're ok with this.

Hi,

Fernando will be on PTO in the following days, please, feel free to take it, . Thanks!

Comment 84

[Albert [:albert]]

I think there is a problem with the singleton in the "Preferences" class of libpref, that singleton is creating two instances.

When system boots, XRE_MainRun() launches the nsDefaultCLH (command line processor) which is setting up and loads "shell.html". That html is the responsible to load "settings.js" and "shell.js". So "shell.js" is initializated while "settings.js" set listeners and init properties, once "settings.js has done his job it starts the shell. All this stuff is preformed under b2g process and it creates an instance of preferences using the Preferences singleton.

Later, when Nuwa is created and there is some access to preferences, so the service is requested in order to get an instance, the singleton is creating a new instance instead of returning the one created for the b2g proces, which is configured with the preferences.

Some logs at http://pastebin.mozilla.org/5017065

Maybe when Nuwa is forked, the instance of preferences (with preferences configured) does not exist yet in b2g and this is the reason why it is created again but does not contain configured settings.

Does it make sense?

Comment 85

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

I can no longer reproduce this bug on Flame.

I tried:
 - Gecko 28 (gaia 1.3)
 - Gecko 30 (gaia 1.4)
 - Gecko 32 (gaia 2.0)

I also tried some combinations of gaia and gecko and downloaded some pvt builds to see if my build config changes something.

I believe it must be a race condition, and if :albert's hypothesis is correct, it's way below the l10n.js level.

Unless I can get a device on which I can reproduce the bug, I'm not able to help further.

I asked gwagner to look into the preferences desync hypothesis.

Comment 86

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

Tried running this a few times using b2g-desktop oop, can't repro. However, if it's a race condition, could be something we'd have to run many times. Should we try an integration test?

Comment 87

[Gregor Wagner [:gwagner]]

I can't reproduce this bug on the flame either. We have to wait for a sora device.

Comment 88

[Gregor Wagner [:gwagner]]

Can we get a logcat when this reproduces? Is it in any of the attachments?

Comment 89

[Jason Smith [:jsmith]]

(In reply to Gregor Wagner [:gwagner] from comment #88)
> Can we get a logcat when this reproduces? Is it in any of the attachments?

sync-1 - Can you get a logcat for this bug or point out which attachment has the log?

Comment 90

[Gregor Wagner [:gwagner]]

It reproduces with a 1.3 build on a flame.
The first process gets english and the 2nd one gets french here if we set the gaia build pref to french: https://github.com/mozilla-b2g/gaia/blob/v1.3/shared/js/l10n.js#L1160

Seems like a race condition when we propagate the language via the settings api.
Vivien, I assume you tried to fix similar bugs here: http://hg.mozilla.org/mozilla-central/annotate/35f9431188ca/b2g/chrome/content/settings.js#l91

Can't we just set the pref in the gaia build process instead of mirroring it via the settings api during startup?

Comment 91

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

I tested gecko 28 and gaia 1.3 on Flame and was not able to reproduce it.

Comment 92

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

gregor: can you provide some more detail instruction on how to reproduce it on flame?

Gecko/Gaia changesets and gaia's make flags would help.

Comment 93

[Gregor Wagner [:gwagner]]

(In reply to Zbigniew Braniecki [:gandalf] from comment #92)
> gregor: can you provide some more detail instruction on how to reproduce it
> on flame?
> 
> Gecko/Gaia changesets and gaia's make flags would help.

My setup:
1.3 tip from https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/ and gaia 1.3 branch.

STR: make clean && MOZILLA_OFFICIAL=1 GAIA_DEFAULT_LOCALE=fr make production

The checkbox is on french but the language is English.

Comment 94

[Gregor Wagner [:gwagner]]

Attachment: Set pref during buildtime

This fixes the problem for me. The language depends on a pref and we rely on a setting to set the actual pref. This is racy.

Comment 95

[Gregor Wagner [:gwagner]]

Comment on attachment 8416670 [details] [review]
Set pref during buildtime

Not sure who the right person for review is here.

Comment 96

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

That's awesome! Can we remove hacks like this then http://hg.mozilla.org/mozilla-central/annotate/35f9431188ca/b2g/chrome/content/settings.js#l91 ?

Comment 97

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

The issue seems to me that the Gecko build is not done properly. Are you building a *Gecko* multi-locale build has explained in https://developer.mozilla.org/en-US/Firefox_OS/Building ?

Just building Gaia with the right flag is not enough for the moment, as some parts of the localization subsystem still lives in Gecko.

Comment 98

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 8416670 [details] [review]
Set pref during buildtime

Cancelling the review until the Gecko question is answered.

Comment 99

[Viga]

(In reply to Vivien Nicolas (:vingtetun) (:21) (NOT reading bugmails, needinfo? please) from comment #97)
> The issue seems to me that the Gecko build is not done properly. Are you
> building a *Gecko* multi-locale build has explained in
> https://developer.mozilla.org/en-US/Firefox_OS/Building ?
> 
> Just building Gaia with the right flag is not enough for the moment, as some
> parts of the localization subsystem still lives in Gecko.

Yes we are. At least I build as the Doc said. So, please review [:gwagner]'s path

Comment 100

[Albert [:albert]]

(In reply to Gregor Wagner [:gwagner] from comment #95)
> Comment on attachment 8416670 [details] [review]
> Set pref during buildtime
> 
> Not sure who the right person for review is here.

The patch doesn't fix the bug for me, however it is not 100% reproducible.

Comment 101

[Viga]

(In reply to Albert [:albert] from comment #100)
> (In reply to Gregor Wagner [:gwagner] from comment #95)
> > Comment on attachment 8416670 [details] [review]
> > Set pref during buildtime
> > 
> > Not sure who the right person for review is here.
> 
> The patch doesn't fix the bug for me, however it is not 100% reproducible.

I tried, doesn't fix for me either. Comment 39  Fernando Campo's patch resolve the problem for me.

Comment 102

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

What are the options to get sora device either in Paris, Warsaw or San Francisco office for debugging? The patch from comment 39 is a dirty hack workaround. Not a fix.

And it seems that the manifestation we can reproduce with Flame is different than what you get with Sora.

Comment 103

[Gregor Wagner [:gwagner]]

(In reply to Zbigniew Braniecki [:gandalf] from comment #102)
> What are the options to get sora device either in Paris, Warsaw or San
> Francisco office for debugging? The patch from comment 39 is a dirty hack
> workaround. Not a fix.
> 
> And it seems that the manifestation we can reproduce with Flame is different
> than what you get with Sora.

We should have one in the SF office by tomorrow (Monday).

Comment 104

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to weijia from comment #99)
> (In reply to Vivien Nicolas (:vingtetun) (:21) (NOT reading bugmails,
> needinfo? please) from comment #97)
> > The issue seems to me that the Gecko build is not done properly. Are you
> > building a *Gecko* multi-locale build has explained in
> > https://developer.mozilla.org/en-US/Firefox_OS/Building ?
> > 
> > Just building Gaia with the right flag is not enough for the moment, as some
> > parts of the localization subsystem still lives in Gecko.
> 
> Yes we are. At least I build as the Doc said. So, please review [:gwagner]'s
> path

What Gregor's patch is doing should have already been done if Gecko is built correctly. The fact that the patch does not solve your issue probably means something else is going on here.

It's likely a sync issue between the pref of the master process and the prefs of the content processes.

Comment 105

[:gerard-majax]

I'll have a look at this.

Comment 106

[Albert [:albert]]

There is a sync preferences problem caused by the nuwa process clone for communications (ftu).

When b2g process starts it creates nuwa, launches communications and listens for preferences changes in order to send an update IPC message to child processes (nuwa and running apps).

Usually, b2g creates nuwa, launches communications, receives an update for intl.accept_languages and send an update IPC message to both nuwa and communications, then ftu is aware of the preference update and all works as expected.

But sometimes, communications is launched later, after sending the update IPC message from b2g and before nuwa receives the message. In that case, communications doesn't know that intl.accept_languages has changed and gets an outdated value.

I uploaded logs for both scenarios:
- Success: http://pastebin.mozilla.org/5080389
- Fail:    http://pastebin.mozilla.org/5080393

In order to fix it, we can add some IPC messages to sync main process and nuwa in order to avoid to miss some messages, the flow between both processes can be:

main  ----- PrepareToAdd  -----> nuwa
main <----- StopSending   -----  nuwa
main  ----- AddNewProcess -----> nuwa

Since the flow is completed, main process will not send new messages to nuwa (it should queue new ones) until nuwa does the fork and responds with "NuwaReady".

Comment 107

[[:fabrice] Fabrice Desré]

Cervantes, Patrick, can you take a look?

Comment 108

[Cervantes Yu [:cyu] [:cervantes]]

I'll take a look at this.

Comment 109

[Cervantes Yu [:cyu] [:cervantes]]

This is a race between 2 processes. We shouldn't send requests to the Nuwa process to change its state after we send out the fork request, or the update will be lost. To really fix this problem we need bug 970307, where we wait until the chrome and Nuwa processes are both in a stable state, but I think it's too risky for 1.3 and the patch is not ready. We need to work out a less risky solution for this bug.

Comment 110

[Kai-Chih Hu [:khu]]

Don't really know what's the question ni to me.

Comment 111

[Cervantes Yu [:cyu] [:cervantes]]

Attachment: Redirect Nuwa pref updates to the forked child

Try push: https://tbpl.mozilla.org/?tree=Try&rev=4a6460c49b4d

Comment 112

[Cervantes Yu [:cyu] [:cervantes]]

Albert, I still cannot reproduce the problem locally on my Sora. Could you apply the patch and verify it? Thanks.

Comment 113

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Weijia -

Could you also help to apply the patch to see if it works?

Thanks for your help

Vance

Comment 114

[Albert [:albert]]

(In reply to Cervantes Yu from comment #112)
> Albert, I still cannot reproduce the problem locally on my Sora. Could you
> apply the patch and verify it? Thanks.

The patch gives compilation errors in 1.3, I 'rebased' but there is an error in line:

  content->SendPreferenceUpdate(sNuwaPrefUpdates[i]);

  no known conversion for argument 1 from 'nsTArray<mozilla::dom::PrefSetting>' to 'const PrefSetting& {aka const mozilla::dom::PrefSetting&}'

Comment 115

[Cervantes Yu [:cyu] [:cervantes]]

Attachment: Redirect Nuwa pref updates to the forked child (rebased to 1.3)

Fixed the build error on 1.3.

Comment 116

[Viga]

(In reply to Cervantes Yu from comment #115)
> Created attachment 8420497 [details] [diff] [review]
> Redirect Nuwa pref updates to the forked child (rebased to 1.3)
> 
> Fixed the build error on 1.3.

I test pass. Can't reproduce. Thanks.

Comment 117

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

(In reply to weijia from comment #116)
> (In reply to Cervantes Yu from comment #115)
> > Created attachment 8420497 [details] [diff] [review]
> > Redirect Nuwa pref updates to the forked child (rebased to 1.3)
> > 
> > Fixed the build error on 1.3.
> 
> I test pass. Can't reproduce. Thanks.

Great, thanks for the patch, Cervantes, and thanks for helping to verify the patch, Weijia

Comment 118

[Viga]

(In reply to Vance Chen [:vchen][[e-mail]] from comment #117)
> (In reply to weijia from comment #116)
> > (In reply to Cervantes Yu from comment #115)
> > > Created attachment 8420497 [details] [diff] [review]
> > > Redirect Nuwa pref updates to the forked child (rebased to 1.3)
> > > 
> > > Fixed the build error on 1.3.
> > 
> > I test pass. Can't reproduce. Thanks.
> 
> Great, thanks for the patch, Cervantes, and thanks for helping to verify the
> patch, Weijia

I Just find that another bug introduced. The first start up is all right. But when do a restart,
The device never start up again.....

Comment 119

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

(In reply to weijia from comment #118)
> (In reply to Vance Chen [:vchen][[e-mail]] from comment #117)
> > (In reply to weijia from comment #116)
> > > (In reply to Cervantes Yu from comment #115)
> > > > Created attachment 8420497 [details] [diff] [review]
> > > > Redirect Nuwa pref updates to the forked child (rebased to 1.3)
> > > > 
> > > > Fixed the build error on 1.3.
> > > 
> > > I test pass. Can't reproduce. Thanks.
> > 
> > Great, thanks for the patch, Cervantes, and thanks for helping to verify the
> > patch, Weijia
> 
> I Just find that another bug introduced. The first start up is all right.
> But when do a restart,
> The device never start up again.....

Hi Weijia -

Please help to attach the logs once you have done testing, thanks!

Comment 120

[Viga]

Attachment: errolog1

Log restart.

Comment 121

[Cervantes Yu [:cyu] [:cervantes]]

(In reply to weijia from comment #120)
> Created attachment 8420773 [details]
> errolog1
> 
> Log restart.

Can we have the result of adb shell b2g-info when the phone failed to start up? And you might encounter bug 977359.

Comment 122

[Viga]

https://bug977359.bugzilla.mozilla.org/attachment.cgi?id=8405316  ?

I use this patch to test?

(In reply to Cervantes Yu from comment #121)
> (In reply to weijia from comment #120)
> > Created attachment 8420773 [details]
> > errolog1
> > 
> > Log restart.
> 
> Can we have the result of adb shell b2g-info when the phone failed to start
> up? And you might encounter bug 977359.

Comment 123

[Cervantes Yu [:cyu] [:cervantes]]

(In reply to weijia from comment #122)
> https://bug977359.bugzilla.mozilla.org/attachment.cgi?id=8405316  ?
> 
> I use this patch to test?
Yes. It's supposed to land on 1.3 but it gets blocked by the test failure. I will land the patch soon and handle the test failure in a followup.

Comment 124

[Cervantes Yu [:cyu] [:cervantes]]

Attachment: Redirect Nuwa pref updates to the forked child

Update: only redirect pref updates after the Nuwa process is ready.
Try push: https://tbpl.mozilla.org/?tree=Try&rev=8f2d85c5fa61

Comment 125

[Cervantes Yu [:cyu] [:cervantes]]

The patch is failing emulator opt tests. It appears to be crashes during test. Need to refine it.

Comment 126

[Cervantes Yu [:cyu] [:cervantes]]

Attachment: Redirect Nuwa pref updates to the forked child

Change to the previous version: null check the pointer sNuwaPrefUpdates in ContentParent::RecvAddNewProcess().

Retest on emulator: https://tbpl.mozilla.org/?tree=Try&rev=358fdf9f434c

Comment 127

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Comment on attachment 8421632 [details] [diff] [review]
Redirect Nuwa pref updates to the forked child

Review of attachment 8421632 [details] [diff] [review]:
-----------------------------------------------------------------

I'm a little worried that we didn't see this until now ...

Comment 128

[Cervantes Yu [:cyu] [:cervantes]]

Comment on attachment 8421632 [details] [diff] [review]
Redirect Nuwa pref updates to the forked child

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 771765
User impact if declined: The user may see the FTU app not localized.
Testing completed: manual by the partner.
Risk to taking this patch (and alternatives if risky): low to middle. The only risk to be the Nuwa process failing to receive some preference updates after it is ready to fork. However, it might be unsafe when the Nuwa process receives some preference update after being ready. So I would suggest taking this patch.

Comment 129

[Cervantes Yu [:cyu] [:cervantes]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/17942ed40870

Comment 130

[Preeti Raghunath(:Preeti)]

Fabrice

ni'ed for 1.3 approval

Comment 131

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

https://hg.mozilla.org/mozilla-central/rev/17942ed40870

Comment 132

[Cervantes Yu [:cyu] [:cervantes]]

1.3: https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/2e902c53be8d
1.3t: https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/8352a71b30be
1.4: https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/0f94bf84d434

Comment 133

[Ryan VanderMeulen [:RyanVM]]

For future reference, you don't need to double-land on 1.3/1.3t. The branches are kept in sync via daily merges. Please take the time to read over the link below to avoid future confusion.

https://wiki.mozilla.org/Release_Management/B2G_Landing#Landing_Procedure_4