Stesp to reproduce: (IMAP and POP both have this problem) -send a message to yourself from 5.0 that has non-ascii chars in the Subject and body; -get the message; -click Reply(Forward); //note the problem : when quoting the subject header high-ascii are garbled and the message body is lost(probably separete bug) This problem does include Latin1, UTF-8 and JA

I used my local build (yesterday's pull with bug fixes 13891, 14045). I tested pop and imap with Latin1, Japanese and UTF-8 and did see the problem. Because of the bug 3979, we should explicitly reset charset of reply/forward mail every time. Marina, did you reset charset before send?

This bug is about quoting the text incorrectly in the Composer window before sending mail. It seems that this problem: 1. occurs on boht IMAP and POP3 mail. 2. occurs only wiht HTML mail body so far. 3. occurs on and off. The same message may get quoted correctly once and then maybe quoted in corrupt manner. 4. what we haven't tried yet is using or not using charset detector has any effect.

I still cannot reproduce this using i18n smoke test data. Please attach file(s) so I can use the same data, thanks.

Here's a mail file "demo" in .zip format. http://rocknroll/users/momoi/publish/seamonkey/bugs/demo.zip Try the message whose header reads "Kore ha nihongo no mail desu."

The French message -- the very first one "Sante Nouveau!" also has the same problem on and off.

Reassign to mscott, this may be a dup of 11888. I don't know about how the quoted text is generate, don't know either about the recent change. I have not been able to reproduce it (NT4 debug build) and didn't happen with momoi's other machine (NT 4 US release build). But Marina's found this problem on NT 4 US release build.

I don't think it will be a dup because #11888 was happening on the IMAP only ant hits problem occurs on POP3 also.

** Checked with 10/21/99 Win3q build ** A lot of things have changed since this bug was filed. For example, there is no longer "Froward/quote"-- there is only Forwad/inline or Forward/as attachment. Thus, I'm going to now summarize what remains as a problem as of the above build and mark it as [Dogfood]. The problem is now restricted to Plain Text mail only: 1. When you reply/quote the original mail written in JPN using Plain Text mail compose, the body text is mangled. 2. The subject header is quoted OK. 3. This does not happen with teh HTML send option. 4. This happens either with IMAP or local mail. 5. The problem does not happen with Latin 1 body. So, this bug will now be used to track the quoting problem in Plain Text mail for the bod text (in multi-byte characters). We cannot look at every day functionality such as Reply with this defect lingering. This is Dogfood for Intl Mail. rhp, is this your bug?

Currently we have data to show that the quoting corruption occurs with JPN and UTF-8 msgs.

As the bug is re-defined as above, it now looks like this bug is very similar to Bug 15465. In that bug, corruption in quoting 8-bit Latin 1 characters (QP-encoded or raw) was noted. I wonder if we can combine these 2 into one bug. We might consider marking this one a duplicate of Bug 15465.

Kat, thanks for the detailed analysis breaking down what exactly this bug represents now. This does sound like more of an rhp bug now. The only thing I can guess is that because it is in plain text, we don't have a meta tag which describes the character set for layout?? But I'm not very familiar with this. Over to rhp to take a look... I do agree with Kat this does seem like a dogfood issue to me for I18N.

Let me add one more piece of info on item #5 above where I said that this does not happen with Latin 1 accented body text. I should further restrict it to say that it does not happen with Latin 1 data text which has HTML entities representing accented characters in the original. I think that is the Latin 1 test msg I have. In Bug 15465, quoting failure in Plain text compose window is mentioned with regard to Latin 1 data which are either QP-encoded or raw 8-bit, i.e non HTML entities. Scott, as you say, it must be the lack of meta-tag in Plain text mail which mangles all potentially 8-bit mail (but not HTML entities whose Unicode points can be found without a meta-tag). Naoki, if you agree, please mark this bug a duplicate of Bug 15465, and let's make sure that we test both Latin 1 and other 8-bit text body when that bug is fixed.

*** This bug has been marked as a duplicate of 15465 ***

verified as such