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)

Product:
Core
Component:
DOM: Content Processes
Version:
32 Branch
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla35
Project Flags:
blocking-b2g 2.0+
Tracking Flags:
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)

Init the date cache cleaner for content processes forked from b2g
2.52 KB, patch
khuey
: review+
lmandel
: approval-mozilla-aurora+
bajaj
: approval-mozilla-b2g32+
Details | Diff | Splinter Review
Patch for v 2.0
1.02 KB, patch
Details | Diff | Splinter Review
Verify_Woodduck_Time.MP4
4.33 MB, video/mp4
Details 
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?
Keywords: regressionwindow-wanted
Whiteboard: [systemsfe]
Actually, we should do branch checks first.
Keywords: regressionwindow-wanted → qawanted
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?]
status-b2g-v1.4: --- → unaffected
status-b2g-v2.0: --- → affected
status-b2g-v2.1: --- → affected
status-b2g-v2.2: --- → affected
Flags: needinfo?(jmitchell)
Keywords: qawanted → regression
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)
Keywords: regressionwindow-wanted
QA Contact: croesch
QA Wanted - Does this happen on 2.0 with the KK image?
Keywords: regressionwindow-wanted → qawanted
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)
Keywords: regressionwindow-wanted
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)
Keywords: regressionwindow-wanted
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.
https://hg.mozilla.org/mozilla-central/rev/0388b53acaa5
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.
status-b2g-v2.2: affected → fixed
status-firefox33: --- → wontfix
status-firefox34: --- → affected
status-firefox35: --- → fixed
Flags: needinfo?(cyu)
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)
Keywords: branch-patch-needed
Attached patch Patch for v 2.0 — — 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

          status-b2g-v2.0:
          fixed → verified

          status-b2g-v2.0M:
          fixed → verified

          status-b2g-v2.1:
          fixed → verified

          status-b2g-v2.2:
          fixed → verified

    
    

    
  


  

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: