Closed Bug 873407 Opened 11 years ago Closed 11 years ago

[Buri]Time on status bar won't update immediately when set time in Settings.

Categories

(Firefox OS Graveyard :: Gaia::System, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:leo+, firefox24 fixed, b2g18 verified, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 verified)

VERIFIED FIXED
blocking-b2g leo+
Tracking Status
firefox24 --- fixed
b2g18 --- verified
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- verified

People

(Reporter: sync-1, Assigned: johnhu)

References

Details

(Keywords: regression)

Attachments

(2 files)

+++ This bug was initially created as a clone of Bug #455048 +++
 
 AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.019.105
 Firefox os  v1.0.1
 Mozilla build ID:20130512070209
 
 STR:
 1. Settings->Date & Time->set time.
 2. See time on status bar, the time does not update immediately. --ko1
 3. Go back to homescreen, wait a minute, time on homescreen will update, while the time on status bar won't update at the same time. --ko2
 
 
 ++++++++++ end of initial bug #455048 description ++++++++++
blocking-b2g: --- → tef?
cannot reproduce on partner buri build (dated May 15th)
(In reply to Joe Cheng [:jcheng] from comment #1)
> cannot reproduce on partner buri build (dated May 15th)

I don't know which version you got. It's a new regression bug, so you cannot reproduce on an old version.

The fix for bug 864516 cause this bug.
i can reproduce with partner may 20th build
reproduced on unagi with build number 20130520230211 from pvtbuilds
Wouldn't block on the functional behavior, since it's minor and resolves itself quickly, but we should get a regression window as soon as possible.
blocking-b2g: tef? → leo?
Here are the results for the regression window of when this issue started occurring: 

b2g18 v1_0_1 2013-05-09-23-02-02 PASS
b2g18 v1_0_1 2013-05-10-07-02-03 PASS
b2g18 v1_0_1 2013-05-10-23-02-03 FAIL
b2g18 v1_0_1 2013-05-11-07-02-02 FAIL

Tested on the Unagi device
Modify code in gaia/apps/system/js/statusbar.js:
    case 'moztimechange':
      this.clock.start.bind(this.clock, this.update.time.bind(this))
      break;
to:
    case 'moztimechange':
      this.clock.start(this.update.time.bind(this));
      break;
seems can fix it.
according to comment 7, mark tef?
blocking-b2g: leo? → tef?
Not a blocker for us, suggest we fix it in leo
Whiteboard: [tef-triage]
Comment 5 stands.
blocking-b2g: tef? → leo+
Whiteboard: [tef-triage]
Comment from Mozilla:Comment 5 stands.
Assignee: nobody → johu
I had checked the code. This bug also can be reproduced at gaia-master. But only home screen part can be reproduced: 

 3. Go back to homescreen, wait a minute, time on homescreen will update, while the time on status bar won't update at the same time. --ko2

The difference is because: code in v1.0.1 has a little different with gaia-master while this bug is merged: 

https://bugzilla.mozilla.org/show_bug.cgi?id=864516

differences from v1.0.1 to master:
@@ -285,7 +334,8 @@ var StatusBar = {
         break;
 
       case 'moztimechange':
-        this.clock.start.bind(this.clock, this.update.time.bind(this))
+        navigator.mozL10n.ready(
+          this.clock.start.bind(this.clock, this.update.time.bind(this)));
         break;
 
       case 'mozChromeEvent':

this.clock.start.bind(this.clock, this.update.time.bind(this)) this doesn't calls this.clock.start. But navigator.mozL10n.ready(this.clock.start.bind(this.clock, this.update.time.bind(this))); does. This is the reason gaia-master works for this part.

As to home screen part, there is a time difference, within 60s depending on the moment of changing time,  between home screen and status bar. It is because the timer of status bar is called every 60sec. When time changed, settings app creates the Date object based on YYYY-MM-DDTHH:MM format which assumes 00 in the seconds field.

I will start with the bug of home screen part. And ask for the author of 864516 for more information about difference between gaia-master and v1.0.1.
Gabriele Svelto,

Would you mind to tell us why there is a difference between v1.0.1 and master or v1-train on status_bar.js?? Thanks in advance..

@@ -285,7 +334,8 @@ var StatusBar = {
         break;
 
       case 'moztimechange':
-        this.clock.start.bind(this.clock, this.update.time.bind(this))
+        navigator.mozL10n.ready(
+          this.clock.start.bind(this.clock, this.update.time.bind(this)));
         break;
 
       case 'mozChromeEvent':
Flags: needinfo?(gsvelto)
I can still repo this in ikura v101 build, unagi v101 build.
if there is a fix later, please uplift this to v1train and v101 if possible.
(In reply to John Hu [:johnhu] from comment #13)
> Would you mind to tell us why there is a difference between v1.0.1 and
> master or v1-train on status_bar.js?? Thanks in advance..

I had developed the patch on master and manually ported it to v1-train and v1.0.1 because there were significant differences between the branches. When responding to the |moztimechanged| event v1.0.1 did not call navigator.mozL10n.ready() in the first place so in my back-ported patch I also did not call it when refreshing the time. I thought about changing that call, but I feared I could introduce regressions so I tried to be conservative and simply followed what v1.0.1 was doing.
Flags: needinfo?(gsvelto)
Attached file patch file for master
In gaia master, it has asynchronized home screen clock and status bar clock. To fix it, this.clock.stop() is called to reset the timer interval(every 1 min) and this.clock.start() is called to create correct timer interval again.
Attached file patch for v1.0.1
To fix this bug:
1. to reset timer interval (every 1 min), and start it again
2. replace this.clock.start.bind with this.clock.start to make it run immediately.
Attachment #757197 - Flags: review?(alive)
Attachment #757200 - Flags: review?(alive)
To prevent things mixed, I created two PR one for master and another for v1.0.1.
Is v1-train use the same patch as master?
Comment on attachment 757197 [details]
patch file for master

Looks good.
Attachment #757197 - Flags: review?(alive) → review+
Attachment #757200 - Flags: review?(alive) → review+
(In reply to John Hu [:johnhu] from comment #22)
> merged to master:
> https://github.com/mozilla-b2g/gaia/commit/
> b01f01ab2a948e5a08d274c212e56435c68c4875
> 
> merged to v1.0.1
> https://github.com/mozilla-b2g/gaia/commit/
> fcae23654296c9cc645c2b7e77a2c36bf494803a

Is this applicable to v1-train?  Also, please set status-b2g18-v1.0.1 to fixed when you land to v1.0.1.

Thanks
Flags: needinfo?(johu)
Yes this is applicable to v1-train.

And, thanks for the change...
Flags: needinfo?(johu)
Verified fixed on Buri 1.0.1 Build ID: 20130621070204

Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/9c62297d11b0
Gaia: 93241eb6c5d6c110710fad8da3ccd4423312b0c9
Platform Version: 18.0


Also verified fixed on Leo Build ID: 20130621070212

Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/a34f6d62cb05
Gaia: cca61224e6df8e9f7e450d77cb6a8cf91029be64
Platform Version: 18.0

Time in status bar updates immediately after making a change in the settings.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: