Content-Type: charset of the original message should be used.
Assign to me (for now).
Requested email@example.com to add charset name support to nsIMessage.
Requested firstname.lastname@example.org to add charset name support to nsIMessage.
I've added it, but there's no code that sets it to anything other than the empty
string. I'm drowning in IMAP and will be until after M6.
Changed to use the new code. Use the value when the string is not empty.
Moving to M6, this will not work until nsIMessage change.
Reassinging to email@example.com.
What more do you want me to do? I've added the methods to nsIMessage. I'm
guessing you want me to parse every message for its content type and set the
field appropriately. This is of course impossible for IMAP and News...didn't we
used to rely on libmime having parsed the message in the past?
Reassinging to firstname.lastname@example.org.
I don't know who is responsible for reply implementation.
Reassigning to rhp
*** Bug 6995 has been marked as a duplicate of this bug. ***
Will look at for M8.
How should this work? Should I just set the charset of the reply to the same
charset of the replied to message? This seems like we could have problems doing
that, but just guessing here.
For reply and forward, the charset of the original message main body should be
Won't get to this before tonight...kind of a tough problem.
Naoki, As a temporary improvement, can we just omit the charset parameter
in the headers for replies and forwards until we get this fixed?
It is not usual to send messages without Content-type charset.
I don't think we get workaround by sending without charset, do we?
Rich, are you proposing to omit the charset parameter from all parts including the 1st of the multi-part bodies?
If so, that wouldn't be a good idea,
I'm not suggesting we change anything...I just latered the bug because this is
not a trivial fix and then bobj and naoki had the other comments.
Sorry, Rich. My question should have been aimed at bobj.
I talked to bobj and momoi, bob's suggestion depended the charset override
feature which is not working yet (5938). So we should not omit a charset label
Does our 4.x product do what's being suggested here; i.e. use the charset from
the message being replied to, rather than the charset of the author of the
Effectively, I'm asking whether this is an RFE or a regression.
I don't know about 'RFE' but this is not a regression of 4.x.
I think 4.x depended on the charset menu selection to decide the charset of
sending out messages.
But this is needed for 5.0.
In 4.x, reply/forward quoted message cound not be displayed unless the charset
menu is set properly.
5.0 uses Content-type charset and usually the user doesn't have to set charset
menu for viewing. Reply/forward also does not require to set charset menu for
viewing/editing but sending out message needs to specify a charset. For initial
charset for reply/forward, it is appropriate to use the charset of the original
message than the current charset menu selection.
I assume confusions if we rely on the menu selection for reply/forward charset
(e.g. sending out with a wrong charset by accident and the receiver cannot see
the message at all).
BTW, there is also a bug of no menu check mark.
Well, two thoughts:
> For initial charset for reply/forward, it is appropriate to use the charset of
> the original message than the current charset menu selection.
I don't understand this. If the reply isn't in the same character set as the
original message, it seems like the charset on the reply is wrong -- i.e.
doesn't reflect the data which is actually in the message.
Second, Rich tells me that changing the MIME parser so that we have the original
character set hanging around in memory is a major change. It's not likely we'll
attempt that before he returns, if at all. TFV -> M13.
>I don't understand this. If the reply isn't in the same character set as the
>original message, it seems like the charset on the reply is wrong -- i.e.
>doesn't reflect the data which is actually in the message.
That case (e.g. replying to French message by Japanese), it is users
responsibility to reset the charset. There is also a risk that the original
message may not be mapped to the sending charset if sending out as different
charset than original unless send as unicode (e.g. UTF-8). For that, we're
planning for replacing those unmapped characters as entities (but that's for
I'll investigate further when time allows.
If there's an i18n interop issue here, we should look at it for B1.
For reply we do, but not for forward.
So, how much extra work needed or performance increase for getting Content-Type
of the main body in case of we're not quoting?
this is a test
I have an idea how to fix this problem, but I need to understand one thing. Do
we need to use the charset of the mail message, or the part that is displayed
as the primary body part. Please tell me the first one :-) Also, I could use a
message that has a non us-ascii charset for the top level mail message itself.
Can you post an example I can work from.
Finally, after putting my brain into this one, I think I have it fixed. Now,
when you reply to a non US-ASCII email, you will reply in that charset.
Forwarding INLINE also has this same behavior, but if you forward as an
attachment, I do not do this. The reason is that the attachment is an
encapsulated message/rfc822 message that should render properly since it has
all of the appropriate charset information inside of the message structure.
I will check this in when the tree opens for M14.
Does this do something like:
1. For single part msg --> relfect the content-type charset info.
2. For multi-part msg --> reflect first body par charset
for reply/forward inline?
Not currently. This increases the complexity to have to determine the type of
message and decend to the main body part to pull out the charset. Is is this
the right thing to do???
For multi-part, if you are not descending into the body to get the reply/forward-inline charset,
where do you get the charset info?
I get it from the RFC822 message header. If one isn't specified it will default
to the users default settings.
Rich, I remember discussing some of this with nhotta. The spec has been
published to this page:
"Charset of the original message (main body) is used." for charset for reply/forward mail.
Naoki argued above also that we should not use the default charset set by the user if
there is a charset info already in the mail. We would not go crazy like descending into 2nd, 3rd parts
for multi-part msgs. The 1st (main) part should be sufficient.
Thus, falling back to user's default fro multi-art is not what the spec would call for.
Could we wait until Monday when Naoki is back to settle this? I'm working on Messenger
charset menu related specs and some of them may have bearing on this issue.
This makes sense. I will see if I can handle this situation...I have some ideas
how to make this happen.
Good news. I think after some more hacking that I am able to decend into the
body part of a multipart/ message and get the charset to be used for replies
We'll need more testing, but so far, I think this is working.
Just checked in the fix for this problem.
I'm in the process of looking at this fix. It's going to take a bit of time for
we need to cover a variety of cases.
There seems to be one problem now. On our smoketest mailbox, the 1st msg is
Latin 1 but using HTML entities and so marked as US-ASCII. The last msg is in UTF-8
and marked as so. These two will not go out reflecting the original charset label
if you have the following setting in prefs.js.
I tried, Trad. Chinese (Big5), Simplified Chinese (gb2312), Korean (EUC-KR),
Czech (ISO-8859-2), Russian (KOI8-R), and they are OK even with the above setting.
Naoki, the above is not the mail default setting, is it? Could you remind me what the mail default
setting formual is? I'll also try that later.
Momoi san, your setting for the mail send default charset is correct.
And that setting should not affect the behavior of reply/forward charset
I should add that when you remove: user_pref("intl.character_set_name", "iso-2022-jp");
reply msgs work as intended by this fix.
By the way, forward/inline seems to have this problem with the above special setting.
Correction: "By the way, forward/inline seems to have this problem with the above special setting."
to: By the way, forward/inline DOES NOT seem to have this problem with the above special setting.
Re-opening it since there is a limited but nonetheless real problem with some
msg charset headers when the mail default charset setting exists in prefs.js.
Ok, here is the problem. We make a call to nsMsgI18NGetDefaultMailCharset() in
the compose back end when we create a message. This is the charset we will use
unless there is a non us-ascii specified charset on the mail message. If we
have a non-usascii, it shows up on the content type of the quoting operation,
but other than that, we don't see any and we don't change it.
I'm looking to see where exactly that is stripped off the line.
I have a fix that Naoki is reviewing.
Ok, I think I have a fix for this one now. Will try to get checked in tonight.
Due to Beta indication in Summary, putting beta1 into keyword field.
Checked in this fix today.
Half-way through. So far tried replying to some 16 different
language msgs with some charset buried in the main body part.
Also tried the problem ones with default charset set to ISO-2022-JP.
So far none failed. I will move on to forard/inline to finish
At this point, I cannot verifyu this until Bug 28055 is fixed.
** Checked with 2/21/2000 Win32 build **
This feature is working very well with the above build.
I checked with some 17 different charsets -- some in
single part msgs and others in the first part of
multipart msgs. We are now able to reflect the original
charset regardless of the mail-send default charset setting
with all these test msgs.
This is in accord with our current spec.
Marking it verified/fixed.