900480 - mozContacts.find with filter 'match' provides disparate results with different SIM cards

Status: RESOLVED WORKSFORME

(Core :: DOM: Device Interfaces, defect)

Description

[Jose Manuel Cantera]

import the attached vcard file as contacts on your device. 

execute navigator.mozContacts.find({
  filterBy: 'tel',
  filterOp: 'match'
  filterValue: '' 
});

with no SIM attached on the device or with a Spanish SIM. 

-->  There is one result. : OK

execute the same API call with a Vivo's SIM 

--> there are no results. : KO

Comment 1

[Jose Manuel Cantera]

Attachment: vcard_sergi.vcf

attachment with test contacts

Comment 2

[Jose Manuel Cantera]

(In reply to Jose M. Cantera from comment #0)
> import the attached vcard file as contacts on your device. 
> 
> execute navigator.mozContacts.find({
>   filterBy: 'tel',
>   filterOp: 'match'
>   filterValue: '[phone]' 
> });
> 
> with no SIM attached on the device or with a Spanish SIM. 
> 
> -->  There is one result. : OK
> 
> execute the same API call with a Vivo's SIM 
> 
> --> there are no results. : KO

Comment 3

[Gregor Wagner [:gwagner]]

(In reply to Jose M. Cantera from comment #0)
> import the attached vcard file as contacts on your device. 
> 
> execute navigator.mozContacts.find({
>   filterBy: 'tel',
>   filterOp: 'match'
>   filterValue: '' 
> });
> 
> with no SIM attached on the device or with a Spanish SIM. 
> 
> -->  There is one result. : OK
> 
> execute the same API call with a Vivo's SIM 
> 
> --> there are no results. : KO

The vivo sim is from Brazil?

Comment 4

[Reuben Morais [:reuben]]

NI? myself so I don't forget to check this.

Comment 5

[Jose Manuel Cantera]

(In reply to Gregor Wagner [:gwagner] from comment #3)
> (In reply to Jose M. Cantera from comment #0)
> > import the attached vcard file as contacts on your device. 
> > 
> > execute navigator.mozContacts.find({
> >   filterBy: 'tel',
> >   filterOp: 'match'
> >   filterValue: '' 
> > });
> > 
> > with no SIM attached on the device or with a Spanish SIM. 
> > 
> > -->  There is one result. : OK
> > 
> > execute the same API call with a Vivo's SIM 
> > 
> > --> there are no results. : KO
> 
> The vivo sim is from Brazil?

Yes

Comment 6

[Julien Wajsberg [:julienw]]

Jose, can you tell us which Gecko version you're using ? Several lookup problems have been fixed recently.

Comment 7

[Jose Manuel Cantera]

(In reply to Julien Wajsberg [:julienw] from comment #6)
> Jose, can you tell us which Gecko version you're using ? Several lookup
> problems have been fixed recently.

d9a90f1

Comment 8

[Reuben Morais [:reuben]]

Reproduced with a Vivo SIM card. Same problem will happen for any SIM card with an MMC that has substring matching enabled. We save data in the ContactDB indexes that changes based on the SIM card, so to fix this we would need to go through all contacts and update their indexes when we detect a SIM card change.

Comment 9

[Julien Wajsberg [:julienw]]

(In reply to Reuben Morais [:reuben] from comment #8)
> Reproduced with a Vivo SIM card. Same problem will happen for any SIM card
> with an MMC that has substring matching enabled. We save data in the
> ContactDB indexes that changes based on the SIM card, so to fix this we
> would need to go through all contacts and update their indexes when we
> detect a SIM card change.

do we really want to do this ?

The substring count is currently defined as a pref, but does it really change or can we assume that substring matching is always done with 7 characters ?

If we can assume this, then it's way easier: always store the substring match in the index, but chose if we should use this as a filter value depending on the sim card. Would that work ?

Comment 10

[Reuben Morais [:reuben]]

(In reply to Julien Wajsberg [:julienw] from comment #9)
> (In reply to Reuben Morais [:reuben] from comment #8)
> > Reproduced with a Vivo SIM card. Same problem will happen for any SIM card
> > with an MMC that has substring matching enabled. We save data in the
> > ContactDB indexes that changes based on the SIM card, so to fix this we
> > would need to go through all contacts and update their indexes when we
> > detect a SIM card change.
> 
> do we really want to do this ?
> 
> The substring count is currently defined as a pref, but does it really
> change or can we assume that substring matching is always done with 7
> characters ?

Right now we have 8 for Brazil, 10 for Colombia and 7 for Venezuela… So I'm going to say we can't :)

Comment 11

[Julien Wajsberg [:julienw]]

:(

Then maybe we can store all these possible substring match in the index, like we already do for the iterative search. It will make the index quite big but at least we will always have the same index no matter the SIM card.

Or maybe it's possible to do a range like [1] ?

[1] https://mxr.mozilla.org/mozilla-central/source/dom/contacts/fallback/ContactDB.jsm#1079

Comment 12

[Julien Wajsberg [:julienw]]

ok taking it, I hope do be able to do this during this sprint.

Comment 13

[Reuben Morais [:reuben]]

(In reply to Julien Wajsberg [:julienw] from comment #11)
> Then maybe we can store all these possible substring match in the index,
> like we already do for the iterative search. It will make the index quite
> big but at least we will always have the same index no matter the SIM card.

You'd have to store them in several different indexes, but yes, that's a possibility if we're willing to live with the extra workload.

Comment 14

[Gregor Wagner [:gwagner]]

This should be a dup of bug 877302. Can you test again?

Comment 15

[Gregor Wagner [:gwagner]]

Sorry it should be bug 905927.

Comment 16

[isabelrios]

Hi, 
Cannot reproduce this bug with unagi master build:
ecko-fe76476
Gaia-cfcea74
Changing status to WFM