Closed Bug 859185 Opened 8 years ago Closed 7 years ago

[Dialer] When calling number that device isn't saved, call screen shows similar number.

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:leo+, b2g18 verified)

VERIFIED FIXED
1.1 QE1 (5may)
blocking-b2g leo+
Tracking Status
b2g18 --- verified

People

(Reporter: leo.bugzilla.gaia, Assigned: gwagner)

References

Details

(Whiteboard: [TD-9655] [depends on gecko uplifts])

Attachments

(2 files)

1.46 MB, video/mp4
Details
45 bytes, text/x-github-pull-request
etienne
: review+
Details | Review
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
Attached video Call_screen_error
I modify content

call screen shows similar number -> call screen shows contact of similar number
Severity: major → critical
blocking-b2g: --- → leo?
Triage 4/10 - Leo+ for high user impact.
blocking-b2g: leo? → leo+
mind taking a look?
Flags: needinfo?(etienne)
(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?
Flags: needinfo?(etienne) → needinfo?(anygregor)
(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.
Flags: needinfo?(anygregor)
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.
Flags: needinfo?(jcarpenter)
Whiteboard: [TD-9655]
(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.
Flags: needinfo?(jachen)
(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).
Flags: needinfo?(rmacdonald)
Flags: needinfo?(jcheng)
Flags: needinfo?(jcarpenter)
Flags: needinfo?(jachen)
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.
Flags: needinfo?(rmacdonald) → needinfo?(anygregor)
(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.
Flags: needinfo?(anygregor)
Target Milestone: --- → Leo QE1 (5may)
Flags: needinfo?(jcheng) → needinfo?
Flags: needinfo?
Assignee: nobody → gtorodelvalle
Ups, didn't notice that Gregor was working on it :-O If you want me to take care of it, please tell ;-)
Assignee: gtorodelvalle → anygregor
Depends on: 862250
Priority: -- → P1
Blocks: b2g-contact
Per Gregor, Reuben Morais is actually working on this; reassigning.
Assignee: anygregor → reuben.bmo
(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.
Assignee: reuben.bmo → anygregor
Depends on: 866135
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?
Attached file PR pointer
Attachment #743205 - Flags: review?(etienne)
(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] [review]
PR pointer

Comment on github, I think short numbers lookup should still do an equality lookup.
Attachment #743205 - Flags: review?(etienne)
Comment on attachment 743205 [details] [review]
PR pointer

Talked over the github comment on IRC and agreed on the change.

r=me
Attachment #743205 - Flags: review+
https://github.com/mozilla-b2g/gaia/commit/5cfdae8ca2c748225d97cc2437fbce0368f96213
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Whiteboard: [TD-9655] → [TD-9655] [depends on gecko uplifts]
Uplifted 5cfdae8ca2c748225d97cc2437fbce0368f96213 to:
v1-train: eeef0fa4f62ddd2711280e153bf3cb54c410c1ab
Flags: in-moztrap?
Added test case in MozTrap: 
https://moztrap.mozilla.org/manage/case/8513/
Flags: in-moztrap? → in-moztrap+
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
Status: RESOLVED → VERIFIED
Attachment mime type: text/plain → text/x-github-pull-request
You need to log in before you can comment on or make changes to this bug.