Closed Bug 977539 Opened 6 years ago Closed 6 years ago

[Sora][Date&time]Date&time on status bar display inconsistent with data&time in time setting

Categories

(Core :: DOM: Core & HTML, defect, P1)

28 Branch
defect

Tracking

()

VERIFIED FIXED
1.4 S3 (14mar)
blocking-b2g 1.3+
Tracking Status
firefox28 --- wontfix
firefox29 --- wontfix
firefox30 --- verified
b2g-v1.3 --- verified
b2g-v1.3T --- verified
b2g-v1.4 --- verified

People

(Reporter: sync-1, Assigned: cyu)

References

()

Details

(Keywords: regression, Whiteboard: [systemsfe])

Attachments

(2 files)

Firefox OS v1.3
 Mozilla build ID: 20140208004002
 
 Created an attachment (id=650020)
  ko picture
 
 DEFECT DESCRIPTION:
 Date&time on status bar display inconsistent with data&time
 in time setting
 
  REPRODUCING PROCEDURES:
 1.Enter "Settings--> date &time",set automatically off,,modify "Time zone_> region /city"
 2. Compare date&time  on status bar with date&time in time setting;Date&time inconsistent with  date&time in time setting.--KO.
 
 Note:Beetle lite FF is OK.
 
  EXPECTED BEHAVIOUR:
 Date&time display on status bar should consistent with  date&time in time setting.
 
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:
Attached image ko picture
Can someone confirm this on the Moz side?
Keywords: qawanted, regression
QA Contact: lmauritson
Confirming that this occurs on Buri 1.4

When the date / time is set to automatic but the user is in a different time zone than is set (New York when in Seattle, for instance) the times can become mismatched.

1.4 Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140228040203
Gaia: 9422aca1931ba6c68784f9e80bb1b6a7fcfd92e3
Gecko: 58eca03214a6
Version: 30.0a1
Firmware Version: v1.2-device.cfg
Keywords: qawanted
Also confirming for 1.3, since this was the branch it was found on.

1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140228004002
Gaia: 9e439c98a05bde90b571701ef0b2dbb4249ef196
Gecko: 7fb42ba60248
Version: 28.0
Firmware Version: v1.2-device.cfg

Side note: This can happen immediately when turning automatic off as well.
blocking-b2g: --- → 1.3?
Duplicate of this bug: 978382
So this is a regression caused by fixing something else. Can we check what regressed this and back out the same?
Wondering if this is a status bar issue. Gregor, please help here.
blocking-b2g: 1.3? → 1.3+
Flags: needinfo?(anygregor)
Assignee: nobody → dale
Whiteboard: [systesmsfe]
Target Milestone: --- → 1.4 S3 (14mar)
Flags: needinfo?(anygregor)
dears,

