In case that the header of received message contains 8 bit characters and it is not mime encoded, mozilla can display the header correctly. However, replying to the message, the subject field and receipient field in the new message can not be displayed correctly. These fields can't handle so called 8 bit through header. NS 4.x and IE5.x can do t

This is probably a duplicate of Bug 41009.

If reproducible, this should be a dup of bug 39736. IQA please test and reopen bug 39736 and mark this as a dup.

Reopened bug 39736. Marked this one as a dup of 39736. *** This bug has been marked as a duplicate of 39736 ***

As I mentioned in the other bug. This is not a duplicate of Bug 39736 which is about body quoting. This bug is about header quoting. See my comments in Bug 41009 at: Additional Comments From Katsuhiko Momoi 2000-08-10 17:26 If this is not strictly a duplicate of Bug 41009, then this bug should be kept open.

Hi Naoki, the problem described in bug 41009 is about the failure of "Edit as New" funtion for msgs w/o MIME headers. And this one is about reply/forward. Are they calling the same module? If they do, we have three bugs: this one, 41009, 39736, to point to the same problem, although we need to modify the summary of bug 41009 to better reflect the problem.

I am not sure if they use the same code. Looks like this bug is about headers not body so let's reopen this and keep as separate.

just one thing: in nsMsgCompose.cpp, line 966, can you remove the comment that say that encodedCharset is not used. Appart that, R=ducarroz

Okay, I will change it before check in.

sr=bienvenu

checked in

I checked on Build 20010219. The recipient field seems to have been fixed, but cc: field still has the problem, when choosing "reply all".

Tomoo, could you attach a testcase to the report? thanks.

Confirmed the problem. Reopened the bug.

Reopen, I only fixed for subject header.

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

Need forward as attachment change, should wait for the MIME decoder change bug 65277.

adding nsbeta1 keyword, and jenm to cc: list.

R=ducarroz

yuck - well, sr=bienvenu

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

checked in for forward attachment. Future the remaining problems, non subject header support Non MIME headers.

This problem in subject and sender field seemed to be fixed once at the beginning of May, but it has reappeared while reply, forward and attachment field's problems have been fixed. I checked on Build 20010525 20010527 20010531 20010604 and 2001060908.

Nominating for nsbeta1, this problem still exists on 01/17 build. Forward-inline for non-MIME encoded mail headers doesn't inherit the specified folder charset. But it can inherit the charset that the user specified from charset menu. Reply doesn't have this problem for headers. Modified the summary accordingly.

Please note that forward inline once got fixed in 6.2, but now it's broken. Steps to reproduce: 1. Select a non-MIME encoded iso-2022-jp mail. 2. Set the proper folder charset to correct the view. 3. Click on Forward button, observe the corruption in subject. 4. Select the iso-2022-jp charset from charset menu, click on Forward button, you can see in this case forward inline can take the right charset specified from menu.

I think this is similar to bug 115869. I think this is related to my fix for file name support (supporting filename charset different from the mail body's charset).

nsbeta1+ per i18n triage

This problem is different from the reply/quote (bug 118740). For forward inline, it always fails to get a folder charset. This used to be a non problem since we always set a override flag (so folder charset was not used).

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

> I think this is similar to bug 115869. In some sense :-) The problem in bug 115869 is reverse on this one - In this bug we don't check folder encoding, while in 115869 we check only folder encoding and not msg window override charset

This bug consitts of two parts: first, we don't use default charset when msg charset empty and there is no msg window charset override (mimedrft.cpp); Second, we always failing to get folder charset when sending draft/template/fwd inline. Looks like problems with CreateStartupUrl() Problem in using two notations to reference message number in urls: ?number=<num> and #<num>. nsMailboxUrl.ParseUrl expects msg number in form ?number=, but sometimes gets it as #. This part is will be fixed by patch for bug 110689 (despite it says it's just code cleanup)

Fix for first problem...

Thanks for finding the problem. The problem is fixed after I applied the patch in this bug and the one in bug 110689). About the patch, since the next line after your patch checks for mdd->options, you can include your change inside that if clause.

I also check charset_override now. Naoki, does it seems reasonable?

Comment on attachment 67414 [details] [diff] [review] v2 of the above patch r=nhotta

The comment, - // mscott: aren't we leaking a bunch of trings here like the charset strings and such? I think that is true, so please don't remove.

You can just use PR_Free instead of PR_FREEIF, because PR_Free will check for null, and you don't need the assigning to null behaviour of PR_FREEIF because you're assigning it in the next statement.

Naoki, what we're leaking here? members of MimeDisplayOptions which may leak are: mozITXTToHTMLConv *conv - not used in mimedrft.cpp at all nsIPref *pref - freed in mime_stream_complete char *part_to_load - freed in ~MimeDisplayOptions char *default_charset - ditto What else we may be leaking?

>What else we may be leaking? How about MimeDisplayOptions::url?

Comment on attachment 68862 [details] [diff] [review] patch v2.01; replaced PR_FREEIF with PR_Free r=nhotta

David, could you review the latest patch?

Comment on attachment 67414 [details] [diff] [review] v2 of the above patch sr=bienvenu

checked in the patch but need bug 110689 to get the folder charset

depends on bug 110689

Here is rest of needed changes to fix this. (no more depend on 110689)

Comment on attachment 72391 [details] [diff] [review] folder charset part r=nhotta This is for forward inline. By the change, PrepareMessageUrl is called and that makes a folder charset to be retrieved correctly later, and the reply quote code also uses GetUrlForUri instead of CreateStartupUrl. I cc to ducarroz in case he wants to review it.

Comment on attachment 72391 [details] [diff] [review] folder charset part sr=sspitzer please test forwarding for imap, news and local.

Naoki, does this patch take care of CC and BCC fields? If not, I'd like to open a seperate bug.

You mean 'cc' in the quoted text in the body for forward inline?

yes, the cc part in the quoted text in the body for forward inline How about Edit as new and edit draft? Does this patch take case of those cases too?

Comment on attachment 72815 [details] [diff] [review] Updated for the recent URI change (SetSpec argument type change). r=nhotta

With the patch, the last two test cases quoted fine if I set the folder charset to Shift_JIS. Not all the headers are quoted (e.g. bcc is not quoted), I think that is by design.

Per discussion with Naoki, filed bug 129349 for the display problem with the non-MIME encoded Reply-To and Bcc header when editing message as new.

Comment on attachment 72815 [details] [diff] [review] Updated for the recent URI change (SetSpec argument type change). sr=sspitzer

Comment on attachment 72815 [details] [diff] [review] Updated for the recent URI change (SetSpec argument type change). a=asa (on behalf of drivers) for checkin to the 1.0 trunk

There seems to be at least one more issue (cf bug 129256 & bug 129349) not yet under consideration: BCC header isn't MIME-encoded by Mozilla (as shown when we save a message and "Edit Draft" again). Maybe another bug has to be filed?

Oh, by the way, is there a bug already filed about Mozilla crashed by forwarded mails? I don't know how to reproduce the exact situation. I think I'd better make a test case for that if you think a new bug is needed. nhotta: why is BCC unquoted by design?

Reply-To and BCC problems is bug #64092 (mozilla1.2, nsbeta-, patch, review).

>nhotta: why is BCC unquoted by design? I was wrong, you can change it to show all headers by View->Headers.

checked in to the trunk Thanks for the contribution.

Verified as fixed with 03/20 builds.

This problem has occured again since 2002032203 to 2002033109. The problem occures when the mail has the header of Content-Type: text/plain; charaset="iso-2022-jp" . When forwarding to this mail, Japanese characters can't display correctly. In case of reply, there is no problem. Tomoo

Tomoo, I don't see this on 03/28 build. Did you see the corruption in subject or body?

I saw the corruption in body.

unzip, move to mail folder, launch Mozilla, choose check3 folder, choose message and forward.

Tomoo, the mail you just attached is an ISO-2022-JP mail with MIME header, and it's also a reply mail with original one having no MIME header and it has added some lines above the quoted mail. It has two problems when doing forward on this mail: 1. The added lines is garbled 2. The quoted part in the mail is dropped when forwarding. I think this is a different one with this bug since the mail you try to forward has MIME header. Could you file a seperate bug on this or do you want me to do it? Please let me know. Thanks.

#134762 is a new entry. Please follow it up. Tomoo

Attached test case, http://bugzilla.mozilla.org/attachment.cgi?id=25725&action=view "To:" has problem when forward as inline. Other test cases do not have that problem. I guess it is releated to the non-MIME encoded multiple line header. Xianglan, could you try that using NS 7 and file as a separate bug?

Filed bug 180025 for above problem.