Closed Bug 838095 Opened 12 years ago Closed 11 years ago

[CONTACTS][SMS] If you have a contact with a phone number that is part of the phone number of other contact, when you try to send a SMS from contact details, wrong information is shown in recipients header

Categories

(Firefox OS Graveyard :: Gaia::Contacts, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:-, b2g18+)

RESOLVED FIXED
blocking-b2g -
Tracking Status
b2g18 + ---

People

(Reporter: carlosmartinez, Unassigned)

References

Details

Attachments

(1 file)

Attached image Wrong header in SMS app (deleted) —
Tested in unagi with Gecko-e2abfaf.Gaia-00c0349 STR: 1-Open contacts app 2-Create a contact with a phone number (e.g. 616454545) 3-Create another contact with a phone number (e.g. 616) 4-Open contact details for the second contact 5-Send a SMS from this screen Expected result --> The name of the second contact is shown in SMS app Actual result --> The name of one of the contacts is shown plus "and 1 more"
I'm thinking this doesn't mean that anyone with a shared area code would all show up in the header. Can we get some QA around this to determine if it only shows up when you use a subset of a number (and thus, not likely 'real' number) like 616 or if this can happen with numbers of the same length?
Keywords: qawanted
blocking-b2g: tef? → -
Gregor, in SMS App in Gaia we are using 'contains' for the filter to Contacts API, that's why we are getting this weird behaviour. Should we move to 'equal'? Or this is the result expected? Thanks!
Flags: needinfo?(anygregor)
(In reply to Borja Salguero [:borjasalguero] from comment #2) > Gregor, in SMS App in Gaia we are using 'contains' for the filter to > Contacts API, that's why we are getting this weird behaviour. Should we move > to 'equal'? Or this is the result expected? Thanks! Well, if we change contains to equals, we wouldn't mach 4501234567 with +14501234567 any more. Maybe this gets resolved with bug 833291. We will always be able to find corner cases where our matching heuristics doesn't work because unfortunately there is no real solution to this problem :(
Flags: needinfo?(anygregor)
(In reply to Lukas Blakk [:lsblakk] from comment #1) > I'm thinking this doesn't mean that anyone with a shared area code would all > show up in the header. Can we get some QA around this to determine if it > only shows up when you use a subset of a number (and thus, not likely > 'real' number) like 616 or if this can happen with numbers of the same > length? The point is that short numbers could be real ones, like emergency number (112), voice mail number (123), company phone numbers.
Keywords: qawanted
I can't reproduce it anymore. Could you please re-test?
Flags: needinfo?(carlos.martinez)
I´ve tried this in unagi with Gecko-a378fd4.Gaia-79f122d from V1.0.1 and is doing the exact same thing described when we opened the bug.
Flags: needinfo?(carlos.martinez)
Sorry, I meant is not happening anymore in master. Uplifting Bug 856991 will fix it.
Is this still reproducible?
Keywords: qawanted
Tested in Unagi Device Gecko-ada3b96.Gaia-c51082d STR: 1-Open contacts app 2-Create a contact with a phone number (e.g. 616454545) 3-Create another contact with a phone number (e.g. 616) 4-Open contact details for the second contact 5-Send a SMS from this screen Expected result --> The name of the second contact is shown in SMS app Actual result --> As the expected result indicates. Only the name of the second contact appears in the Messages Screen list
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: