Forward inline: non-MIME encoded multiple line header of the original mail is not displayed correctly

NEW
Unassigned

Status

MailNews Core
Internationalization
--
minor
16 years ago
5 years ago

People

(Reporter: ji, Unassigned)

Tracking

Trunk
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: intl)

(Reporter)

Description

16 years ago
This bug is seperated from bug 66098.
When doing forward inline, the non-MIME encoded multiple line header of the
original mail is not displayed correctly.

Steps to reproduce:
1.Unzip the following zip file containing a testing mail
http://bugzilla.mozilla.org/attachment.cgi?id=25725&action=view
2. Put the testing mail in your local folder.
3. Restart mail, select the folder containing the testing mail, change the
folder charset to Japanese (ISO-2022-JP) to correct the view
4. After the view is corrected, click on Forward icon, observe the To: field of
the original mail, they are displayed as question marks.
(Reporter)

Updated

16 years ago
Summary: Forward inline: non-MIME encoded multiple line header of the original mail is not displayed correctly → Forward inline: non-MIME encoded multiple line header of the original mail is not displayed correctly

Comment 1

16 years ago
reassign to nhotta
Assignee: smontagu → nhotta
Product: MailNews → Core

Comment 2

13 years ago
This bug WFM with TB 1.6a1-1117.  Reporter (Ji) -- can you confirm?

Comment 3

13 years ago
Clarification: There is a problem with this message, but the described behavior of forwarding is WFM.  There are multiple To: headers which don't display in any context -- not in the envelope panel, not in the forward.

If I Reply All to the message while enforcing my ISO-8859-1 charset on replies, the original's From: message is copied over correctly, but the To: is not.  But if I allow the original message's charset in the reply, both fields are correct. I think this last bit is already a bug somewhere.

Comment 4

13 years ago
I need to withdraw comment 2 & 3; I thought I was testing with the same 
message, but in fact I was testing with an edited version that no longer had 
the multiple recipients.  My mistake.

I did some further testing.  The initial mail consists of a single, folded To: header with nine comma-separated addresses; the realname portion of each 
address is in ISO-2022-JP, rather than MIME-encoding.  When forwarded-inline, these bytes are copied verbatim into the new message (which always has the 
ISO-2022-JP encoding that was correctly specified in the original message 
body).  In the compose window, these names appear as they would looking at the message source in an ASCII text editor; this is the original bug report.  However, when the message is sent, and the sent version viewed, the bytes are properly interpreted as ISO-2022-JP and displayed as the expected Japanese characters.

I then tweaked the message, in light of a different symptom reported elsewhere (bug 318705).  The edited version had a To: header with only one address, a 
CC: header with a single address, and second a CC: header with seven comma-separated addresses.  When *this* message is forwarded-inline, the compose window displays the in-body To: header (with a single address) as expected; 
and it shows a single, eight-address CC: header with the characters appearing 
as ASCII.

I re-tweaked to have two single-address To: headers and one seven-address CC: header; in the forwarded message body, both headers appeared as ASCII.

In other words, the To: or CC: headers will appear correctly in the compose window if there is only one To: or CC: address in the message.
Severity: normal → minor
OS: Windows XP → Windows 2000
(Assignee)

Updated

10 years ago
Product: Core → MailNews Core
QA Contact: marina → i18n

Updated

5 years ago
Assignee: nhottanscp → nobody
Whiteboard: intl
You need to log in before you can comment on or make changes to this bug.