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

VERIFIED FIXED in mozilla0.9.6

Status

MailNews Core
Internationalization
P4
normal
VERIFIED FIXED
17 years ago
10 years ago

People

(Reporter: ji, Assigned: nhottanscp)

Tracking

({intl})

Trunk
mozilla0.9.6
All
Other

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments)

(Reporter)

Description

17 years ago
****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.
(Reporter)

Comment 1

17 years ago
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.
(Reporter)

Comment 2

17 years ago
Created attachment 44129 [details]
A testing mail containing one link to euc file and one link to sjis file.
(Reporter)

Comment 3

17 years ago
Created attachment 44130 [details]
Please ignore the 1st attachment. I attached as a html file. Use this one instead.

Updated

17 years ago
Keywords: intl

Comment 4

17 years ago
Xianglan, is shift-jis your system encoding?
(Reporter)

Comment 5

17 years ago
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

17 years ago
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.
(Reporter)

Comment 7

17 years ago
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.
(Reporter)

Comment 8

17 years ago
Created attachment 44143 [details]
A screenshot of the reply window to the testing mail.

Comment 9

17 years ago
so you are talking about the file name and the text supplied for the link not
the contents.
(Reporter)

Comment 10

17 years ago
It's for the contents which include the text for the link.
(Reporter)

Comment 11

17 years ago
and also the subject.

Comment 12

17 years ago
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
(Reporter)

Comment 13

17 years ago
Created attachment 44154 [details]
Another testing mail with Ja subject and mail body that contains a link to a sjis file
(Reporter)

Comment 14

17 years ago
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

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

Comment 16

17 years ago
Mail/news issue.  assigning to nhotta.
Assignee: yokoyama → nhotta
(Reporter)

Comment 17

17 years ago
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.
(Reporter)

Comment 18

17 years ago
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.
(Assignee)

Updated

17 years ago
Priority: -- → P4
(Reporter)

Comment 19

17 years ago
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.
(Assignee)

Comment 20

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

Comment 21

17 years ago
jbetak- can you take a look at this ?
Assignee: nhotta → jbetak
accepting...
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.4
pushing out...
Target Milestone: mozilla0.9.4 → mozilla0.9.5
(Assignee)

Comment 24

17 years ago
Reassign to nhotta.
Assignee: jbetak → nhotta
Status: ASSIGNED → NEW
(Assignee)

Comment 25

17 years ago
move to 0.9.6
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.5 → mozilla0.9.6
(Assignee)

Comment 26

17 years ago
So the link itself is not broken, just the display string.
<a href="cid:part1.07060507.04060202@netscape.com">sjis$B%U%!%$%k(B</a>

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

Comment 27

17 years ago
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.
(Assignee)

Comment 28

17 years ago
Insert link is not a mail specific. Can you see the problem with HTML composer?
(Reporter)

Comment 29

17 years ago
Yes, same thing on HTML composer, the non-ASCII path or filename is displayed as
escaped string on insert window.
(Assignee)

Comment 30

17 years ago
Then it is not broken, it is supposed to be escaped because non ASCII URI has to
be escaped.
(Reporter)

Comment 31

17 years ago
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.
(Assignee)

Comment 32

17 years ago
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?
(Reporter)

Comment 33

17 years ago
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.
(Reporter)

Comment 34

17 years ago
Filed bug 107448 for the display problem on insert link window.
(Assignee)

Comment 35

17 years ago
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.
(Assignee)

Comment 36

17 years ago
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.
(Assignee)

Comment 37

17 years ago
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".

(Assignee)

Comment 38

17 years ago
Created attachment 55830 [details] [diff] [review]
Added a special handling for "multipart/related", also changed to check number of children first to avoid calling MimeObjectChildIsMessageBody if not needed.
(Assignee)

Comment 39

17 years ago
Created attachment 55833 [details] [diff] [review]
Fix indentation.
Comment on attachment 55833 [details] [diff] [review]
Fix indentation.

Looks good. R=ducarroz
Attachment #55833 - Flags: review+

Comment 41

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

sr=bienvenu
Attachment #55833 - Flags: superreview+
(Assignee)

Comment 42

17 years ago
Checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 43

16 years ago
Verified as fixed.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.