[Dialer][SMS][Contacts] Call log does no longer show contact names after version upgrade

RESOLVED FIXED in Firefox 25, Firefox OS v1.1hd

Status

()

Core
DOM: Device Interfaces
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: whimboo, Assigned: mikehenrty)

Tracking

({dataloss, regression})

unspecified
mozilla25
ARM
Gonk (Firefox OS)
dataloss, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:leo+, firefox23 wontfix, firefox24 wontfix, firefox25 fixed, b2g18 fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 wontfix, b2g-v1.1hd fixed)

Details

(Whiteboard: [migration][fixed-in-birch])

Attachments

(2 attachments, 1 obsolete attachment)

1.70 KB, patch
gwagner
: review+
Details | Diff | Splinter Review
1.24 KB, patch
reuben
: review+
Details | Diff | Splinter Review
(Reporter)

Description

4 years ago
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/f1b84d841ced
Gaia   0b0cd9ee3eb9fb09f8505214615492bcc5eff7da
BuildID 20130616230206
Version 18.0

Since I have updated my phone from the build below, the call does no longer show contact names. Only the phone numbers called are visible. This is a regression between builds 20130613230207 and 20130616230206.

Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/537f3eac4c48
Gaia   0c836be7f24693b74ad7fd21c8153824f1c7f548
BuildID 20130613230207
Version 18.0
(Reporter)

Comment 1

4 years ago
Might be this is caused by a Gecko change? In the call log I only see normalized phone numbers without brackets and spaces while in my contacts every one has those special characters.
Bug 871930 removed some magic we had in Dialer, not sure this is related (because it landed before your 20130613 build). Maybe Etienne will have more information.
Blocks: 883821
(Reporter)

Comment 3

4 years ago
This even doesn't work for local numbers without the country prefix and any brackets nor spaces. Just a number like 0351123456 will fail to show the contact name in the call log.

Updated

4 years ago
Blocks: 883750

Updated

