73503 - Charset override is broken for quoting inline attachment with no charset label

Status: VERIFIED FIXED

(MailNews Core :: Internationalization, defect)

Description

[ji]

****Observed with linux 03/26 and win32 03/21 trunk build*******

When reply to or forward as inline a message with an attachment which doesn't have a meta tag, the reply or forward msg 
doesn't inherit the charset that the mail body carries, instead it inherits the charset that the charset menu currently points to.

Steps to reproduce:
1. Launch Mail.
2. Send the http://www.yahoo.co.jp page in Japanese iso-2022-jp  to your testing account. 
   This message will have iso-2022-jp encoded mail body and base64 encoded euc-jp html attachment
3 [details] [diff] [review]. After the mail is received, Select  View | Character Coding | Japanese (EUC-JP) to be able to view the attachment.
4. Click on Reply or select Forward as inline, the reply or forward mail compose window will have have Japanese (EUC-JP) 
labeled in the window title and the charset menu has check mark on euc-jp (if the euc-jp is on the active list)

This is a regression from 6.0.

Comment 1

[ji]

Attachment: A Japanese iso-2022-jp mail which has a non-meta tagged euc-jp html attachment

Comment 2

[marina]

compare to bug # 28868?

Comment 3

[nhottanscp]

Do you mean that quoting does not work?

Comment 4

[marina]

yes, that the charset parameter disappears from the Content-Type line when we do
forward/inline. And since there is no meta charset tag in the attachment itself,
it cannot be displayed correctly.

Comment 5

[nhottanscp]

We do not specify a charset for HTML attachment if no META charset is in the HTML.
So it did not disapper, it was not there when it was sent.

Comment 6

[ji]

The problem I report here is NOT about the content-type line.
The reply or forward inline mail doesn't inherit the charset that the original
mail carries. It just takes the charset of the original mail's charset menu
currently points to. For example, when reply/ forward inline an iso-2022-JP
mail, it inherits the iso-2022-jp. But it doesn't happen in that way when the
charset menu is not pointing to iso-2022-jp, at that time, the chatset menu
could points to different charset to be able to view a non-meta tagged attachment.
At 6.0, when reply or forward inline, it always inherits the charset of the
original mail body. It ignores the charset that the charset menu points to.  Is
there any spec changes?

Comment 7

[ji]

Actually, it's a more generic problem, not only limited to a mail with a
non-meta attachment. It can happen to any mail. For example, for a iso-8859-1
mail, if you change the charset to iso-2022-JP to view it, and then reply, the
reply mail takes iso-2022-jp instead of iso-8859-1.
However, this problem affects more to a mail with a non-meta attachment.

Comment 8

[nhottanscp]

Looks like override charset is not used for quoting in general.
I am using 6.01 and override does not affect quoting at all.
Adding momoi to cc, has this ever been working?

Comment 9

[Katsuhiko Momoi]

What should the spec be on this?

In 6.0 and 6.01, I don't believe we had an override 
working in quoting. But in current builds, we probably
have an override effect to be working. 

How does one know that you're overriding only the attchments
and not the main body part? If you overrode a charset parameter,
should that new charset not be the one to use for quoting?

Comment 10

[nhottanscp]

>But in current builds, we probably have an override effect to be working.
I don't think this got changed since 6.0.

We do not have a way to control charset of indivisual attachments.
So the expected behavior under the current UI would be to use a menu checked
charset then apply it for main body and attachments.

Comment 11

[ji]

>So the expected behavior under the current UI would be to use a menu checked 
charset then apply it for main body and attachments.

Does this apply to reply/froward inline messages?

Comment 12

[ji]

My question was: which charset should reply/forward inline take?
The one on the menu or the one in the original mail body (in case it has one)?

Comment 13

[nhottanscp]

The menu charset to be applied to main body and inline attachments for quoting.
But it is not working, that is this bug.

Comment 14

[ji]

So there is spec changes for this then.

Comment 15

[Katsuhiko Momoi]

For attachments, is it possible not to touch the data but rather
quote the original atatchment material as is? This may mean that
the attachment may not show correctly but it will be go out in the
same encoding as the original regardless of what the menu
choice is.

Comment 16

[nhottanscp]

The quoting is done by editor which uses unicode interface, so conversion is
required.

Comment 17

[nhottanscp]

bug 39736 - charset override has no effect on quoting (fixed in RTM)
bug 66227 - Manually selected charset is not marked on the charset menu (fixed 
in mozilla0.8)

Xianglan, please confirm following.
So, override for quoting in general should be working.
Quoting for inline attachemnt with no charset label does not work, even after 
you set a charset by menu (e.g. to EUC-JP for yahoo.co.jp).

Comment 18

[ji]

Yes, the override for quoting for general is working.
But it's broken for inline attachment with no charset label.

Comment 19

[ji]

Changed the summary to better reflect the problem.

Comment 20

[nhottanscp]

By fix of bug 39736, the override applies to the quoted text including inline 
attachments. So marking this as fixed as well.

Comment 21

[ji]

Verifie with 04/17 trunk builds.