Closed
Bug 796630
Opened 13 years ago
Closed 13 years ago
[sms] wrong data extracted from the contact that is picked from contacts app
Categories
(Firefox OS Graveyard :: Gaia, defect, P2)
Firefox OS Graveyard
Gaia
Tracking
(blocking-basecamp:+)
VERIFIED
FIXED
| blocking-basecamp | + |
People
(Reporter: ghtobz, Assigned: fcampo)
References
Details
(Whiteboard: [label:sms][LOE:S])
Attachments
(1 file)
|
23.90 KB,
image/png
|
Details |
[GitHub issue by chrisvargauk on 2012-09-12T08:41:06Z, https://github.com/mozilla-b2g/gaia/issues/4617]
Issue: If there are multiple contacts in the Contacts app, when user tries to pick one for the SMS app, sometimes some data (any of: phone type, carrier) of the picked contact is missing.
Reproduce:
* Open SMS app
* Compose a new sms
* Tap on pick contact icon - Contacts app opens through activity
* Tap on one of the contacts - Make sure that you have more than one contacts, ideally at least 50. You can generate the contact list through UI Tests app.
* Contacts app activity is closed and SMS app is on the screen with the composed app.
Expected result: Phone type and carrier shows up in the header.
Actual result: Sometimes phone type is null and/or instead of the carrier the phone number shows up
[GitHub comment by albertopq on 2012-09-12T08:51:30Z]
@borjasalguero @fcampo ping?
[GitHub comment by fcampo on 2012-09-12T09:09:23Z]
If instead of carrier you see the word 'null', we may have a problem, cause that should have been fixed days ago :D
If you just don't see the carrier (just the phone type), or phone number instead of carrier, could be because of the rules explained in sms wireframes.
Can you add screenshots, or explain more thoroughly the steps? I mean, the contact that doesn't show the info required, which info have stored? Is there more phones from same contact? Is there more contacts with same phone number? Does the contact have a name?
[GitHub comment by albertopq on 2012-09-12T09:42:07Z]
Steps to reproduce:
(first, import about 50 contacts from UI tests)
1.- Go to contacts
2.- Create a contact with 2 phones: Name -> A, phone1-> 1, carrier1 -> C1, phone2 -> 2, carrier2 -> C2
3.- Go to SMS
4.- New SMS
5.- Pick Contact
6.- Select contact 'A'
7.- Select phone 1 C1 in the list
Expected
'A' is shown in the header
Actual
A name from another contact is shown.
Notes: If you select the second one, the behavior is the same (with a different contact selected). Any of the 2 contacts have the phone number '1' or '2'.
[GitHub comment by borjasalguero on 2012-09-12T09:51:37Z]
For me it's working properly. I've created 'Borja' with:
- 123909 Orange
- 090909 Movistar
Picking a contact from SMS App and choosing second one (or fist one), carrier info is updated in sub-header as expected. Try to rebase because we have been modifying this code yesterday and the PR has been approved one hour ago.
[GitHub comment by fcampo on 2012-09-12T09:59:08Z]
Using alberto's steps I've just been able to reproduce the error. Taking a look on it
[GitHub comment by fcampo on 2012-09-14T12:18:15Z]
Ok, the problem here is that when we choose a contact with live search, we return the number, so if we have different contacts with same number and we pick any of those 3, the contact shown in header will be the first one of the list returned when querying for the contact data.
We don't have use cases for this kind of situations (more than one contact with the same number), so I think we should ping someone from UX, cause it affects other parts of Gaia (e.g. if number 666 calls you and you have 2 contacts with that number, which one should u show on screen?)
@aymanmaat, @jcarpenter , who should we talk with about this?
[GitHub comment by jcarpenter on 2012-09-14T19:15:41Z]
> more than one contact with the same number...
Good question! I see two possible solutions for v1:
1. Show both contact names. eg: Under incoming call, show: "[CcontactA] and [ConctactB]"
2. Show only the more recently-created contact.
#1 would be better. #2 would probably be easier, from dev and UX standpoints.
@aymanmaat What do you think?
[GitHub comment by fcampo on 2012-09-18T10:20:05Z]
Well, showing both contact names implies a lot of work from UX, both wireframes and visuals (changing the current display of data) plus work from devs, and could bring new problems and questions (type and carrier, show all from both too? check if are the same? show none?).
If we take the second option, and we only show one...well, that's already done ;) Right now we take the first contact from the returned array, but I do not know in which order are they coming (probably alphabetical).
Is there any specific reason to choose the most recently-created from that list? or it is just a matter of choosing one of them? I'd have to check the data stored on contacts to see if we can actually know the date of creation and change the order.
And yes, the question is totally for skipping some work on this, if we can :D
[GitHub comment by jcarpenter on 2012-09-19T03:33:24Z]
> Is there any specific reason to choose the most recently-created from that list?
Simply because more recent = more accurate (probably, on average).
| Reporter | ||
Comment 10•13 years ago
|
||
[GitHub comment by aymanmaat on 2012-09-19T12:06:41Z]
in the event that two or more contacts in the users address book share the same phone number, upon one of those contacts phoning the user i would advise to show all contact names that have the same number.
I dont see this as being much work for UX and Visual Design because (as a quick fix) we can accomodate the longer string by reducing the font size in some cases and alter the wording in others.
Referencing wireframe pack : HTML5_Dialer_Contacts_20120810_R2S1_V6.0
pages effected for alteration of font size would be:
6, 7, 8, 9, 10, 11, 12, 13,
so if two contacts have the same number we could reduce font size and output would be "name 1 or name 2"
if more than two contacts have the same number we could reduce font size and output "name 1 or 'n' others" where name 1 is the newest entry in the contacts address book and 'n' is the number of other contacts that share the same number.
Sorry to be blunt but I would absolutely disregard josh's #2 suggestion of showing the most recently created contact. This is because doing this makes no sense to the end user. We as the designers / programmers know the reason why the screen is saying contact Y is calling when actually it is contact X on the other end of the line when the user answers ...But the user has absolutely no idea and it would force unnecessary workload on the end users to investigate and find out... and i feel devalue their perception of our product.
| Reporter | ||
Comment 11•13 years ago
|
||
[GitHub comment by gtorodelvalle on 2012-09-20T14:44:50Z]
Since this issue also applies to the dialer, let me add that regarding the Dialer the code to addapt the name of the contact to the available space is ready. For example, in the call log it would end up as:
aymanmaat or fcampo or gtorodelvalle or jcarp...
In case of multiple calls of the same type on the same day:
aymanmaat or fcampo or gtorodelvalle or jc... (2)
The ellipsis is included automatically.
This will also work in the call screen (incoming and outgoing calls) but to check that you have to get the latest Gaia code + https://github.com/mozilla-b2g/gaia/pull/4979 I am sorry but taking screenshots from the phone is not working for me.
Is @aymanmaat suggestion the way to go? Just to start implementing it in the dialer ;)
| Reporter | ||
Comment 12•13 years ago
|
||
[GitHub comment by timdream on 2012-09-20T15:02:37Z]
Just to make sure, you didn't see a white strip on the top of the contact picker when you picking contacts fight? Coz if that happens, the UI and the hit areas is actually misplaced and you might be not be pressing the contact you think you did.
This is a CSS issue that is being workarounded currently https://bugzilla.mozilla.org/show_bug.cgi?id=792351
| Reporter | ||
Comment 13•13 years ago
|
||
[GitHub comment by gtorodelvalle on 2012-09-20T15:10:39Z]
In fact, this is how it would end up being in the call log: https://www.dropbox.com/s/zxkjuvqzeqnh79w/Photo%2020-09-12%2017%2000%2047.jpg and the call screen: https://www.dropbox.com/s/9jwrsf3lwzho7x4/Photo%2020-09-12%2017%2001%2021.jpg
The point is that with longer names such as mine we could end up with things such as: "Germán Toro del Valle or...", "Germán Toro del Valle o...", or even "A very long long long name..." (where the user would have no clue that there are several numbers assigned to that concrete number), etc.
Let me tell you that this is not currently implemented in the Dialer. This was just me setting specific names to contacts and calling them just to try to help here with several images ;-)
| Reporter | ||
Comment 14•13 years ago
|
||
[GitHub comment by borjasalguero on 2012-09-30T22:11:36Z]
@fcampo This issue is working properly right?
| Reporter | ||
Comment 15•13 years ago
|
||
[GitHub comment by fcampo on 2012-09-30T22:45:32Z]
No, still waiting for a formal decision from UX to show something when two
contacts share same number.
Right now we only show the first contact (alphabetical order) details.
Comment 16•13 years ago
|
||
hey guys. sorry i thought i gave direction on how to resolve this in my comment on this thread @ 2012-10-01 22:37:50 PDT...however further to German's comment:
For instances where two names share the same number and either one or both is exceptionally long, in order to deliver the required information to the end user we could either:
(1) Truncate each name after 'n' number of characters. so:
"Germán Toro del Valle or Ayman Kommen aus Berlin Maat"
becomes
"Germán Toro... or Ayman Komme..."
(2) just truncate the 1st name and give an indication that the incoming number is shared by other contacts. so:
"Germán Toro del Valle or Ayman Kommen aus Berlin Maat"
becomes
"Germán Toro... or 1 other"
Personally I prefer solution (2) because a) it is more controllable and b) is scaleable for when there are more than two contacts that share the same number.
What do you guys think? Let me know if you need more input
| Assignee | ||
Comment 17•13 years ago
|
||
I also prefer 2nd solution, even if we don't have a way of knowing which other contacts share the phone number.
Comment 18•13 years ago
|
||
Cool, lets go with the second solution then:
(2) just truncate the 1st name and give an indication that the incoming number is shared by other contacts. so:
"Germán Toro del Valle or Ayman Kommen aus Berlin Maat"
becomes
"Germán Toro... or 1 other"
| Assignee | ||
Comment 19•13 years ago
|
||
Fixed in https://github.com/mozilla-b2g/gaia/pull/5692
Still need to know the amount of characters to truncate the first name (UX decision?)
r?:borjasalguero for functionality
r?:kaze for changes on locales
Comment 20•13 years ago
|
||
Fix for Dialer: https://github.com/mozilla-b2g/gaia/pull/5713
r?:etiennesegonzac
r?:arcturus
Comment 21•13 years ago
|
||
Are we using review flags here for GitHub pull requests?
Comment 22•13 years ago
|
||
There is something I don't understand, so we are fixing both sms and dialer, why don't we have two different bugs?
The dialer one already got the r+ in github, anyway I'd like to have them separate, and have the patches here as well.
Cheers,
F.
Updated•13 years ago
|
Priority: -- → P2
| Assignee | ||
Comment 23•13 years ago
|
||
R+ by :borjasalguero and :stasm on github, and merged, marking as fixed
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment 24•13 years ago
|
||
Comment 25•13 years ago
|
||
Reopening bug, issue with null showing for carrier repros for device Ungia; build #20130102070202 v.1
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 26•13 years ago
|
||
(In reply to Misty Byrd from comment #25)
> Reopening bug, issue with null showing for carrier repros for device Ungia;
> build #20130102070202 v.1
This issue has been close since more than one month so what you see is likely a different issue. Can you open a new bug with new steps to reproduce? Also can you indicate if you have created the contacts from the SIM card, from Facebook or manually? Is the contact and old created contact or one recently created?
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Flags: needinfo?(mbyrd)
Resolution: --- → FIXED
Comment 27•13 years ago
|
||
Refer to new bug opened per response from comment #26 https://bugzilla.mozilla.org/show_bug.cgi?id=826465
Status: RESOLVED → VERIFIED
Flags: needinfo?(mbyrd)
You need to log in
before you can comment on or make changes to this bug.
Description
•