Steps to reproduce: open an e-mail with non-ascii chars in the mail body|click Reply or Forward //note: there is no proper conversion done for the string

question: do you see the text broken before send in the editor or broken in the received message?

I see it broken before sending.

I will try to fix the display problem. But looks like reply/forward is not officially implemeneted for M5 (see 5493). We also have Ender related bug for the body sending. Marking as M6.

This is what I saw in the view where =C9 supposed to be É. > abc=C9xyz>> In above case, the text should be QP decoded. The same kind of problem could happen if we support HTML (e.g. named entity like &Eacute). I think we need more generic solution for these kind of problems. Reassigning to ducarroz@netscape.com.

Reply and Forward are totally broken since few days. I will take a look at it.

Reply/Forward are back now in plain text and HTML. marina, momoi could you test again to see if the problem still exists.

If we think this is fixed lets mark it so, get it on the test radar, and then re-open if its not..

Forward and Reply of: 1. Latin 1 message body is now working for both Plain Text & HTML Mail. 2. Japanese message body is broken in display and also as a result of "send": a. The body is quoted in raw JIS when composer displays it. b. It seems that the JIS code point is mistakenly interpreted as "<" of HTML. Thus the body text after this point is not readable as Japanese. See this example, ("Kore ha Nihongo no meeru desu') below: $B$3$l$OF|K\8l$N%a!&lt;%k$G$9!#(B (Note "&lt;"�j The correct sequence is: $B$3$l$OF|K\8l$N%a!<%k$G$9!#(B This problem of "<" is already visible in the Composer window. Naoki, does the lack of Frank's Meta-tag code contribute to these 2 problems or are they independent? The results for Japanese were obtained for both Plain text and HTML mail settings. Since both Latin 1 and Japanese Reply/Forward are M6 International requirements, I can't mark this "resolved".

** The above results were obtained with the 5/22/99 Win32 build **

Regarding the question by momoi, I think sending is not affected by the META problem. Last time I mentioned this quoting problem, I was told this was not in feature but now it's actually in (see http://www.mozilla.org/mailnews/milestones.html). I checked the code nsComposeAppCore::HackToGetBody (nsComposeAppCore.cpp), it has mMsgCompFields->SetBody(nsAutoCString(msgBody), NULL); which only works for Latin1. I don't know this is a temporary soultion or not (it was when I asked last time). Also, if this part is going to changed for the Ender related bug (6672 - M7) then we need to change the milestone.

moved to M7

Now i'm getting Parsing error in the message header with 8-bit chars after receiving forwarded or replyied messages ****observed with 5/24 Win build****

Reassign to rhp as it should be a backend issue.

It looks like the Latin-1 chars conversion bug is back.Forwarding a message that was sent as "Inline" or with the option "As attachement" turn all non-ascii chars into garbage before sending (so it is not a send but i guess a display problem). Obsereved with 1999072608 windows build.

maybe I'm reading this wrong, but this seems to work for me. Can you verify if this is still broken. - rhp

I don't know how to verify this bug sisnce Reply and Forwarding is broken (bug #11094). It might be that the reopening of this bug (5498) was a regression and build problem but i guess Naoki fixed so after i can really verify it i would say resolution RESOLVED as FIXED would be more appropriate.

sounds reasonable to me :-) - rhp

Assigning to marina for verification.

I verified this bug with M9candidate 1999-08-24 on Windows and here are the results: 1.send a message with a string containing non-ascii in the body using Latin1 encoding. -get message back,select it and click Reply (or Forward); //note: all high ascii are garbled or the string is truncated before non-ascii char. (same is true for Newsgroup Reply or Forward) 2. repeating all of the above steps with UTF8 encoding returns the correft results (it is true for Newsgroups). So i think we have to clear the resolution WORKSFORME, i'm reopening this bug

Additional comments: those results are incorrect for Latin1 only on IMAP and News server. (Latin-1 string are either truncated or garbled in the message body) The POP protocol doesn't have this problem.

This was observed with 1999-08-24-12 M9 build for Windows. I would say " a stopper". The only good thing is it is working correctly for POP3 protocol and with UTF8 encoding on IMAP and News server.

per both msanz and momoi...this will not be a stopper for M9. Puting on M10 radar. marina, you could add text for a Release Note to: http://bugzilla.mozilla.org/show_bug.cgi?id=11352

This will be added to M9 Intl Release notes -- which will be done later today. Thanks!

Bulk move rhp bugs to M11 for now

Since Rich is out, and this bug is not mentioned in 12907, I'm moving to M15

Bulk change to assigned. - rhp

This is the same technical issue we are attacking in Bug #17034. When I fix one, I should fix the other. - rhp

I believe that most quoting/forwarding issues should be fixed with my latest checkin. - rhp

Verifiyng with 1999-12-14 win build. I don't see it happening any more.