4 years ago
Blocks: 883756
Can you try to delete the contact and add it again? This might be an issue of a missing DB migration code.
Henrik: Can you add a screenshot of what you see? Parul has been testing this today to see if she can reproduce.
Flags: needinfo?(hskupin)
(In reply to Gregor Wagner [:gwagner] from comment #4)
> Can you try to delete the contact and add it again? This might be an issue
> of a missing DB migration code.

Yep. The call log is working okay.
Looks like a migration issue :/
Component: Gaia::Dialer → DOM: Device Interfaces
Product: Boot2Gecko → Core
same thing for SMS by the way.

* the contact would not match on a number (no difference in internationalization, space, etc, it was a plain internationalized number both in sms and in contact)
* I updated the contact, changed a number and put it back
=> it was matching again.
I'd like to add that my contacts were freshly imported contacts from GMail, so I don't think it was a migration problem for me, but I may miss something.
(Reporter)

Comment 9

4 years ago
(In reply to Julien Wajsberg [:julienw] from comment #7)
> both in sms and in contact)
> * I updated the contact, changed a number and put it back
> => it was matching again.

Yeah, I can confirm that! I have only updated the name of the contact and checked the call log and sms list. Now the name is displayed correctly again. So what kind of migration issue could this be? Have we updated the schema of the contacts database lately, and with the update of the contact we correctly write out the information?

If that is the case it seems to be very important to get fixed before any of our users will get updated from 1.0 to 1.1.

I don't think the request for a screenshot is still valid? Given that others do also see that.
Flags: needinfo?(hskupin)

Updated

4 years ago
Assignee: nobody → dscravaglieri
blocking-b2g: leo? → leo+
Keywords: dataloss
Whiteboard: [migration]
We need leo+ on this, lots of contact matching is broken right now because of this.
Blocks: 885587
We know what's going on here. It's the missing migration code for the match field.
Reuben can you take this?
Assignee: dscravaglieri → reuben.bmo
Summary: [Dialer][Contacts] Call log does no longer show contact names → [Dialer][Contacts] Call log does no longer show contact names after version upgrade
What missing migration?

https://mxr.mozilla.org/mozilla-central/source/dom/contacts/fallback/ContactDB.jsm#329
Duplicate of this bug: 885587
Summary: [Dialer][Contacts] Call log does no longer show contact names after version upgrade → [Dialer][SMS][Contacts] Call log does no longer show contact names after version upgrade
Created attachment 767071 [details] [diff] [review]
patch
Assignee: reuben.bmo → anygregor
Attachment #767071 - Flags: review?(bent.mozilla)
Ah how much do I love this upgrade scenario.
The bad thing is that this doesn't solve the problem for people that already see this bug. This will only solve it for users that haven't upgraded yet.
(Reporter)

Comment 16

4 years ago
Would another update of the schema help here?
(In reply to Henrik Skupin (:whimboo) [away 06/28 - 07/07] from comment #16)
> Would another update of the schema help here?

Yeah I was thinking more about it. We should make the buggy upgrade code a noop and bump the revision number again with a correct upgrade code.
Michael is taking care of it :)
Assignee: anygregor → mhenretty
Attachment #767071 - Flags: review?(bent.mozilla) → review+
Based on comment 11 and having a patch, removing regressionwindow-wanted.
Keywords: regressionwindow-wanted
Created attachment 767570 [details] [diff] [review]
Patch with upgrade path fix
Attachment #767071 - Attachment is obsolete: true
Attachment #767570 - Flags: review+
https://hg.mozilla.org/projects/birch/rev/56172e239ed5
Whiteboard: [migration] → [migration][fixed-in-birch]
https://hg.mozilla.org/mozilla-central/rev/56172e239ed5
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
https://hg.mozilla.org/releases/mozilla-b2g18/rev/c01b9ca8d218
status-b2g18: affected → fixed
status-b2g18-v1.0.0: --- → wontfix
status-b2g18-v1.0.1: --- → wontfix
status-b2g-v1.1hd: --- → affected
status-firefox23: --- → wontfix
status-firefox24: --- → wontfix
status-firefox25: --- → fixed
https://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/c01b9ca8d218
status-b2g-v1.1hd: affected → fixed
Created attachment 769995 [details] [diff] [review]
Followup

My mistake :(
Attachment #769995 - Flags: review?(reuben.bmo)
Comment on attachment 769995 [details] [diff] [review]
Followup

Review of attachment 769995 [details] [diff] [review]:
-----------------------------------------------------------------

Good catch.
Attachment #769995 - Flags: review?(reuben.bmo) → review+
Followup:
https://hg.mozilla.org/releases/mozilla-b2g18/rev/b9547f9afe33
https://hg.mozilla.org/projects/birch/rev/f921263b8cc7
https://hg.mozilla.org/mozilla-central/rev/f921263b8cc7
https://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/b9547f9afe33
I wonder if there should be another follow up, because the 'match' search does not match anything now.

(however, 'contains' search still works ok)
Flags: needinfo?(anygregor)
(Reporter)

Comment 30

4 years ago
Whatever has been done here, this is not fixed on my Unagi for the nightly channel:

Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/39607fd11f6b
Gaia   d336288e6cda1a8f974ceea41b9d7860c2367d1f
BuildID 20130706230209
Version 18.0
status-b2g18: fixed → affected
I verified this works for new contact but still not for the old ones :(

Michael, Gregor, can I somehow investigate what's inside the indexeddb ?
(Reporter)

Comment 32

4 years ago
Julien, I assume that we should reopen the  bug completely, or? I don't think that it will be fixed on trunk either.
Julien, you can see what's in the contacts DB by using bent's IndexedDB FF extension: https://addons.mozilla.org/en-US/firefox/addon/indexeddb-browser/

To use the extension for this purpose, you will need to first adb pull the contacts sqlite file off the phone and place it in your FF profile folder for indexeddb (also make sure to delete any .DS_Store files if you're using MacOS finder to move stuff around). Restart your browser, then open the IndexedDB browser (Tools->Web Developer->IDB Browser), and drill into the DB named "contacts." Inside "contacts" there will be another "contacts" entry, click on this and click the Load Data button. Here you should see all your contacts. If you examine the the value of one, you should see a "parsedTel" entry in the JSON string. If it's missing, the upgrade probably failed. Let me know if you encounter any hiccups, cause I had to do some wrangling to get it to work for me.

Reopening this bug for further investigation.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
It seems that the problem comes with using |this.substringMatching| in most places except the migration path.

Therefore, for a number +33123456789, we try to match 23456789 whereas only +33123456789, 123456789 and 0123456789 are in the index. However, adding/updating or importing generates the index correctly.
Guys - Can you file a followup bug for this?
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
status-b2g18: affected → fixed
tracking-b2g18: ? → ---
Resolution: --- → FIXED
Right,

Could use the just-filed Bug 890909 (that I was going to dupe ;) ).
Blocks: 890909
(In reply to Julien Wajsberg [:julienw] from comment #34)
> It seems that the problem comes with using |this.substringMatching| in most
> places except the migration path.
> 
> Therefore, for a number +33123456789, we try to match 23456789 whereas only
> +33123456789, 123456789 and 0123456789 are in the index. However,
> adding/updating or importing generates the index correctly.

Hm I don't see how this can reduce the search space. The substringMatching only adds the last x digits to the search space but we should still find the number with the national formats. 
What format is 23456789 in your example? Isn't 0123456789 or 123456789 the local format?
Flags: needinfo?(anygregor)
It reduces the search space because the value that is looked for is only the sliced value... which is not in the index.

see https://mxr.mozilla.org/mozilla-central/source/dom/contacts/fallback/ContactDB.jsm#893

When investigating with Mike, we found that being in France I should not be using the sliced value, but because "init" is called too soon, we always end up with the default brazil configuration. 

But that's another issue, and we should file another bug for this. I also don't understand why we don't always slice for all countries... because we don't want to match 2 similar numbers from 2 different countries?
status-b2g18: fixed → affected
status-b2g-v1.1hd: fixed → affected
status-firefox25: fixed → affected
(Reporter)

Comment 39

4 years ago
Julien, why did you move the status to affected again? I thought we have bug 890909 for the followup work now?
completely right, I mixed up my bugs, sorry.
status-b2g18: affected → fixed
status-b2g-v1.1hd: affected → fixed
status-firefox25: affected → fixed
You need to log in before you can comment on or make changes to this bug.