156588 - Support for multiple addresses in from header is inconsistent

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Brian Zuzga]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530
BuildID:    2002053012

RFC 822 and 2822 specify that the "From:" header can consist of a comma
separated list of addresses.  In the case that there are multiple "From"
addresses, the information displayed is somewhat inconsistent.

In the summary list of message headers, the first address in the list is
displayed.  In the message preview pane and the subsequent full message view,
the last address in the list is displayed.  Neither displays the full list. 
Even if display of the full list of from address is not practicable, it would be
better to see more consistent behavior between the two panes.  This seems to
indicate two separate code paths to produce the same displayed result.

When I do a "reply" or "reply all", the behavior is 100% correct and includes
all the addresses listed on the from line.  This indicates to me that the
underlying data abstractions are sound and that the front end code just needs
some tweaking.


Reproducible: Always
Steps to Reproduce:
1. Generate a fully RFC 822/2822 compliant email message to yourself that has a
comma separated list of multiple "From" addresses on one line.
2. View that message via IMAP.  (I just happened to use IMAP, but it may just as
well happen via other transports.)
3. You'll see that the summary headers display the first address in the list. 
The message preview and full view display the last address.  Neither displays
the full list.  Viewing the source of the message works fine.

Actual Results:  You'll see that the summary headers display the first address
in the list.  The message preview and full view display the last address. 
Neither displays the full list.  Viewing the source of the message works fine.

Expected Results:  I would expect to see the comma separated list of all the
addresses on the From line.  If that would involve significant refactoring of
the code, it would suffice to see consistent behavior between the summary and
preview panes.

Comment 1

[Mike Cowperthwaite]

Brian Zuzga: Is this still an issue with current builds?  If so, could you 
attach a sample mail message exhibiting the problem?

Comment 2

[Brian Zuzga]

Attachment: Mail message in unix mbox format that recreates problem

Here's a mail message copied out of my IMAP server that recreates the problem. 
It is in unix mbox format, but let me know if you need it some other way.

I replicated the problem as described on 1.3 and 1.4a.	I'm downloading 1.4b
currently.  Let me know if there is a particular build that you want me to try.

Comment 3

[Brian Zuzga]

Still repro in 1.4b.
I've also verified the bug on Mac OS 10.2.6 and FreeBSD 4.8.

Comment 4

[Mike Cowperthwaite]

Yep, I see it too; and I couldn't find any dupes.  Confirming.

Comment 5

[Mike Cowperthwaite]

Whoops, found a dupe.

*** This bug has been marked as a duplicate of 110605 ***

Comment 6

[Mike Cowperthwaite]

I'm reversing myself; this isn't a dupe, that other bug is about mis-displaying 
RFCx822 "To:" lines, not "from:" lines.  Related, tho.

Comment 7

[Mike Cowperthwaite]

Incidentally, see bug 115240 for a similar inconsistency on a very dissimilar 
'From:' address.

Comment 8

[Mike Cowperthwaite]

Another related item: bug 172104

Comment 9

[Mike Cowperthwaite]

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

Comment 10

[Mike Cowperthwaite]

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

Comment 11

[Mike Cowperthwaite]

This is WFM with SeaMonkey/1.5a-20060220 (trunk) -- that is, the entire list is displayed in the envelope panel, altho (by necessity) only one address is shown in the Thread pane.  The fix was implemented as part of bug 308988.

See also bug 106189 where a patch has just been checked in for the same handling with Reply-To.

Comment 12

[Mike Cowperthwaite]

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