1. Title : When calling number that device isn't saved, call screen shows similar number. 2. Precondition : Saved contact ( ex) 21113754 ) 3. Tester's Action : Call 2111375 4. Detailed Symptom : Call screen shows contact "21113754" 5. Expected : When calling to 2111375, call screen shows only "2111375" 6. Reproducibility: Y 1) Frequency Rate : 100% 7. Gaia revision : 5a1ead9c8f831167fd86464d21eea310c7082112

I modify content call screen shows similar number -> call screen shows contact of similar number

Triage 4/10 - Leo+ for high user impact.

mind taking a look?

(In reply to Joe Cheng [:jcheng] from comment #4) > mind taking a look? Well, we send a "contains" search request to the mozContacts database, so this behavior is incorrect but expected. Gregor, do you think an "endswith" kind of search is do-able for leo?

(In reply to Etienne Segonzac (:etienne) from comment #5) > (In reply to Joe Cheng [:jcheng] from comment #4) > > mind taking a look? > > Well, we send a "contains" search request to the mozContacts database, so > this behavior is incorrect but expected. > > Gregor, do you think an "endswith" kind of search is do-able for leo? This is expected behavior. We can change it if we don't want it but we had use-cases where we have to deal with phonenumber extensions. We should ask our UX team to help here.

We should be able to identify extensions by "p" or "," in a saved number right? The current expected behaviour is bad and I think somewhat worse than not showing those numbers saved with extensions. ni?josh for comment 6.

(In reply to Wayne Chang [:wchang] from comment #7) > We should be able to identify extensions by "p" or "," in a saved number > right? Not sure I follow... But anyway, I believe "extensions support" is always about the beginning of the phone number, never the end. So I'm not sure which use-cases are broken by an endswith search.

(In reply to Etienne Segonzac (:etienne) from comment #8) > (In reply to Wayne Chang [:wchang] from comment #7) > > We should be able to identify extensions by "p" or "," in a saved number > > right? > > Not sure I follow... > But anyway, I believe "extensions support" is always about the beginning of > the phone number, never the end. So I'm not sure which use-cases are broken > by an endswith search. If I understand correctly, the extension use cases Gregor mentioned are calling a number followed by an extension, for example someone at work number 01234567 with extension 456 would usually be stored in the phonebook as "01234567p456" or "01234567,456".

needsinfo to Rob Macdonald (FFOS UX) for Dialer question. Also changing needs info from Jaime to Joe (I think there was a mixup in comment 8).

I tried this on the latest engineering build (15 apr) and the error as reported is definitely a problem. I propose the contact name should only be displayed if there is an exact match, regardless of extensions (numbers followed by a "," or "p" character). The only exception would be country codes ("1" or "+1" in North America). This behavior is consistent with other devices. Gregor, can you point me to the use cases that involved extensions? I want to make sure I'm not breaking anything.

(In reply to Rob MacDonald [:robmac] from comment #11) > I tried this on the latest engineering build (15 apr) and the error as > reported is definitely a problem. > > I propose the contact name should only be displayed if there is an exact > match, regardless of extensions (numbers followed by a "," or "p" > character). The only exception would be country codes ("1" or "+1" in North > America). This behavior is consistent with other devices. > > Gregor, can you point me to the use cases that involved extensions? I want > to make sure I'm not breaking anything. So if we save a new number we should use PhoneNumberJS to normalize the number and remove all non-diable numbers and make the contact findable with this number. We will also try to convert the number to all known formats (international version, local version) and allow the contact to be found with them as well. Reuben is currently working on a patch.

Ups, didn't notice that Gregor was working on it :-O If you want me to take care of it, please tell ;-)

Per Gregor, Reuben Morais is actually working on this; reassigning.

(In reply to Michael Lee [:mlee] from comment #14) > Per Gregor, Reuben Morais is actually working on this; reassigning. I'm working on the Gecko mechanism to allow fixing this bug. Dialer will require changes when that one is fixed, and I would highly advise against assigning me to a blocker Gaia bug :)

…and that's bug 862250, marked as a dep in this bug.

Gregor, now that Reuben's fixed bug 862250 are you still confident that this one's a quick 1-liner you can land before Friday?

(In reply to Michael Lee [:mlee] from comment #17) > Gregor, now that Reuben's fixed bug 862250 are you still confident that this > one's a quick 1-liner you can land before Friday? Gah it's 2 lines... Only if the leo triage process is fast enough. All the code changes should be done.

Comment on attachment 743205 [details] PR pointer Comment on github, I think short numbers lookup should still do an equality lookup.

Comment on attachment 743205 [details] PR pointer Talked over the github comment on IRC and agreed on the change. r=me

Uplifted 5cfdae8ca2c748225d97cc2437fbce0368f96213 to: v1-train: eeef0fa4f62ddd2711280e153bf3cb54c410c1ab

Added test case in MozTrap: https://moztrap.mozilla.org/manage/case/8513/

Executed test case https://moztrap.mozilla.org/manage/case/8513/ and verified fixed on: Device: Leo phone Build Identifier: 20130611074722 Update channel: leo/1.1.0/nightly Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/8d0562d20324 Gaia: 8c64e19b82d4e0490a7780232d3d6bd07d0ba9ec1370937291 Git commit info: 2013-06-11 07:54:51 OS version: 1.1.0.0-prerelease and Device: Unagi phone Build Identifier: 20130611074722 Update channel: unagi/1.1.0/beta Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/8d0562d20324 Gaia: 8c64e19b82d4e0490a7780232d3d6bd07d0ba9ec1370937291 Git commit info: 2013-06-11 07:54:51 OS version: 1.1.0.0-prerelease