54051 - For multipart/mixed mails, the charset of last attachment overrides the charset of the mail.

Status: VERIFIED FIXED

(MailNews Core :: Internationalization, defect, P2)

Description

[ji]

***Observed with linux and win32 2000092509 build *****

The charset of the original mail is not reflected in the reply or forward window.

Steps to reproduce:
1. Launch browser.
2. Send page of  http://home.netscape.com/ja to your mail account, or compose a Japanese mail with local Japanese ShiftJis 
file  and send it to your account.
3. Go to the mail sent at Step 2, click on Reply or select Message | Forward as | Inline
    On the Reply or Forward compose window, select View | Character Coding, you'll see no charset has check mark on the left.
After receiving the reply or forwarded mail, open the View | Message source window of the reply or forwarded mail, you'l l see 
the charset the reply/forward used is ShiftJis which is the charset of the attachment.

Comment 1

[ji]

I talked to Naoki, This is a problem limited to  multipart/mixed mails. For this kind of mails, the charset of last attachment will 
override the charset of the mail. Changed the summary accordingly.

Comment 2

[msanz]

Is this a regression?

Comment 3

[nhottanscp]

Yes, this is a regression. Looks like this is a side effect of bug 46881 fix.
46881 - Can't recognize charset info in multipart/alternative mail --> corrupt 
reply mail
If I back out the fix for this (mimemult.cpp rev 1.16), this bug is gone.
Adding mscott and rhp to cc.

Comment 4

[nhottanscp]

Here is a diff to fix the problem. Basically, restore one condition which was 
removed by the change for multipart/alternative. With the patch, we pick up 
correct charset for both multipart/alternative and multipart/mixed.

Index: mimemult.cpp
===================================================================
RCS file: /cvsroot/mozilla/mailnews/mime/src/mimemult.cpp,v
retrieving revision 1.18
diff -c -r1.18 mimemult.cpp
*** mimemult.cpp	2000/09/13 09:06:37	1.18
--- mimemult.cpp	2000/09/25 22:21:53
***************
*** 210,215 ****
--- 210,221 ----
          PRBool isBody = MimeObjectChildIsMessageBody(obj, 
&isAlternativeOrRelated);
          if ( (isAlternativeOrRelated || isBody) && obj->options)
          {
+           MimeContainer *container = (MimeContainer*) obj; 
+           // If we have only one child and this is the message body object,     
+           // this we should check for a special charset and notify the emitter  
+           // if one exists!                                                     
+           if ( (isAlternativeOrRelated) || ((container->children) && 
(container->nchildren == 1)) )
+           {
             char *ct = MimeHeaders_get(mult->hdrs, HEADER_CONTENT_TYPE, 
PR_FALSE, PR_FALSE);
             if (ct)
             {
***************
*** 230,235 ****
--- 236,242 ----
                PR_FREEIF(ct);
                PR_FREEIF(cset);
              }
+           }
            }
          }
        break;

Comment 5

[nhottanscp]

Put nsbeta3 and P3 -> P2, a message may not be seen correctly by sending with an 
incorrect charset label. Especially bad for Japan where main body charset and 
HTML attachment charset are usually different.

Comment 6

[nhottanscp]

nsbeta3+ per ftang

Comment 7

[Jaime Rodriguez, Jr.]

FTang - If we are going to want to check this in this week, I believe we need to 
go before PDT to get an nsbetta3++.

Comment 8

[msanz]

adding regression keyword

Comment 9

[nhottanscp]

I got an approval from mscott for the patch.

Comment 10

[Phil Peterson]

Not holding PR3 for this, so marking nsbeta3-. If this is serious enough to fix 
for RTM, please nominate.

Comment 11

[Jaime Rodriguez, Jr.]

Nominating for RTM+. Adding RTM keyword.

Comment 12

[nhottanscp]

So for this bug, I got r=sr=mscott.

Comment 13

[Frank Tang]

got review. got superreview. The patch is in this bug. please consider rtm++

Comment 14

[Jim Roskind]

Bumping up to rtm double plus.  Please land on branch asap.

Comment 15

[nhottanscp]

Checked in the patch to both brach and trunk.

Comment 16

[ji]

Verified with 2000100909 win32, linux, mac branch build. It is fixed.

Comment 17

[Asa Dotzler [:asa]]

Reopening to Resolve as Fixed.  Bugs stay resolved until verified on both the
branch and the trunk.

Comment 18

[Asa Dotzler [:asa]]

Resolving as Fixed.  vtrunk keyword is in place requesting trunk verification
before this bug changes state to Verified.  When this is verified on the trunk
vtrunk keyword should be removed and the bug Status should be set to Verified.
Sorry for the spam, just trying to make sure we cover all of our bases here.

Comment 19

[Katsuhiko Momoi]

** Checked with 11/4/2000 MN Windows build **

The problem is fixed on the branch build above. Reply or Forward/inline
does not corrupt the body text when the attachment has different
charset than the main body charset. The menu checkmark is correct also.
Forward as attachment also correctly reflects the charset
of the main body.

ji, please check the Linux case.
I will check Mac. 

Comment 20

[Katsuhiko Momoi]

Sorry, this is to be verified on the trunk.
The branch verification is already done by ji.

Comment 21

[ji]

Verified with linux, win32 and mac 2000-12-19-06-Mtrunk build.