Closed Bug 1151627 Opened 9 years ago Closed 9 years ago

[Dialer] "TODAY" appears twice in the call log

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:2.5+, b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 affected, b2g-master verified)

VERIFIED FIXED
blocking-b2g 2.5+
Tracking Status
b2g-v2.0 --- affected
b2g-v2.1 --- affected
b2g-v2.2 --- affected
b2g-master --- verified

People

(Reporter: ychung, Assigned: drs)

References

Details

(Whiteboard: [3.0-Daily-Testing])

Attachments

(6 files, 1 obsolete file)

Attached image TodayTwice.png
Description:
When the user selects the "Screenshot save to Gallery" notification from the notification tray, "The screenshot could not be saved" notification appears and replaces the previous screenshot notification. Instead, the user has to be notified that the memory card is in use and the device has to be unplugged.

Repro Steps:
1) Update a Flame to 20150406010204.
2) Open Dialer, and make a few incoming, outgoing calls.
3) Observe the call log.

Actual:
"TODAY" appears twice.

Expected:
"TODAY" only appears once.

Environmental Variables:
Device: Flame 3.0 (KK, 319mb, full flash)
Build ID: 20150406010204
Gaia: ef61ebbe5de8c2c9fc2a8f74a12455044c3b82e9
Gecko: 4fe763cbe196
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

Repro frequency: once

Note: I observed this issue only once, and unable to reproduce this issue. I did not changed the date, time, or "Set Automatically" toggle between the phone calls. Leaving steps-wanted.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
I was able to get STRs with 100% repro rate:

STR:
1) Go to settings > Date & Time > Disable "Set Automatically".
2) Open Dialer, and make an outgoing call.
3) Close the Dialer app.
4) Go to settings > Date & Time > Enable "Set Automatically".
5) Open Dialer, and make an outgoing call.
6) Open Call log.

Actual:
"TODAY" appears twice.

Expected:
"TODAY" only appears once.

Environmental Variables:
Device: Flame 3.0 (KK, 319mb, full flash)
Build ID: 20150406010204
Gaia: ef61ebbe5de8c2c9fc2a8f74a12455044c3b82e9
Gecko: 4fe763cbe196
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0
This issue also reproduces on Flame 2.2, 2.1, 2.0.

Result: "TODAY" can be shown multiple times in the call log.

Environmental Variables:
Device: Flame 2.2 (KK, 319mb, full flash)
Build ID: 20150406002503
Gaia: a6351e1197d54f8624523c2db9ba1418f2aa046f
Gecko: c3335a5d3063
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Environmental Variables:
Device: Flame 2.1 (KK, 319mb, full flash)
Build ID: 20150406001204
Gaia: 87e55a7ec688138812181747f690fd188d2a0668
Gecko: 747b6132c44d
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 34.0 (2.1)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Environmental Variables:
Device: Flame 2.0 (KK, 319mb, full flash)
Build ID: 20150406000203
Gaia: 84898cadf28b1a1fcd03b726cff658de470282f0
Gecko: e4014ac859af
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 32.0 (2.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

=======================================

This issue does NOT reproduce on Flame v18D-1(2.0) base image only

Result: "TODAY" only appears once.
Not nominating to block on this. It is not a regression and considering the steps involved, I don't think this will be encountered by many end users.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
The 100% steps are relying on the clock which is not known for its reliability. Do you think it's a call log or a time issue, Gabriele?
Flags: needinfo?(gsvelto)
I don't think it's a clock issue but rather a call log one. If the time changes the call log should properly re-group the entries accordingly but apparently it doesn't. It would be interesting to know if this can be reproduced by manually changing the date:

- Set the date to a certain time
- Make a call
- Close the dialer
- Set the date to a different time
- Make a call
- Observe the bug

Obviously the trick would be to figure out what time difference is causing this.
Flags: needinfo?(gsvelto)
Steps wanted to try comment 5. Let's find out if the it happens when you back or forward in time. Let's also check if changing the time zone affects the behavior.
Keywords: steps-wanted
Call Log exhibits extremely odd behavior when the user attempts to manipulate the time frequently in between making calls.
Following the steps of comment 5:

*) Time & Date starts at 'Automatic'
1) Make a call; receive a call
2) Close the dialer
3) Set time and date to manual: go forward one hour
4) Make a call; receive a call
5) Close the dialer
6) Set time and date 2 hours back (an hour before initial entry)

Results:
Call log creates multiple 'Today' entry fields when the user jumps an hour ahead or behind. These fields end up holding overlapping data and exposing similar timestamps in a non-chronological order of time.

