Closed Bug 988689 Opened 6 years ago Closed 6 years ago

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

Categories

(Core :: IPC, defect, P1)

28 Branch
defect

Tracking

()

RESOLVED FIXED
2.0 S2 (23may)
blocking-b2g 1.3+
Tracking Status
b2g-v1.3 --- fixed
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: sync-1, Assigned: cyu)

References

()

Details

(Whiteboard: [cert])

Attachments

(24 files, 3 obsolete files)

9.54 MB, application/x-rar
Details
145.83 KB, image/jpeg
Details
1.02 MB, application/zip
Details
9.54 MB, application/x-rar
Details
9.54 MB, application/x-rar
Details
9.54 MB, application/x-rar
Details
9.54 MB, application/x-rar
Details
145.83 KB, image/jpeg
Details
1.02 MB, application/zip
Details
9.54 MB, application/x-rar
Details
9.54 MB, application/x-rar
Details
1016.80 KB, application/x-zip-compressed
Details
250.35 KB, image/jpeg
Details
116.68 KB, image/jpeg
Details
9.54 MB, application/x-rar
Details
106.92 KB, image/png
Details
2.43 MB, application/x-rar
Details
1016.80 KB, application/x-zip-compressed
Details
9.54 MB, application/x-rar
Details
250.35 KB, image/jpeg
Details
46 bytes, text/x-github-pull-request
stas
: review-
Details | Review
46 bytes, text/x-github-pull-request
Details | Review
249.61 KB, text/x-vhdl
Details
6.59 KB, patch
khuey
: review+
Details | Diff | Splinter Review
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
Attached file TL-2
Attached file TL-4
Attached file TL-3
Attached file TL-1
Attached file TL-2
Attached file TL-4
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!
Attached file TL-3
Attached file Wizard_v10I.zip
Attached image Geolocation description
Attached file TL-1
Attached image Antonio V10I.png
Attached file TL-5
Attached file Wizard_v10I.zip
Attached file TL-2
Attached image Geolocation description
Can someone confirm this on the Moz side on 1.3?
Component: Gaia::System → Gaia::First Time Experience
Keywords: qawanted
QA Contact: 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
Keywords: qawanted
Whiteboard: [closeme 4/4/2014]
per comment 23 
Leaving QA Wanted if this issue specific for Sora device

