2.96 KB, text/html
2.96 KB, text/plain
51.59 KB, image/jpeg
2.10 KB, text/plain
Added a special handling for "multipart/related", also changed to check number of children first to avoid calling MimeObjectChildIsMessageBody if not needed.
3.59 KB, patch
|Details | Diff | Splinter Review|
3.60 KB, patch
Jean-Francois Ducarroz: review+
|Details | Diff | Splinter Review|
****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.
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.
Created attachment 44129 [details] A testing mail containing one link to euc file and one link to sjis file.
Created attachment 44130 [details] Please ignore the 1st attachment. I attached as a html file. Use this one instead.
Xianglan, is shift-jis your system encoding?
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.
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.
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.
so you are talking about the file name and the text supplied for the link not the contents.
It's for the contents which include the text for the link.
and also the subject.
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
Created attachment 44154 [details] Another testing mail with Ja subject and mail body that contains a link to a sjis file
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.
I understand now that we are talking about different issues after Xianglan showed me the problem on her machine.
Mail/news issue. assigning to nhotta.
Assignee: yokoyama → nhotta
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.
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.
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.
I think creating a link pointing to a local file is not common, I would attach the file instead.
jbetak- can you take a look at this ?
Assignee: nhotta → jbetak
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Reassign to nhotta.
Assignee: jbetak → nhotta
Status: ASSIGNED → NEW
move to 0.9.6
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.5 → mozilla0.9.6
So the link itself is not broken, just the display string. <a href="cid:firstname.lastname@example.org">sjis$B%U%!%$%k(B</a> Does this happen after reply? Was the original message showing fine?
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.
Insert link is not a mail specific. Can you see the problem with HTML composer?
Yes, same thing on HTML composer, the non-ASCII path or filename is displayed as escaped string on insert window.
Then it is not broken, it is supposed to be escaped because non ASCII URI has to be escaped.
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.
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?
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.
Filed bug 107448 for the display problem on insert link window.
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.
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.
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".
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.
Comment on attachment 55833 [details] [diff] [review] Fix indentation. Looks good. R=ducarroz
Attachment #55833 - Flags: review+
Comment on attachment 55833 [details] [diff] [review] Fix indentation. sr=bienvenu
Attachment #55833 - Flags: superreview+
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Verified as fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.