92957 - Reply/forward-inline: charset is overwritten by the charset of the linked local html file

Status: VERIFIED FIXED

(MailNews Core :: Internationalization, defect, P4)

Description

[ji]

****Observed with 07/26 branch build******

When replying or forward-inline to a mail with a link in the mail body that
points to a local html file, the charset of the reply/forward mail is
overwritten by the charset of the linked file. If the mail has  more than one
linked local files, the charset of the last one will be used.

Steps to reproduce:
1. Open a mail composer window.
2. In the mail body, select Insert | Link
3. Enter a string and link it to a local shift-jis html file.
4. Send out the mail in ISO-2022-JP to yourself.
5. After received, reply or forward-inline to this mail. You can see Shift-Jis
instead of iso-2022-jp is used for the reply or forward mail.

Comment 1

[ji]

This problem doesn't exist when the link points to a web page or the mail has   
attachement files. I'll attach a testing mail later.

Comment 2

[ji]

Attachment: A testing mail containing one link to euc file and one link to sjis file.

Comment 3

[ji]

Attachment: Please ignore the 1st attachment. I attached as a html file. Use this one instead.

Comment 4

[marina]

Xianglan, is shift-jis your system encoding?

Comment 5

[ji]

Yes. I'm using a Ja windows.
But it has nothing to do with the system encoding. It just picked up the charset 
in the last linked local file. For example, on ja windows, if the mail has a 
link to a local euc html file, when reply or forward-inline, euc is used.

If the local html file doesn't have charset meta tag, this won't happen.

Comment 6

[marina]

i am just thinking if it is not a designed behavior: in case of Reply/Forward
inline the attachment ( the linked file) is a part of the body and if it has a
meta tag than the meta tag would define the charset of the body ( it won't
happen in the case you would forward  the mail as an attachment), i am not sure
how the multiple parts work though.

Comment 7

[ji]

Actually, when the charset of linked html file is applied, the quoted mail body 
is garbled since the original mail is encoded in different charset. I don't 
think it's the designed behaviour.

Comment 8

[ji]

Attachment: A screenshot of the reply window to the testing mail.

Comment 9

[marina]

so you are talking about the file name and the text supplied for the link not
the contents.

Comment 10

[ji]

It's for the contents which include the text for the link.

Comment 11

[ji]

and also the subject.

Comment 12

[marina]

well , the screen shot shows the file names only... When i want for ex. create a
file on my local system ( Win NT EN) using the composer i can not give it a name
saving it as a charset other than the system charset, say a russian file name
would be considered as ????.html In case i would attach this file or insert the
link with this file it won't be ever sent...That's why i am thinking about
dependancy on the system charset

Comment 13

[ji]

Attachment: Another testing mail with Ja subject and mail body that contains a link to a sjis file

Comment 14

[ji]

This has nothing to do with the filename. You can reproduce the problem by 
inserting a link in the mail body to a local file with ASCII filename but with 
contents encoded in a different charset with mail body.

Comment 15

[marina]

I understand now that we are talking about different issues after Xianglan
showed me the problem on her machine. 

Comment 16

[Roy Yokoyama]

Mail/news issue.  assigning to nhotta.

Comment 17

[ji]

If you correct the charset of reply/forward mail on compose window and then 
send it out, after received, the quoted mail is displayed alright. However, on 
reply/forward compose window, although you correct the charset from charset 
menu, it won't correct the display on the compose window.

Comment 18

[ji]

On above comments, I said "after received, the quoted mail is displayed 
alrigh". It's not ture for all the Japanese characters, like Japanese dash 
won't be displayed correctly after received.

Comment 19

[ji]

Considering the charset used for Japanese HTML file is usually not the same as 
mails, it's not so rare for Japanese users to come across this problem. 
Especially there is no way to correct the display on reply/forward-inline 
compose window for this type of mails, I think we need to reconsider the 
priority of this bug.

Comment 20

[nhottanscp]

I think creating a link pointing to a local file is not common, I would attach
the file instead.

Comment 21

[Frank Tang]

jbetak- can you take a look at this ?

Comment 22

[[e-mail] (away - not reading bugmail)]

accepting...

Comment 23

[[e-mail] (away - not reading bugmail)]

pushing out...

Comment 24

[nhottanscp]

Reassign to nhotta.

Comment 25

[nhottanscp]

move to 0.9.6

Comment 26

[nhottanscp]

So the link itself is not broken, just the display string.
<a href="cid:[e-mail]">sjis$B%U%!%$%k(B</a>

Does this happen after reply? Was the original message showing fine?

Comment 27

[ji]

The linked string is broken on the insert link window, and  the reply compose
window is also broken if the linked file has the different charset of mail, and
it can't corrected.

Comment 28

[nhottanscp]

Insert link is not a mail specific. Can you see the problem with HTML composer?

Comment 29

[ji]

Yes, same thing on HTML composer, the non-ASCII path or filename is displayed as
escaped string on insert window.

Comment 30

[nhottanscp]

Then it is not broken, it is supposed to be escaped because non ASCII URI has to
be escaped.

Comment 31

[ji]

But should the display be different thing? On 4.x, we display as it is on the
same window. And we have bug 29698 for the similiar problem on URL bar.

Comment 32

[nhottanscp]

The link "href=xxx" has to be escaped, so the link shown in the link dialog is
correct. But the associated text does not have to be escaped.
So the example below, only the href part has to be escaped.
<a href="file:///D:/aaaaa%80.html">file:///D:/aaaaa%80.html</a>

So the issue is not mail specific.
Is this bug about asking not showing the escaped text?

Comment 33

[ji]

This bug is about the reply/forward compose window. When the original mail has a
string linked to a local file which has a different charset of mail, for
example, an ISO-2022-JP mail contains a string linked to a local sjis html file,
when you reply or forward inline, it doesn't inherit the charset of the original
mail, instead it uses the charset of the linked local html file, so the quoted
original mail is garbled on reply or forward inline compose window.

I'll file a seperate bug for the display problem on insert link window.

Comment 34

[ji]

Filed bug 107448 for the display problem on insert link window.

Comment 35

[nhottanscp]

Sorry about the confusion, it is not about the file name but META charset in the
attached HTML. We should not parse and pick up that charset because it is not
inserted as inline quote.

Comment 36

[nhottanscp]

There is a code to decide a charset of the original message.
http://lxr.mozilla.org/seamonkey/source/mailnews/mime/src/mimemult.cpp#251

This case, Content-Type: multipart/related; and a charset of the last part is used.
I think we had this problem before for multipart/mixed, probably we should do
the same for multipart/related.

Comment 37

[nhottanscp]

The current code does the same handling for "multipart/alternative" and
"multipart/related". A charset of the last part is used. This is fine for
"multipart/alternative" as it is described in RFC 2046 - "5.1.4. Alternative
Subtype". For "multipart/related" RFC 2387, I cannot find the recomendation of
prefering the last part. I am going to change to use the first part for
"multipart/related".

Comment 38

[nhottanscp]

Attachment: Added a special handling for "multipart/related", also changed to check number of children first to avoid calling MimeObjectChildIsMessageBody if not needed.

Comment 39

[nhottanscp]

Attachment: Fix indentation.

Comment 40

[Jean-Francois Ducarroz]

Comment on attachment 55833 [details] [diff] [review]
Fix indentation.

Looks good. R=ducarroz

Comment 41

[David :Bienvenu]

Comment on attachment 55833 [details] [diff] [review]
Fix indentation.

sr=bienvenu

Comment 42

[nhottanscp]

Checked in.

Comment 43

[ji]

Verified as fixed.