In Bug 858362 we changed how we parse the contacts returned from a search, and if we get multiple contacts for one number we add ".. and n others" at the end of the name for the first contact. Now that I used this, and I have this case in my Contacts DB, I believe this is wrong. We should show the first contact, and keep "and n others" for the multi-recipient case. Otherwise this is very misleading, because we're sending to one person, and we get "and n others". Here is a STR: * add 2 different contacts for one number * send a Sms to that number * open the thread list view, or the thread view for that number

Ayman, do you agree with this reasoning ?

If this

(In reply to Julien Wajsberg [:julienw] from comment #0) > In Bug 858362 we changed how we parse the contacts returned from a search, > and if we get multiple contacts for one number we add ".. and n others" at > the end of the name for the first contact. > > Now that I used this, and I have this case in my Contacts DB, I believe this > is wrong. We should show the first contact, and keep "and n others" for the > multi-recipient case. Otherwise this is very misleading, because we're > sending to one person, and we get "and n others". > > Here is a STR: > * add 2 different contacts for one number > * send a Sms to that number > * open the thread list view, or the thread view for that number Yes i completely agree with this as now we have group messaging it is misleading to use '… and n others' for instances where more than one contact shares the same phone number. As a reference point we have just killed showing '… and n others' in the call log for instances where two or more contacts share the same phone number . refer to bug 865079. So your proposition would align.

NI dietrich pour leo+

Steve, take care that Bug 873703 will fix how the locale is called.

Steve, I don't reproduce this with the current code, after all...

I also can't reproduce now

don't know which commit fixed it though.