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)
Tracking
(blocking-b2g:leo+, firefox24 fixed, b2g18 verified, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 verified)
VERIFIED
FIXED
blocking-b2g | leo+ |
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 ++++++++++
Comment 1•11 years ago
|
||
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.
Comment 3•11 years ago
|
||
i can reproduce with partner may 20th build
Comment 4•11 years ago
|
||
reproduced on unagi with build number 20130520230211 from pvtbuilds
Comment 5•11 years ago
|
||
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?
Keywords: regression,
regressionwindow-wanted
Comment 6•11 years ago
|
||
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
Keywords: regressionwindow-wanted
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.
Reporter | ||
Comment 11•11 years ago
|
||
Comment from Mozilla:Comment 5 stands.
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → johu
Assignee | ||
Comment 12•11 years ago
|
||
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.
Assignee | ||
Comment 13•11 years ago
|
||
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)
Comment 14•11 years ago
|
||
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.
status-b2g18:
--- → affected
status-b2g18-v1.0.0:
--- → wontfix
status-b2g18-v1.0.1:
--- → affected
status-firefox24:
--- → affected
Comment 15•11 years ago
|
||
(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)
Assignee | ||
Comment 16•11 years ago
|
||
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.
Assignee | ||
Comment 17•11 years ago
|
||
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.
Assignee | ||
Updated•11 years ago
|
Attachment #757197 -
Flags: review?(alive)
Assignee | ||
Updated•11 years ago
|
Attachment #757200 -
Flags: review?(alive)
Assignee | ||
Comment 18•11 years ago
|
||
To prevent things mixed, I created two PR one for master and another for v1.0.1.
Comment 19•11 years ago
|
||
Is v1-train use the same patch as master?
Assignee | ||
Comment 20•11 years ago
|
||
Yes, v1-train uses the same patch as master. master: https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/statusbar.js#L336 v1-train: https://github.com/mozilla-b2g/gaia/blob/v1-train/apps/system/js/statusbar.js#L298
Comment 21•11 years ago
|
||
Comment on attachment 757197 [details]
patch file for master
Looks good.
Attachment #757197 -
Flags: review?(alive) → review+
Updated•11 years ago
|
Attachment #757200 -
Flags: review?(alive) → review+
Assignee | ||
Comment 22•11 years ago
|
||
merged to master: https://github.com/mozilla-b2g/gaia/commit/b01f01ab2a948e5a08d274c212e56435c68c4875 merged to v1.0.1 https://github.com/mozilla-b2g/gaia/commit/fcae23654296c9cc645c2b7e77a2c36bf494803a
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 23•11 years ago
|
||
(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)
Assignee | ||
Comment 24•11 years ago
|
||
Yes this is applicable to v1-train. And, thanks for the change...
Flags: needinfo?(johu)
Updated•11 years ago
|
Comment 25•11 years ago
|
||
v1-train: 1a6ba0a
Comment 27•11 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•