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
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
Marking as M6.
This is what I saw in the view where =C9 supposed to be É.
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 É).
I think we need more generic solution for these kind of problems.
Reassigning to firstname.lastname@example.org.
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
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!<%k$G$9!#(B (Note "<"�j
The correct sequence is:
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
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
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
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.
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 :-)
Assigning to marina for verification.
I verified this bug with M9candidate 1999-08-24 on Windows and here are the
1.send a message with a string containing non-ascii in the body using Latin1
-get message back,select it and click Reply (or Forward);
//note: all high ascii are garbled or the string is truncated before non-ascii
(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:
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.
This is the same technical issue we are attacking in Bug #17034. When I fix
one, I should fix the other.
I believe that most quoting/forwarding issues should be fixed with my latest
Verifiyng with 1999-12-14 win build. I don't see it happening any more.