Closed Bug 1064890 Opened 10 years ago Closed 10 years ago

[fte] different time shown on lockscreen and homescreen than the one set in ftu

Categories

(Core :: DOM: Content Processes, defect)

32 Branch
ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla35
blocking-b2g 2.0+
Tracking Status
firefox33 --- wontfix
firefox34 --- fixed
firefox35 --- fixed
b2g-v1.4 --- unaffected
b2g-v2.0 --- verified
b2g-v2.0M --- verified
b2g-v2.1 --- verified
b2g-v2.2 --- verified

People

(Reporter: aryx, Assigned: cyu)

References

Details

(Keywords: regression)

Attachments

(3 files)

Boot2Gecko 2.2.0.0-prerelease 20140908160203 on Flame Resetting the phone without a SIM card insert lets you set date and time in the first time experience app. I chose Europe, Berlin, today's date and the current time, but after finishing the fte app, the home and lock screen use a time two hours in the future. Two hours is the difference between UTC and my timezone, maybe related?
This is a regression. Can we figure out when this happened?
Whiteboard: [systemsfe]
Actually, we should do branch checks first.
This bug repro's on: Flame 2.2, Flame 2.1, Flame 2.0, OpenC 2.2 Actual Results: With no SIM inserted, setting the time in the FTU will change automatically to a different time once the homescreen loads. Repro Rate: 5/5 Environmental Variables: Device: Flame Master BuildID: 20140908163110 Gaia: 4acd3e69b263b54f4111e3586ff4ade84b49b4da Gecko: 6b8da5940f74 Version: 35.0a1 (Master) Firmware Version: v123 ----------------------------------------------- Device: Flame 2.1 BuildID: 20140909080656 Gaia: ece265efa8e87765713ac905e8ff55657fcbde01 Gecko: 3b49cf3e2043 Version: 34.0a2 (2.1) Firmware: V123 ------------------------------------------------ Device: Flame 2.0 BuildID: 20140908131505 Gaia: 59a670d40ad7f5966ec7fafcab0f05009bea97ab Gecko: de70f9a40834 Version: 32.0 (2.0) Firmware: V123 ------------------------------------------------ Device: Open_C 2.2 BuildID: 20140908062801 Gaia: c71fd5d8c9c7cb021c97e5e9fbb29f92b50a084d Gecko: f7a27a866c47 Version: 35.0a1 (2.2) Firmware: P821A10v1.0.0B06_LOG_DL ------------------------------------------------ ------------------------------------------------ This bug does NOT repro on: Flame 1.4 Actual Result: Proper time is kept on the homescreen when setting the location and time in the FTU Repro Rate: 0/3 attempts Environmental Variables: Device: Flame 1.4 BuildID: 20140905100238 Gaia: 2ee5b00bfbb8a67a967094804390b4afce8ecf54 Gecko: a3e8df746cd8 Version: 30.0 (1.4) Firmware Version: v123
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawantedregression
QA Contact: croesch
[Blocking Requested - why for this release]: regression in a major feature
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
QA Contact: croesch
QA Wanted - Does this happen on 2.0 with the KK image?
Yes this bug is present in the latest KK 2.0 Eng build. Set the location in the FTU to Malta in Europe which said 4pm. Upon reaching the home screen, the time changed to 6:38pm Environmental Variables: Device: Flame 2.0 BuildID: 20140908131505 Gaia: 59a670d40ad7f5966ec7fafcab0f05009bea97ab Gecko: de70f9a40834 Version: 32.0 (2.0) Firmware Version: v165
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Contact: croesch
restoring regression-window wanted based on bug also being present in KK builds.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
QA Contact: croesch → ckreinbring
blocking-b2g: 2.0? → 2.0+
Regression window Last working BuildID: 20140708163531 Gaia: dde24450450514039bad6d8ab4fcb7e5d4d44e03 Gecko: ff4e6d562903 Platform Version: 33.0a1 Firmware Version: V123 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0 First broken BuildID: 20140708201331 Gaia: 0f9f11d0a6dadb3ea27160204bbe911c1ad69a6f Gecko: 196d05832e12 Platform Version: 33.0a1 Firmware Version: V123 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0 Working Gaia / Broken Gecko = Repro Gaia: dde24450450514039bad6d8ab4fcb7e5d4d44e03 Gecko: 196d05832e12 Broken Gaia / Working Gecko = No repro Gaia: 0f9f11d0a6dadb3ea27160204bbe911c1ad69a6f Gecko: ff4e6d562903 Gecko pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ff4e6d562903&tochange=196d05832e12 B2G Inbound Last working BuildID: 20140708150230 Gaia: 0f9f11d0a6dadb3ea27160204bbe911c1ad69a6f Gecko: c49f24908699 Platform Version: 33.0a1 Firmware Version: V123 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0 First broken BuildID: 20140708155732 Gaia: 0f9f11d0a6dadb3ea27160204bbe911c1ad69a6f Gecko: ec4dc354e091 Platform Version: 33.0a1 Firmware Version: V123 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0 Working Gaia / Broken Gecko = Repro Gaia: 0f9f11d0a6dadb3ea27160204bbe911c1ad69a6f Gecko: ec4dc354e091 Broken Gaia / Working Gecko = No repro Gaia: 0f9f11d0a6dadb3ea27160204bbe911c1ad69a6f Gecko: c49f24908699 Gecko pushlog: http://hg.mozilla.org/integration/b2g-inbound/pushloghtml?fromchange=c49f24908699&tochange=ec4dc354e091
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Broken by Bug 1033618 ? Can you take a look Kyle Triage notes - not adding this bug to the blocked field yet - it is the only one in the pushlog but I'm not confident that it is related - even though I did have the regression window double-checked.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(khuey)
Seems odd, but we've seen weirdness around this with Nuwa before (e.g. bug 1024470), so I'm willing to believe it. I'm out of the office until next week though.
Thinker - Can someone from your team look into this since Kyle is out of the office?
Flags: needinfo?(tlee)
Component: Gaia::First Time Experience → DOM: Content Processes
Product: Firefox OS → Core
Whiteboard: [systemsfe]
Version: unspecified → 32 Branch
So if bug 1033618 exposed this then I suspect it was broken on the "good" revision if dom.ipc.processPrelaunch.enabled is set to false. Can QA confirm that?
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
(In reply to Jason Smith [:jsmith] from comment #11) > Thinker - Can someone from your team look into this since Kyle is out of the > office? Cervantes, could you take a look?
Flags: needinfo?(tlee) → needinfo?(cyu)
(In reply to Thinker Li [:sinker] from comment #13) > (In reply to Jason Smith [:jsmith] from comment #11) > > Thinker - Can someone from your team look into this since Kyle is out of the > > office? > > Cervantes, could you take a look? Sure.
Flags: needinfo?(cyu)
Assignee: nobody → cyu
I think I know what has happened here. This happens on the combination of config MOZ_NUWA_PROCESS and content process forked from b2g, which doesn't previously exist. I will provide a patch.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
Please nominate this for aurora and b2g32 approval when you get a chance.
Comment on attachment 8489923 [details] [diff] [review] Init the date cache cleaner for content processes forked from b2g [Approval Request Comment] Bug caused by (feature/regressing bug #): 1033618 User impact if declined: timezone changes in some apps (e.g. FTE) may not take effect. Testing completed: manually on the device and automation on the try server. Risk to taking this patch (and alternatives if risky): low. This patch brings the initialization step back to the processes that are not forked from the Nuwa template process.
Attachment #8489923 - Flags: approval-mozilla-b2g32?
Flags: needinfo?(cyu)
Blocks: 1069863
No longer blocks: 1069863
Depends on: 1069863
Comment on attachment 8489923 [details] [diff] [review] Init the date cache cleaner for content processes forked from b2g I assume the lack of an Aurora request was just an oversight. See comment 20.
Attachment #8489923 - Flags: approval-mozilla-aurora?
Comment on attachment 8489923 [details] [diff] [review] Init the date cache cleaner for content processes forked from b2g Aurora+
Attachment #8489923 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment on attachment 8489923 [details] [diff] [review] Init the date cache cleaner for content processes forked from b2g requesting qa verification once this lands...
Attachment #8489923 - Flags: approval-mozilla-b2g32? → approval-mozilla-b2g32+
Keywords: verifyme
This conflicts with bug 1024470 not being on b2g32. Please rebase.
Flags: needinfo?(cyu)
Attached patch Patch for v 2.0 (deleted) — Splinter Review
Flags: needinfo?(cyu)
Cannot reproduce this bug on latest v2.0 build. Thanks. * Build information: - Gaia 092d2b7678774c8b0b06dca0e0a8119e9eafdec3 - Gecko https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/69ca61f7edf3 - BuildID 20141006000202 - Version 32.0 - ro.build.version.incremental=27 - ro.build.date=Thu Sep 4 14:59:02 CST 2014
Status: RESOLVED → VERIFIED
Keywords: verifyme
Flags: needinfo?(jmitchell)
This issue has been verified successfully on Woodduck 2.0;Flame2.0&2.1&2.2. Reproducing rate: 0/5 See attachment: Verify_Woodduck_Time.mp4 Note:The reset phone function isn't working now, so we verify it by flashing ROM. Woodduck build version: Gaia-Rev d742e375aca6dc1bf3a36638000ad7f5338ef457 Gecko-Rev d049d4ef127844121c9cf14d2e8ca91fd9045fcb Build-ID 20141126050313 Version 32.0 Flame2.0 build version: Gaia-Rev 99e4594c66aa3738d58b0cb44bd885a87a063b6e Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/f91abc6127d9 Build-ID 20141125000201 Version 32.0 Flame2.1 build version: Gaia-Rev 1bdd49770e2cb7a7321e6202c9bf036ab5d8f200 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/db893274d9a6 Build-ID 20141125001201 Version 34.0 Flame2.2 build version: Gaia-Rev 824a61cccec4c69be9a86ad5cb629a1f61fa142f Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/acde07cb4e4d Build-ID 20141125040209 Version 36.0a1
Attached video Verify_Woodduck_Time.MP4 (deleted) —
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: