Description: After being called by a contact and a new number, adding second new number to existing contact then deleting 2nd number will cause call log to show number incorrectly (after restart of Phone app - will show name not number). Adding that 2nd number to contact again and restart of Phone app will cause number to appear in Call log when it is attached to a contact. Repro Steps: *Start with a contact (saved in Phone app) from number that can call your device 1) Update a Flame device to BuildID: 20141215040201 2) Get called by contact that is already saved in Phone app > End call 3) Get called by other number that isn't saved in Phone app > End call 4) Long press on non-contact number > select Call Information > Add to existing contact > Add as 2nd number to saved contact that called 5) Close/reopen Phone app > Go to Call Log > Notice if contact name is on both calls 6) Go to Contacts tab > Tap on contact > Tap Edit > Delete 2nd phone number > Update contact 7) Close/reopen Phone app > Go to Call Log Actual: When deleting 2nd phone number on a contact then restarting Phone app, the Call log will not show the contact name on first phone number. Expected: Call Log is always synced with all contact phone numbers when adding/deleting second phone number of contacts. Environmental Variables: Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash) BuildID: 20141215040201 Gaia: e2a3e606675c346b6e6f35351a458040be599b09 Gecko: f14dcd1c8c0b Gonk: 263b5f41f7733c5577fb101eb4dc8ac5c11cfa8d Version: 37.0a1 (2.2 Master) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 Repro frequency: 100%, 4/4 See attached: video clip (http://youtu.be/A1Xct0e7FpM), logcat (calllog_logcat.txt)
Issue occurs on Flame 2.0 and Flame 2.1. Call Log does not properly sync with contact phone numbers when adding/deleting 2nd phone number. When deleting 2nd phone number on a contact then restarting Phone app, the Call log will not show the contact name on first phone number. Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash) Build ID: 20141216001202 Gaia: 79286eafe67707d1330966c1b1413b2d0de595d9 Gecko: 222a62b532db Gonk: e5c6b275d77ca95fb0f2051c3d2242e6e0d0e442 Version: 34.0 (2.1) Firmware Version: v188-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Device: Flame 2.0 (319mb)(Kitkat Base)(Full Flash) Build ID: 20141216000202 Gaia: f3b9806f687fbbd7eba6b0e1f6ebb8bde09840ea Gecko: 12aea1649f5a Gonk: e5c6b275d77ca95fb0f2051c3d2242e6e0d0e442 Version: 32.0 (2.0) Firmware Version: v188-1 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
After reproducing this bug on my own devices I was seeing a lot of strange behavior where the number would randomly be attached to the number, and then detached from the number. This could be confusing for the end user. NI Dialer owner for a blocking decision
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(dharris) → needinfo?(jlorenzo)
I reproduced the issue. One thing major here is that even if the contact calls you with the first phone number, his name won't appear until you delete the broken entry in the call log. So we loose the link between a contact and his phone number. [Blocking Requested - why for this release]: Data loss, a phone number is no more attached to a contact once a user triggers that bug.
blocking-b2g: --- → -
Whiteboard: [2.2-exploratory-2] → [2.2-exploratory-2][planned-sprint c=?]
Target Milestone: --- → 2.2 S3 (9jan)
Triage: The functionality is broken if a user triggers this bug.
Whiteboard: [2.2-exploratory-2][planned-sprint c=?] → [2.2-exploratory-2][planned-sprint c=3]
While trying to reproduce this bug I've noticed that it goes beyond the STR described in comment 0. While trying the STR using the light reference workload I managed to get into the following scenario: - Two calls in the call log, the first to number 123, the second to number 456 - A contact containing the number 456 which previously contained the 123 number too - The call log displays the calls from number 456 as a plain number and the ones from 123 as the contact (!) There must be something seriously wrong with CallLogDB.invalidateContactsCache().
Status: NEW → ASSIGNED
After some quick checking I think I know what's wrong: I had to modify part of that code in bug 1112577 because it creates a readonly IndexedDB transaction and from within it launches a readwrite transaction on the same group if some contacts were updated. That's bound to fail in various spectacular ways which explains why I managed to get into the situation described in comment 5. I'll block on bug 1112577 because it's pointless to try to address this until the CallLogDB code is abusing the IndexedDB API in ways that are guaranteed to fail.
Depends on: 1112577
This was fixed by the patch for bug 1112577.
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Resolution: FIXED → DUPLICATE
Duplicate of bug: 1112577
Verified against master: Build ID 20150219160225 Gaia Revision 0d9a825dd27ed63f877d5140a08327cc8f91ec74 Gaia Date 2015-02-19 19:55:26 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/51458a066fda Gecko Version 38.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150219.193017 Firmware Date Thu Feb 19 19:30:28 EST 2015 Bootloader L1TC000118D0
You need to log in before you can comment on or make changes to this bug.