129113 - Mailing list is expanded incorrectly through the address picker

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Address Book & Contacts, defect, P1)

Description

[marina]

*** observed with 2002-03-01 build *** (actually the intl problem that is
related to this bug started with 02-20 build)
In the current builds when the address picker is used or you compose a mail from
the address book by selecting a mailing list and clicking compose the mailing
list gets expanded against its name instead of description. It does the right
thing (expanding against description) when mail is composed by entering the list
name into the recipient field.
Steps to reproduce:
- have a list name "alist" with the descriptin as "description";
- open PAB, select the mailing list, click "compose";
//now note that the list expands to "alist" instead of expected "description"
//you'll see the correct result if you just type into the mail compose "alist"

Comment 1

[marina]

as i said earlier the regression possibly started between 02-19 and 02-20 builds

Comment 2

[Ninoschka Baca]

Trunk build 2002-03-06: WinMe

I can duplicate the problem in 2 ways. My mailing list has a List Name and a
Description. 

I. From Adress Book window
1. Select the list in the results pane
2. Select the Compose button

Actual Results: 
a. It displays "alist<alist>"

b. b. Try to send to "alist<alist>" and it appears to work but then I receive a
message titled "Mail System Error - Returned Mail" and it states

"Recipient: <[e-mail]>
Reason:    5.1.1 <[e-mail]>... User unknown"

Expected Results: It should display "alist<description>"

II. From the 3pane
1. Select Compose button
2. Select Address button so the Select Address dialog appears
3. Select the list in the results pane, select 'To' button so it moves the
address to the bottom of the dialog.

Actual Results: 
a. Notice that it displays "alist<alist>". Then select OK to close the Select
Address dialog and the Compose address area still shows "alist<alist>".

b. Try to send to "alist<alist>" and it appears to work but then I receive a
message titled "Mail System Error - Returned Mail" and it states

"Recipient: <[e-mail]>
Reason:    5.1.1 <[e-mail]>... User unknown"

Marking nsbeta1 because the "description" seems to cause the sending of a list
to fail.

Comment 3

[Michael Buckland]

Discussed in Mail News bug mtg w Engineering Mktng PjM.  Decided to plus the
bug.  Making P1 also.

Comment 4

[Ninoschka Baca]

*** Bug 120668 has been marked as a duplicate of this bug. ***

Comment 5

[Tom Mraz]

This bug isn't too recent regression as I'm seeing this in Mozilla0.9.8 too. But
it's serious ui problem.
Raising severity to major.

Comment 6

[varada]

Attachment: Patch V1

If the card is a mailing list then we check for description and tag it as the
name  mailinglist<description>
Else not we go with the mailing list display name mailinglist<mailinglist>

Comment 7

[Rajiv Dayal]

Please put GetDirectoryFromURI(card.mailListURI); call in a try catch block.

Besides that r=rdayal.

Comment 8

[(not reading, please use [e-mail] instead)]

a try / catch is not necessary.

but "mailinglist <description>" looks wrong to me.

I'd think it would be:

"description <mailinglist>"

similar to how it is for emails:

"Seth Spitzer <[e-mail]>"

I'm thinking something like this:
   
   var email;
   var displayName;

   if (card.isMailList) {
     // for mailings lists, the "email" is the display name.
     email = card.displayName;

     var directory = GetDirectoryFromURI(card.mailListURI);
     // for display name, use description, then nickName, and 
     // if all else fails, use displayName, which is always defined.
     if (directory.description)
       displayName = directory.description;
     else if (directory.nickName)  // varada, double check that is correct
       displayName = card.nickName;
     else
       displayName = card.displayName;
   }
   else {
     email = card.primaryEmail;
     displayName = card.displayName;
   }
   return gHeaderParser.makeFullAddressWString(displayName, email);
 }

Comment 9

[(not reading, please use [e-mail] instead)]

varada is checking if I'm right about the mix up, and if we might have messed 
this up elsewhere in the code.

giving the bug to varada, as he's hacking / investigating.

Comment 10

[varada]

The actual format is MailingList_Name<MailingList_Desc>. In the absence of a
Description attribute it is ML_Name<ML_Name>. The nickname merely serves as a
shorter autocomplete mechanism and shouldnt be involved in the header. Fixing
this portion of the code fixes launching mailcompose from addressbook as well as
select Address from mailcompose window and DnD lists from AB to MailCompose. 
If the try catch is not necessary then I am sticking with the first patch which
addresses all the above issues.

Comment 11

[(not reading, please use [e-mail] instead)]

Comment on attachment 76176 [details] [diff] [review]
Patch V1 

ok, from nbaca's comments in the bug, and from what varada tells me over AIM,
this is the right fix for now.

I think we've actually reversed the two fields, and varada is going to log a
bug to discuss that.

but as long as we are consistent, this will make it so sending mail will work,
which is important to get right first.

carrying over r=rdayal,
adding sr=sspitzer

try / catch is not necessary.

Comment 12

[varada]

133616 is the bug that is going to deal with the other problem of 
MailingList_Description<MailingList_Name> should be the format while composing mail.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 76176 [details] [diff] [review]
Patch V1 

a=dbaron for trunk checkin

Comment 14

[varada]

Marking Fixed.

Comment 15

[Ninoschka Baca]

Trunk build 2002-03-27: WinMe
Trunk build 2002-03-28: Linux RH 7.1, Mac 10.1.3
Verified Fixed.

Comment 16

[Michael Buckland]

Discussed in Mail News bug meeting.  Decided to ADT1 this bug.

Comment 17

[Ninoschka Baca]

*** Bug 118125 has been marked as a duplicate of this bug. ***

Comment 18

[Ninoschka Baca]

Branch build 2002-07-23: WinMe, Linux RH 7.1, Mac 10.1.3 - Fixed.