Closed Bug 1054818 Opened 8 years ago Closed 5 years ago

[Sora][Call][Settings]The call time display abnormal after user change the system time.


(Firefox OS Graveyard :: Gaia::Dialer, defect)

Not set


(b2g-v1.3 affected, b2g-v2.2 affected, b2g-master affected)

Tracking Status
b2g-v1.3 --- affected
b2g-v2.2 --- affected
b2g-master --- affected


(Reporter: sync-1, Unassigned)



(Whiteboard: [planned-sprint c=?])


(7 files, 1 obsolete file)

Firefox OS v1.3
 Mozilla build ID:20140422024003
 The call time display abnormal after user change the system time.
 1.Establish a call(10086)
 2.Tap home key back to idle screen
 3.Launch "Settings" app -> Data&Time
 4.Change the system time 
 5.The call time also be changed(KO)
 KO:The call time should not be changed.
 For FT PR, Please list reference mobile's behavior:
Attached file jrdlog
Attached image Screenshot
Attached file log

This bug also happens in V2.1, could you please help to check it?
Flags: needinfo?(vchen)
Hi Etienne -

Could you help to take a look at this one? it happens on master as well. if the user changes the time/date setting while in-call, the call duration time will change as well.


Flags: needinfo?(vchen) → needinfo?(etienne)
Redirecting since I didn't follow the new developments around system time.
Flags: needinfo?(etienne) → needinfo?(drs+bugzilla)
I don't know much about this either, but I did some digging and it seems that the MozTimeManager web API doesn't provide an event for the system time changing. I wrote up a quick Gecko patch to add this, but then I looked further and found that there's an "onmoztimechange" event fired on the window element. This doesn't have blocking/feature status though, so I'm not going to get to this until after FL.
Whiteboard: [dialer-most-wanted]
I am adding qawanted to check if this is a regression in 1.3. Also interested in knowing if this has always been a problem or did we write something in 1.3 that this fallout is caused.
Keywords: qawanted
This is not a regression. The duration time comes from ( - startTime), so if changing the system time/date, is changing with it. The duration time is changed.
This bug does occur in 1.3 Flame. Adjusting the system time while in a call will also adjust the in call duration time.

***NOTE: I also found that adjusting the hours, kicks the user out of the time selector settings back to the call screen. This was rather unexpected.

Environmental Variables:
Device: Flame 1.3
Build ID: 20140627162151
Gaia: 5c43d012a9351e8aaeacda0b87b0886b7f67d33d
Gecko: e181a36ebafaa24e5390db9f597313406edfc794
Version: 28.0 (1.3)
Firmware Version: v123
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Contact: croesch
Qa-Wanted triage analysis: Not a regression, not a common user path / action
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
If someone wants to take this, here's my plan for it:

* Currently, we pass the start time into setInterval() and hold onto this for the duration of the call. [1]
* We should instead store the start time on the DOM of the duration element, perhaps as data-start-time. [2]
* We will also need to store the unlocalized duration, perhaps as data-duration. This should be updated every time the duration element itself is. [2]
* We then hook the "moztimechange" event. In here, we iterate over every duration element, and calculate its start time backwards with: |data-start-time = - data-duration|. [2]

Note that we must do this backwards calculation instead of storing just a duration. The reason being that setTimeout() is unreliable and may not be called every second as requested. Indeed, the time it's actually called at usually has a significant epsilon. So by basing our calculations on a start time, we're never accumulating an error.

[2] This should be unit tested.
Flags: needinfo?(drs+bugzilla)
Whiteboard: [dialer-most-wanted]
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Assignee: nobody → david.garciaparedes
Attached file patch (obsolete) —
Attachment #8487982 - Flags: review?(drs+bugzilla)
Comment on attachment 8487982 [details] [review]

This is good. I left some comments on the PR that are mostly related to commenting.
Attachment #8487982 - Flags: review?(drs+bugzilla) → review-

This patch doesnot take the following case in account:
1.Outgoing a call to B, A-B ; And outgoing another call to C,A-C;
2.Merge these two call to a conference call A-BC.
3.Change the system time during the call, the duration for the conference call is right;
4.Hang up A-B, then B left the conferenc call, the call display is update, but the duration for A-C is still not right.

In function timechangeHandler(), var durationNodes = this.calls.querySelectorAll('.duration'); When there is a conference call, there is no '.duration' for every seperated calls. So the duration for these calls is still not update.
Whiteboard: [planned-sprint]
Target Milestone: --- → 2.1 S5 (26sep)
Gabriele suggested using instead of the method described in comment 12. It should be as simple as replacing with instead of all the DOM goop.

We should also file a followup to address the lack of the previous and new times in the moztimechange event.
David mentioned that doesn't work properly with the sinon.clock API. The attached patch stubs to use instead, and should work for this purpose. The one thing I don't like is that we lose the precision of the Performance API, since it goes to msec but only goes to sec.
Attached file patch v2
New patch using
I tried the mock, but I was not able to test the time change part because the mock is relaying on
I'm stubbing with this:

  this.sinon.stub(performance, 'now', function() {
Attachment #8487982 - Attachment is obsolete: true
Attachment #8490042 - Flags: review?(drs+bugzilla)
Comment on attachment 8490042 [details] [review]
patch v2

Thanks for making the extra effort to add a test that makes sure that system time changes don't affect the duration. In this case, I don't think it makes sense to test that, since it's a property of the differences between the Performance and Date APIs. I left a couple of comments but this is otherwise great, and I'm happy that we found this simpler method.
Attachment #8490042 - Flags: review?(drs+bugzilla) → review+
Merged in master (David has not permission in Gaia to merge pr's):
Closed: 8 years ago
Resolution: --- → FIXED
QA Contact: croesch
Resolution: FIXED → ---
Reverted on v2.2:
Reverted on master:
Assignee: david.garciaparedes → nobody
Priority: P2 → --
Whiteboard: [planned-sprint] → [planned-sprint c=?]
Target Milestone: 2.1 S5 (26sep) → ---
See Also: → 1150766
link all Fire C (codename: Sora) bugs to a meta one.
Firefox OS is not being worked on
Closed: 8 years ago5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.