Changing the country and the city in the time zone menu has no visible effect. This issue was reproduced with both manual and automated tests. Build info(flame): Gaia 41db6954a67efc55016744bc8f6591ae9e07a285 Gecko https://hg.mozilla.org/mozilla-central/rev/9e8e3e903484 BuildID 20140612040203 Version 33.0a1 ro.build.version.incremental=94 ro.build.date=Tue May 20 09:29:20 CST 2014 STR: 1. open FTU app 2. tap next until you reach Date & Time menu 3. change country and city Expected results: The values for country and city are updated Actual results: No changes are visible. Note: Changing the values for date and time will also update the country/city values to the correct ones. This issue is not reproduced on v1.4

We need to know if this happens on 2.0 & what the last working & first broken build is in automation.

I am unable to repro this issue on the Flame v2.0 MOZ ril. v2.0 Environmental Variables: Device: Flame v2.0 MOZ BuildID: 20140612000201 Gaia: 2bb66630315299ca947e40fcec23c9f7ea012111 Gecko: 670d69879f0e Version: 32.0a2 Firmware Version: v10G-2 Changes made to the date & time screen occur as expected and are saved if the user checks them in the settings after completing the FTE. Leaving qawanted tag for the automation regression window.

Flame 2.1 = Repro Flame 2.0 = NO repro Flame 1.4 = NO repro QA-Wanted to Check the Buri branch

This issue occurs in Mozilla-Inbound during a period where there was no builds for over 26 hours. As such the Pushlog for that window is quite large, more so than the Central Window. I am also including both windows in case Central is easier to work with. Central Regression Window: Last working Environmental Variables: Device: Flame BuildID: 20140611072409 Gaia: 0750f66a0004870773c9a743fa6bdbe124379336 Gecko: 429f55154e83 Version: 33.0a1 First Broken Environmental Variables: Device: Flame BuildID: 20140611081515 Gaia: 0750f66a0004870773c9a743fa6bdbe124379336 Gecko: c7391b84d9c2 Version: 33.0a1 Last working gaia / First broken gecko - Issue DOES occur Gaia: 0750f66a0004870773c9a743fa6bdbe124379336 Gecko: c7391b84d9c2 First broken gaia / Last working gekko - Issue does NOT occur Gaia: 0750f66a0004870773c9a743fa6bdbe124379336 Gecko: 429f55154e83 Gecko Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=429f55154e83&tochange=c7391b84d9c2 Mozilla-inbound Regression Window Last working Environmental Variables: Device: Flame BuildID: 20140610081416 Gaia: f42ebc93554979501d3ac52bcf9e69cb4b310a4f Gecko: 00d5164a4049 Version: 33.0a1 First Broken Environmental Variables: Device: Flame BuildID: 20140611101104 Gaia: 508c85713fdf35eb2b3c8e8340e1d2ee306e6aec Gecko: e1562c119643 Version: 33.0a1 Last working gaia / First broken gecko - Issue DOES occur Gaia: f42ebc93554979501d3ac52bcf9e69cb4b310a4f Gecko: e1562c119643 First broken gaia / Last working gecko - Issue does NOT occur Gaia: 508c85713fdf35eb2b3c8e8340e1d2ee306e6aec Gecko: 00d5164a4049 Gecko Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=00d5164a4049&tochange=e1562c119643

Can we try bisecting this using Buri builds instead?

Mozilla-inbound Regression Window Last working Environmental Variables: Device: Buri BuildID: 20140610222008 Gaia: 0750f66a0004870773c9a743fa6bdbe124379336 Gecko: b35a6797354b Version: 33.0a1 First Broken Environmental Variables: Device: Buri BuildID: 20140610224608 Gaia: 0750f66a0004870773c9a743fa6bdbe124379336 Gecko: a72228f459ec Version: 33.0a1 Last working gaia / First broken gecko - Issue DOES occur Gaia: 0750f66a0004870773c9a743fa6bdbe124379336 Gecko: a72228f459ec First broken gaia / Last working gecko - Issue does NOT occur Gaia: 0750f66a0004870773c9a743fa6bdbe124379336 Gecko: b35a6797354b Gecko Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b35a6797354b&tochange=a72228f459ec

Broken by bug 879475.

Kan-Ru - Can you either fix this quickly or backout?

(In reply to Jason Smith [:jsmith] from comment #8) > Kan-Ru - Can you either fix this quickly or backout? We can't backout this. I'll fix this asap.

Make sure that we run mozilla::dom::time::InitializeDateCacheCleaner only in the chrome process and run InitOnContentProcessCreated even prelaunch process is disabled.

After the introduction of the Nuwa process, it's easy to break such cross-process observers. In bug 965912 we fail to run mozilla::dom::time::InitializeDateCacheCleaner() to register the observer for system time changes. In this bug, we call mozilla::dom::time::InitializeDateCacheCleaner() too early and make the second call fail because it is already initialized and just skip the whole stuff in it. We may consider cleaning up the old instance of mozilla::dom::time::DateCacheCleaner() if mozilla::dom::time::InitializeDateCacheCleaner() is called the second time. It looks safe to do it except that the parent side will notice that some unknown observer needs to be unregistered and spits out a warning in http://mxr.mozilla.org/mozilla-central/source/hal/Hal.cpp#204

Comment on attachment 8441956 [details] [diff] [review] Make sure we run InitOnContentProcessCreated in all cases Review of attachment 8441956 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/ipc/ContentChild.cpp @@ +674,5 @@ > nsRefPtr<SystemMessageHandledObserver> sysMsgObserver = > new SystemMessageHandledObserver(); > sysMsgObserver->Init(); > > + InitOnContentProcessCreated(/* AfterNuwaFork = */false); aAfterNuwaFork @@ +1840,5 @@ > toplevel = toplevel->getNext(); > } > > // Perform other after-fork initializations. > + InitOnContentProcessCreated(/* AfterNuwaFork = */true); and here

Issue verified fixed on 2.1 Flame Result: The values for country and city are updated Environmental Variables: Device: Flame Build ID: 20140620040204 Gaia: ccd70903544486bea04e85d8a4aacf63f1de2a72 Gecko: bdac18bd6c74 Version: 33.0a1 Firmware Version: v121

Already on 2.1