Just have someone test it on sora PIO device.
Flags: needinfo?(sarsenyev)
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
(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.
Flags: needinfo?(sarsenyev)
Component: Gaia::First Time Experience → Vendcom
Whiteboard: [closeme 4/4/2014]
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."
(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.
Flags: needinfo?(fernando.campo)
(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.
(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!
Flags: needinfo?(fernando.campo)
(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.
(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?
Flags: needinfo?(fernando.campo)
> (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!
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.
blocking-b2g: --- → 1.3?
Component: Vendcom → Gaia::First Time Experience
blocking-b2g: 1.3? → 1.3+
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.
Flags: needinfo?(fernando.campo)
(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
Hi Vance, 
Already talked with Fernando. I have a sora device, will help him to test the patch. Thanks
(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!
Whiteboard: cert
Whiteboard: cert → [cert]
Assignee: nobody → fernando.campo
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.
Attachment #8404620 - Flags: review?(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.
Attachment #8404620 - Flags: review?(stas) → review-
(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.
(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?
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...
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.
(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.
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.
Flags: needinfo?(stas)
Whiteboard: [cert] → [cert][systemsfe]
Target Milestone: --- → 1.4 S6 (25apr)
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.
(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?
(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".
(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).
sorry for the typo,
Updated one http://pastebin.mozilla.org/4825412

for the document.documentElement.lang log.
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.
(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.
Hi Zbigniew -

The log you ask for is available per Comment#54, thanks!
Flags: needinfo?(gandalf)
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
Yeah, exactly. system, keyboard and homescreen see es, communications sees en-US.
Flags: needinfo?(gandalf)
Thanks for your feedback.
So I think can we confirm that comment 46 is available?
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.
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?
Is it a uers.js prefs? or in the code. can you tell me more?
user.js should work.
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.
wow. never saw empty navigator.language before.
(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
Flags: needinfo?(gandalf)
I do not have Flame device. I only have Keon/Peak.
Flags: needinfo?(gandalf)
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?
Flags: needinfo?(stas) → needinfo?(l10n)
Could this have something to do with bug 999163?
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?
(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.
(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()'?
Flags: needinfo?(gandalf)
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..
I just got tarako device and tried to reproduce it here. No luck. It seems to work just fine in all scenarios.
Flags: needinfo?(gandalf)
No idea either.
Flags: needinfo?(l10n)
I will get access to flame on Tue and I'll try to reproduce it there.
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.
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.
Hi Vance, 

can you help to push it forward?

Thanks.
Flags: needinfo?(vchen)
(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
Flags: needinfo?(vchen)
Target Milestone: 1.4 S6 (25apr) → 2.0 S1 (9may)
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
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.
Finally, it can be reproduced on your side. Anymore helps just let me know.
Thanks.
(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!
Assignee: fernando.campo → gandalf
Status: NEW → ASSIGNED
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?
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.
Assignee: gandalf → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(anygregor)
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?
I can't reproduce this bug on the flame either. We have to wait for a sora device.
Flags: needinfo?(anygregor)
Can we get a logcat when this reproduces? Is it in any of the attachments?
Keywords: qawanted
(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?
Flags: needinfo?(sync-1)
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?
Flags: needinfo?(21)
I tested gecko 28 and gaia 1.3 on Flame and was not able to reproduce it.
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.
(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.
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 on attachment 8416670 [details] [review]
Set pref during buildtime

Not sure who the right person for review is here.
Attachment #8416670 - Flags: review?(yurenju.mozilla)
Attachment #8416670 - Flags: review?(21)
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.
Flags: needinfo?(21)
Comment on attachment 8416670 [details] [review]
Set pref during buildtime

Cancelling the review until the Gecko question is answered.
Attachment #8416670 - Flags: review?(yurenju.mozilla)
Attachment #8416670 - Flags: review?(21)
(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
Flags: needinfo?(sync-1) → needinfo?(21)
(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.
(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.
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.
(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).
(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.
Flags: needinfo?(21)
I'll have a look at this.
Assignee: nobody → lissyx+mozillians
Status: NEW → ASSIGNED
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".
Flags: needinfo?(khu)
Flags: needinfo?(fabrice)
Cervantes, Patrick, can you take a look?
Flags: needinfo?(pwang)
Flags: needinfo?(fabrice)
Flags: needinfo?(cyu)
I'll take a look at this.
Flags: needinfo?(pwang)
Flags: needinfo?(cyu)
Assignee: lissyx+mozillians → cyu
Component: Gaia::First Time Experience → IPC
Keywords: qawanted
Product: Firefox OS → Core
Version: unspecified → 28 Branch
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.
See Also: → 970307
Don't really know what's the question ni to me.
Flags: needinfo?(khu)
Albert, I still cannot reproduce the problem locally on my Sora. Could you apply the patch and verify it? Thanks.
Flags: needinfo?(acperez)
Hi Weijia -

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

Thanks for your help

Vance
Flags: needinfo?(liweijia)
(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&}'
Flags: needinfo?(acperez)
Fixed the build error on 1.3.
Attachment #8420062 - Attachment is obsolete: true
Attachment #8420062 - Flags: review?(khuey)
(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.
Flags: needinfo?(liweijia)
(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
(In reply to Vance Chen [:vchen][vchen@mozilla.com] 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.....
(In reply to weijia from comment #118)
> (In reply to Vance Chen [:vchen][vchen@mozilla.com] 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!
Flags: needinfo?(liweijia)
Attached file errolog1
Log restart.
Flags: needinfo?(liweijia)
(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.
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.
(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.
Update: only redirect pref updates after the Nuwa process is ready.
Try push: https://tbpl.mozilla.org/?tree=Try&rev=8f2d85c5fa61
Attachment #8420497 - Attachment is obsolete: true
Attachment #8420967 - Flags: review?(khuey)
Whiteboard: [cert][systemsfe] → [cert]
The patch is failing emulator opt tests. It appears to be crashes during test. Need to refine it.
Change to the previous version: null check the pointer sNuwaPrefUpdates in ContentParent::RecvAddNewProcess().

Retest on emulator: https://tbpl.mozilla.org/?tree=Try&rev=358fdf9f434c
Attachment #8420967 - Attachment is obsolete: true
Attachment #8420967 - Flags: review?(khuey)
Attachment #8421632 - Flags: review?(khuey)
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 ...
Attachment #8421632 - Flags: review?(khuey) → review+
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.
Attachment #8421632 - Flags: approval-mozilla-b2g28?
Fabrice

ni'ed for 1.3 approval
Flags: needinfo?(fabrice)
Attachment #8421632 - Flags: approval-mozilla-b2g28? → approval-mozilla-b2g28+
Flags: needinfo?(fabrice)
https://hg.mozilla.org/mozilla-central/rev/17942ed40870
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: 2.0 S1 (9may) → 2.0 S2 (23may)
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
Flags: in-moztrap?
Flags: in-moztrap? → in-moztrap+
You need to log in before you can comment on or make changes to this bug.