User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release) Build ID: 20131206151508 Steps to reproduce: Build a normal profile (or a debug profile) from the latest code for b2g dektop client. Launch First time user menu and change the timezone and city when asked to. The timezone and city are changed but not visible on the screen. Time and Date do change though. Upon re-run of FTU menu, the changes are reflected, but the same happens if you try change them again. Actual results: Timezone sticks to default- America City default- New York Expected results: Timezone and city should reflect the changes made

I want to work on this bug. Need a mentor.

I would also like this to work in Firefox nightly. If it's the same for B2G desktop, then we likely need to expose a mozTime API. We could also mock it I suppose.

This is reproducible on the latest build, Hamachi device: STR: 1. Flash your device with the latest build. 2. Go through the steps until you reach Date & Time step. 3. Try changing the continent and city. Expected results: The changes should be visible. Actual results: Changes are made but they are not visible. BUILD: Gaia ac8a273809b5b160554e616bc5ef2d6fa026ce0e Gecko https://hg.mozilla.org/mozilla-central/rev/1e9f169c9715 BuildID 20140206040203 Version 30.0a1

Confirmed as well on a Buri device manually.

This issue no also exists on Boot2Gecko 1.3.0.0-prerelease 20140208010101 on Keon, but it regressed just recently. Still works with: images-keon-v1.3-2014-02-06.Gecko-ad42352.Gaia-ed8e558 Broken in: images-keon-v1.3-2014-02-08.Gecko-1fcef49.Gaia-464c279

Also reproduced this on the following build: Gaia dd94a5ba3f56ce1e8b378feeecc8a2d7a0b30fc7 Gecko https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/399b31f5a815 BuildID 20140209164003 Version 28.0 ro.build.version.incremental=eng.zxliu.20130911.142924 ro.build.date=Wed Sep 11 14:29:37 CST 2013 We xfailed the test in our v1.3 automation suite.

fairly recent regression. Can we find out what broke this and try a back out?

Regression Window using tinderbox builds: Last Working Environmental Variables: Device: Buri 1.4 BuildID: 20140204113223 Gaia: 75e9691f02b9d18585c18a5434beeff39ee7ea20 Gecko: 55614a949bde Version: 30.0a1 Base Image: V1.2-device.cfg First Broken Environmental Variables: Device: Buri 1.4 BuildID: 20140204114427 Gaia: ac94739a01d64e86890f54f1795ff8e82b8e7939 Gecko: 2c366892729d Version: 30.0a1 Base Image: V1.2-device.cfg Haven't seen this until recently on the Buri, this regression window begins several days after this bug was filed.

I need a regression window on 1.3.

(In reply to Jason Smith [:jsmith] from comment #10) > I need a regression window on 1.3. Also - I need an indication of the following on the 1.3 last working to first broken build: 1. Test to see if this bug reproduces on the 1.3 last working gaia on top of the first broken gecko 2. Test to see if this bug reproduces on the 1.3 first broken gaia on top of the last working gecko

1.3 Regression Window using tinderbox builds: Last Working Environmental Variables: Device: Buri BuildID: 20140207064103 Gaia: 89f0cc7fb7587ce222798001c10671f211ed7fa8 Gecko: af0e7fea51b9 Version: 28.0 Base Image: V1.2-device.cfg First Broken Environmental Variables: Device: Buri BuildID: 20140207105105 Gaia: 89f0cc7fb7587ce222798001c10671f211ed7fa8 Gecko: 164c55b989eb Version: 28.0 Base Image: V1.2-device.cfg I'll update with the results of the testing requested in Comment 11 shortly.

Actually, at least on 1.3 the Gaia is the same for both builds, which would lead me to believe that Gecko is the problem? I'm leaving for the day, but I can check the 1.4 Gaia and Gecko tomorrow if that is still desired.

(In reply to J Zimbrick from comment #14) > Actually, at least on 1.3 the Gaia is the same for both builds, which would > lead me to believe that Gecko is the problem? > > I'm leaving for the day, but I can check the 1.4 Gaia and Gecko tomorrow if > that is still desired. Looks like it - don't worry about doing the old vs. new gaia & gecko testing then.

No idea why, but apparently enabling of nuwa is the only thing present in both regression ranges. Kyle - Why could nuwa cause something like this?

(In reply to Jason Smith [:jsmith] from comment #18) > No idea why, but apparently enabling of nuwa is the only thing present in > both regression ranges. > > Kyle - Why could nuwa cause something like this? I have no clue, but I will investigate.

I was able to reproduce this on the emulator. It's 5 PM here so I'm unlikely to make further progress today.

1.3+ for incorrect information to the user

TimeZone is actually changed, but moztimechange event is not received in the FTU app. So it actually takes effect, just not reflected in UI. I will investigate further.

Lines 206 and 208 in https://github.com/mozilla-b2g/gaia/blob/d6da558d4ff61c1189a50e5f7698eea86222ad10/shared/js/tz_select.js suggest that 'user-select' CSS property should be defined. Looking at the -jsconsole, these declarations are dropped because of invalid property names. Maybe that is causing the problems.

Changing the Country/City does not update the text and the Map does not update the time zones showed, however changing the Country/City then changing the date or time will cause the page to update.

Tests: https://tbpl.mozilla.org/?tree=Try&rev=f074d16a5547

I will review the initialization of the Nuwa process to see if similar cross-process observers are registered before app processes are forked.

Comment on attachment 8376136 [details] [diff] [review] Init the system time observer after forking from the Nuwa process. Review of attachment 8376136 [details] [diff] [review]: ----------------------------------------------------------------- r=me

(In reply to Cervantes Yu from comment #31) > I will review the initialization of the Nuwa process to see if similar > cross-process observers are registered before app processes are forked. That would be great. Can you file a new bug for that?

Fix build break on non-Nuwa platforms.

Repush to try: https://tbpl.mozilla.org/?tree=Try&rev=3feb0c654565

Fix the problem in CrashReporterParent.cpp with unified build. Tests: https://tbpl.mozilla.org/?tree=Try&rev=5cc2c6437de1

Please request approval-mozilla-b2g28 on this patch for uplift to v1.3.

Comment on attachment 8376958 [details] [diff] [review] Init the system time observer after forking from the Nuwa process. [Triage Comment]

What about v1.2 where this is also broken? Will we also get this backported for this version?

Why do you think this is broken on 1.2?

1.2 doesn't have Nuwa and this should not break 1.2.

You were right. Sorry, for that. v1.2 is indeed not affected.

Verified fixed. Timezone and city reflect the changes made. master: BuildID: 20140219040204 Gaia: ac06cfbd2baf6494ffbb668cc599e3892cd5e17b Gecko: bf0e76f2a7d4 Version: 30.0a1 1.3 BuildID: 20140219004003 Gaia: a43904d9646109b48836d62f7aa51e499fbf4b2e Gecko: 97922b6daad1 Version: 28.0