This is same reason as PR 965912, maybe you could close it.
(In reply to Ray REN from comment #8)
> dears,
> 
> This is same reason as PR 965912, maybe you could close it.

I don't think so. That bug landed on 2/18 & was verified fixed on 2/19. This was confirmed busted on 2/28.
(In reply to Jason Smith [:jsmith] from comment #9)
> 
> I don't think so. That bug landed on 2/18 & was verified fixed on 2/19. This
> was confirmed busted on 2/28.

Sorry my mistake. 
Before I merge the patch in PR 965912, the status bar's display is OK and date&time's display is KO. After merged 965912's patch, the status bar's display is KO and date&time's display is OK.
Please check that patch. Thanks.
Looking into this

Fairly confused as to why my 'set automaticcaly' checkbox is gone, despite this code not changing for ~4 months
I can reproduce this on master

Still confused as to why I need to manually set time.clock.automatic-update.enabled, true only on master
Whiteboard: [systesmsfe] → [systemsfe]
QA Contact: lmauritson → mvaughan
ok, a regression window would be interesting because as far as I can tell this will always have worked the same way, its also fairly visible

Setting the timezone triggers some gonk code to set the android timezone, its not used anywhere else, our jsapi code as far as I can uses plain system calls to read the time (http://mxr.mozilla.org/mozilla-central/source/js/src/prmjtime.cpp), so kinda seems like those system calls dont pick up android timezone changes (done via env vars?), when restarted / new processes are all fine. 

With only guessing whats going wrong, assume the fix would be to have PRMJ_Now(void) ifdeffed on android

needinfoing Dave as he made the mistake of answering on irc, I am guessing at most of this stuff, is any of that along the right lines?
Flags: needinfo?(dhylands)
So more looking, |$ date| at the command like will take the new timezone into account, I can only see jsdate.cpp doing a straight path to system calls which sound like they 'should' do the right thing, however informed on IRC that we may cache the timezone somewhere and sstangl might know more, any ideas?
Flags: needinfo?(dhylands) → needinfo?(sstangl)
This issue looks to have started reproducing on the 02/18/14 1.3 build.

The following regression window was found using tinderbox builds:

- Last Working -
BuildID: 20140218130433
Gaia: 77cc5367781d5770b4d94d8746cf4f5ecd80d190
Gecko: 3d3021fdb54f
Version: 28.0
Firmware Version: V1.2-device.cfg

- First Broken -
Device: Buri v1.3 MOZ RIL
BuildID: 20140218135733
Gaia: 77cc5367781d5770b4d94d8746cf4f5ecd80d190
Gecko: 42944ee96dd0
Version: 28.0
Firmware Version: V1.2-device.cfg


*This issue looks to be a gecko issue*

last working gaia/first broken gecko = REPRO
Gaia:  77cc5367781d5770b4d94d8746cf4f5ecd80d190
Gecko: 42944ee96dd0

first broken gaia/last working gecko = NO REPRO
Gaia:  77cc5367781d5770b4d94d8746cf4f5ecd80d190
Gecko: 3d3021fdb54f

Since there was only one gecko commit between these two, I thought it unnecessary to use inbound builds for a deeper regression window. Please NI me if more info is needed though.
Push Log: http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/pushloghtml?fromchange=3d3021fdb54f&tochange=42944ee96dd0
This is a nuwa regression - bug 965912 is the cause of this.

Kyle or Cervantes - Can you look into this?
Blocks: 965912
Flags: needinfo?(khuey)
Flags: needinfo?(cyu)
Component: Gaia::Settings → IPC
Product: Firefox OS → Core
Version: unspecified → 28 Branch
so js/ is getting the same time from the system and modifying it somewhere before returning different times to content

## Status Bar (System App)
I/GeckoWTF( 2265): Date was 1394123760149.000000
E/GeckoConsole( 2265): Content JS LOG at app://system.gaiamobile.org/js/statusbar.js:617 in sb_updateTime: GeckoWTF - NOW IS Thu Mar 06 2014 17:36:00 GMT+0100 (CET)
 
## Settings App
I/GeckoWTF( 2668): Date was 1394123759986.000000
E/GeckoConsole( 2668): Content JS LOG at app://settings.gaiamobile.org/js/date_time.js:45 in updateClock: GeckoWTF - NOW IS Thu Mar 06 2014 23:35:59 GMT+0700 (CET)

(The "Date was" is printing the return from NowAsMillis and is the same time)
(In reply to Dale Harvey (:daleharvey) from comment #14)
> So more looking, |$ date| at the command like will take the new timezone
> into account, I can only see jsdate.cpp doing a straight path to system
> calls which sound like they 'should' do the right thing, however informed on
> IRC that we may cache the timezone somewhere and sstangl might know more,
> any ideas?

There is a cache of the timezone on the JSRuntime, along with the JSAPI call JS_ClearDateCaches() which may be used to notify each JSContext that the timezone has changed.
Flags: needinfo?(sstangl)
I'll look into it.
Flags: needinfo?(cyu)
Flags: needinfo?(khuey)
I think removing the code from nsLayoutStatictics causes the regression for the chrome process: the Nuwa process and its forked childs clear the cache, but the chrome process doesn't. It should be easy to fix.
Fix the regression caused by bug 965912.

Risk analysis: InitDateCacheCleaner() was originally called in nsLayoutStatics::Inittialize() so each process will call in initializing the layout module.

Bug 965912 move it from layout module initialization to ContentChild so it is called when each process is forked from Nuwa. This led to the regression that the chrome process doesn't initialize it.

This bug add the InitDateCacheCleaner() call to ContentParent::StartUp() to fix the regression and should be safe.
Assignee: dale → cyu
Attachment #8387399 - Flags: review?(khuey)
https://hg.mozilla.org/mozilla-central/rev/08940575df75
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Please request approval-mozilla-b2g28 on this when it is ready for v1.3 uplift.
Comment on attachment 8387399 [details] [diff] [review]
Init date cache cleaner in ContentParent

[Approval Request Comment]
Bug caused by: bug 965912
User impact if declined: system time zone change not reflected on status bar.
Testing completed: m-c manual tests.
Risk to taking this patch (and alternatives if risky): low, since the regression in 965912 missed the initialization in ContentParent. This bug adds the initialization back to the chrome process.
Attachment #8387399 - Flags: approval-mozilla-b2g28?
Keywords: verifyme
Attachment #8387399 - Flags: approval-mozilla-b2g28? → approval-mozilla-b2g28+
Verified as fixed v1.3. This issue does NOT reproduce on the latest v1.3 build:

3/26 Environmental Variables:
Device: Buri 1.3 MOZ RIL
BuildID: 20140326004002
Gaia: 812838ad0fabf51fa14435af562ddac6d26fa936
Gecko: ba97efb0da4b
Version: 28.0
Firmware Version: V1.2-device.cfg

Verified as fixed v1.4. This issue does NOT reproduce on the latest v1.4 build:

3/26 Environmental Variables:
Device: Buri 1.4 MOZ RIL
BuildID: 20140326000201
Gaia: 7e705dd4718d528974d99ac31866318d7e201152
Gecko: 4889124accfa
Version: 30.0a2
Firmware Version: V1.2-device.cfg

- 

1) I am currently unable to verify this issue on the v1.3T Branch, leaving verifyme keyword.

2) Changing bug status to verified as this was tested against master v1.4, comment #27.
Flags: in-testsuite?
Flags: in-moztrap?
Flags: in-moztrap? → in-moztrap+
Verified as fixed v1.3T. I am unable to reproduce this issue on the latest v1.3T Tarako build:

v1.3T Environmental Variables:
Device: Tarako v1.3T MOZ RIL
BuildID: 20140530014002
Gaia: e68858693b71d917c9c5ee7e215f7ceea04635f7
Gecko: 1945abae19ff
Version: 28.1
Firmware Version: SP6821a-Gonk-4.0-5-12
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.