Attached:
screenshot

Device: Flame 3.0
BuildID: 20150408010203
Gaia: 84cbd4391fb7175d5380fa72c04d68873ce77e6d
Gecko: 078128c2600a
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0
Based on comment 7, any time difference will trigger the duplicate entry.
tracking-b2g: --- → +
Keywords: steps-wanted
[Tracking Requested - why for this release]:
Priority: -- → P1
(In reply to Oliver Nelson [:oliverthor] from comment #7)
> Call log creates multiple 'Today' entry fields when the user jumps an hour
> ahead or behind. These fields end up holding overlapping data and exposing
> similar timestamps in a non-chronological order of time.

Thanks for confirming this. The call log database code is probably not adjusting the groupings when the time changes. We should listen on |moztimechange| and adjust the call groups accordingly.
Blocks: 1117804
Carrying 2.5+ from bug 1194573.
blocking-b2g: --- → 2.5+
Assignee: nobody → drs
Status: NEW → ASSIGNED
Comment on attachment 8657365 [details] [review]
[gaia] DouglasSherk:1151627-call-log-today-twice > mozilla-b2g:master

The fix for this ended up being fairly simple. We were encoding the user's timezone in the value returned by |Utils.getDayDate()|, which ended up manifesting itself in the |<Date instance>.getTime()| value.

For example, in the UTC-5 timezone today, you would get:
|Utils.getDayDate() = 2015-09-04 5:00 am| -> |1441339200000|.

When the user switches to another timezone, say UTC-4, the return would then be:
|Utils.getDayDate() = 2015-09-04 4:00 am| -> |1441342800000|.

The fix is to force |new Date()| to the UTC TZ at the first millisecond of the day. This is done by passing no timezone into |Date.parse()|, which makes it default to the UTC TZ.

Having said that, this is liable to break a lot of call log functionality. Once this passes technical review, I'm going to ask QA to test it heavily before landing.
Attachment #8657365 - Flags: review?(gsvelto)
Comment on attachment 8657365 [details] [review]
[gaia] DouglasSherk:1151627-call-log-today-twice > mozilla-b2g:master

LGTM but I've got a couple of comments:

- I've noticed that the SMS app (which has similar grouping concerns) has a function with the exact same name but a relatively different implementation. From a very cursory glance it doesn't seem to suffer from this specific problem but I'm not super-sure:

https://github.com/mozilla-b2g/gaia/blob/0b835313bc031dc9cfcab57af2340c0bab88e2b1/apps/sms/views/shared/js/utils.js#L73

- It seems we're using getDayDate() only in the call_log_db.js code so we should cull it from the Utils object and move it there, ditto for the tests.
Attachment #8657365 - Flags: review?(gsvelto) → review+
Comment on attachment 8657365 [details] [review]
[gaia] DouglasSherk:1151627-call-log-today-twice > mozilla-b2g:master

This is pretty substantially different now. Could you review it again?
Attachment #8657365 - Flags: review+ → review?(gsvelto)
Comment on attachment 8657365 [details] [review]
[gaia] DouglasSherk:1151627-call-log-today-twice > mozilla-b2g:master

Excellent, everything's fine, thanks.
Attachment #8657365 - Flags: review?(gsvelto) → review+
https://github.com/mozilla-b2g/gaia/commit/029213d0309168a45f2e79c1f9d35ad05004c9eb

Opted not to go through QA testing since we ended up copying the SMS code, which is already in heavy use.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
This bug has been verified as "pass" on the latest build of Flame KK 2.5 and Aires KK 2.5 by the STR in comment 7.

Actual results: Only showing one "Today" in call log.
See attachment: verified_Aries_v2.5.3gp
Reproduce rate: 0/10


Device: Flame KK 2.5 (Pass)
Build ID               20150923150203
Gaia Revision          8472f0c736660072799aaae60e4b6001a6aaceb4
Gaia Date              2015-09-23 10:29:02
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/4a46de29431baa621d98d8f1168e43297ce1a916
Gecko Version          44.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150923.184655
Firmware Date          Wed Sep 23 18:47:17 EDT 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0

Device: Aries KK 2.5 (Pass)
Build ID               20150923233246
Gaia Revision          8472f0c736660072799aaae60e4b6001a6aaceb4
Gaia Date              2015-09-23 10:29:02
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/f1dffc8682fbba463cb4bb305f293ddcccbc20b4
Gecko Version          44.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20150923.225204
Firmware Date          Wed Sep 23 22:52:12 UTC 2015
Bootloader             s1
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
Depends on: 1207646
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: