"Lastname, Firstname" <a@b.c> in CC is split on comma when using reply-all

VERIFIED FIXED in M16

Status

P3
major
VERIFIED FIXED
19 years ago
10 years ago

People

(Reporter: sstock, Assigned: bugzilla)

Tracking

({regression})

Trunk
x86
Linux
regression

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2+] Fix in hand)

(Reporter)

Description

19 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.12-20 i686; en-US; m14)
BuildID:    2000040315

When I click reply-all on a message with a CC in the format
"Lastname, Firstname" <someone@somewhere.com> the new compose window has a bad
CC list.

Example header:
From: "Stock, Steve (from)" <steve@technolope.org>
To: "Stock, Steve (to)" <sstock@iconnect-inc.com>
CC: "Lastname, Firstname" <someoneelse@iconnect-inc.com>
Subject: test message

When I click reply-all on the message with these headers the compose window has
the following addresses:
To: "Stock, Steve (from)" <steve@technolope.org>
Cc: Stock
Cc: Lastname
Cc: Firstname <someoneelse@iconnect-inc.com>

The from address appears to be parsed correctly for the To field, but the CC
list is wrong.  Other (real life :-) emails are also showing this behavior.



Reproducible: Always
Steps to Reproduce:
1. have someone send you an email that has a comma seperated name in quotes in
the CC field (or find one)
2. Using Mozilla select the message in your inbox (or whereever)
3. click the "Reply All" button

Actual Results:  The new compose window's Cc: lines are bad, they have split the
Cc address on the comma inside the quotation marks.

Expected Results:  For my above example I expected the compose window to have an
address list containing only two recipients:

To: "Stock, Steve (from)" <steve@technolope.org>
Cc: "Lastname, Firstname" <someoneelse@iconnect-inc.com>


I would like to note that all addresses appear correct when viewing the message,
they are only mangled in the compose window.

Updated

19 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: lchiang → esther
(Assignee)

Comment 1

19 years ago
use to work! rhp, any idea?
Status: NEW → ASSIGNED
Target Milestone: --- → M16

Comment 2

19 years ago
Sorry, no clue?

- rhp
(Reporter)

Comment 3

19 years ago
The windows build 2000040415 has the same behavior with my sample message.

Comment 4

19 years ago
*** Bug 35454 has been marked as a duplicate of this bug. ***

Updated

19 years ago
Severity: normal → major
Keywords: beta2, regression

Updated

19 years ago
Keywords: nsbeta2

Comment 5

19 years ago
Putting on [nsbeta2+] radar.  
Keywords: beta2
Whiteboard: [nsbeta2+]
(Assignee)

Comment 6

19 years ago
Here is the fix (BTW, it wasn't a message compose bug but a MsgDB one):

Index: nsMsgHdr.cpp
===================================================================
RCS file: /cvsroot/mozilla/mailnews/db/msgdb/src/nsMsgHdr.cpp,v
retrieving revision 1.79
diff -r1.79 nsMsgHdr.cpp
401c401
< NS_IMETHODIMP nsMsgHdr::SetRecipientsArray(const char *names, const char *addresses, PRUint32 
numAddresses)
---
> nsresult nsMsgHdr::BuildRecipientsFromArray(const char *names, const char *addresses, PRUint32 numAddresses, nsCAutoString& allRecipients)
406c406
< 	nsCAutoString	allRecipients;
---
> 	nsIMsgHeaderParser *headerParser = m_mdb->GetHeaderParser();
408c408
< 	for (PRUint32 i = 0; i < numAddresses; i++)
---
> 	for (PRUint32 i = 0; i < numAddresses; i++, curName += strlen(curName) + 1, curAddress += strlen(curAddress) + 1)
412a413,425
> 		if (headerParser)
> 		{
> 		   char * fullAddress;
> 		   ret = headerParser->MakeFullAddress(nsnull, curName, curAddress, &fullAddress);
> 		   if (NS_SUCCEEDED(ret) && fullAddress)
> 		   {
> 		      allRecipients += fullAddress;
> 		      nsCRT::free(fullAddress);
> 		      continue;
> 		   }
> 		}
> 
>         // Just in case the parser failed...
425,426d437
< 		curName += strlen(curName) + 1;
< 		curAddress += strlen(curAddress) + 1;
427a439,451
> 	
> 	return ret;
> }
> 
> NS_IMETHODIMP nsMsgHdr::SetRecipientsArray(const char *names, const char *addresses, PRUint32 numAddresses)
> {
> 	nsresult ret;
> 	nsCAutoString	allRecipients;
> 	
>     ret = BuildRecipientsFromArray(names, addresses, numAddresses, allRecipients);
>     if (NS_FAILED(ret))
>         return ret;
> 
442,443d465
< 	const char *curName = names;
< 	const char *curAddress = addresses;
444a467,470
> 	
>     ret = BuildRecipientsFromArray(names, addresses, numAddresses, allRecipients);
>     if (NS_FAILED(ret))
>         return ret;
446,468d471
< 	for (PRUint32 i = 0; i < numAddresses; i++)
< 	{
< 		if (i > 0)
< 			allRecipients += ", ";
< 
< 		if (strlen(curName))
< 		{
< 			allRecipients += curName;
< 			allRecipients += ' ';
< 		}
< 
< 		if (strlen(curAddress))
< 		{
< 			if (strlen(curName))
< 				allRecipients += '<';
< 			else
< 				allRecipients += "<";
< 			allRecipients += curAddress;
< 			allRecipients += '>';
< 		}
< 		curName += strlen(curName) + 1;
< 		curAddress += strlen(curAddress) + 1;
< 	}

Index: nsMsgHdr.h
===================================================================
RCS file: /cvsroot/mozilla/mailnews/db/msgdb/public/nsMsgHdr.h,v
retrieving revision 1.44
diff -r1.44 nsMsgHdr.h
57a58
>     nsresult    BuildRecipientsFromArray(const char *names, const char *addresses, PRUint32 numAddresses, 
nsCAutoString& allRecipients);
Whiteboard: [nsbeta2+] → [nsbeta2+] Fix in hand
(Assignee)

Comment 7

19 years ago
Fixed and checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 8

19 years ago
Using build 2000-05-10 on win98, mac and linux the LN,FN is not split up in the 
addressing pane for To: or Bcc: this bug as stated is verified.  However, the 
name still appears as split in the Addressing bucket of the "Select Addresses" 
window.  Note: while addding names to the bucket they display OK, it displays 
this way only after you close and open the "Select Addresses" window again to 
add more names.  I'll log a new bug for this behavior (bug 38937)  Verified
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.