Steps to reproduce: -compose a message with 8-bit chars in the header and body; -send it; -open in 4.6 //note: squares for 8-bit chars in the message and thread pane header and no body

we can slightly change the summary of this bug. I wasn't seeing any body because my message body strated with 8-bit chars. The fact is : after the first 8-bit chars the body would be cut off: c'est le sujet vulné(square instead of "é", and the rest "able" won't show up)

Messenger is receiving incorrect unicode string. For example, Latin1 letter Ê (0xCA), we are getting 0x9495 instead of 0x00CA. 0x9495 is a CJK and the converter is not able to convert to latin1. (in fact, if we change the charset menu to ISO-2022-JP then the character is converted to Japanese sent out correctly as Japanese letter). I suspect that something happened (nsString2?) in the week end because the exact same problem happens in the header widget which currently not using Ender (see 7425).

Reassigning to kostello@netscape.com. I put a break point in nsTextEditor::OutputText and saw the buffer already contained incorrect unicode before calling the parser.

Reassigning to rickg@netscape.com. I think this is the same problem as 7430.

Frank -- I think this issue is in your area.

Naoki, please find out what the problem is and explain in bug report. Otherwise, people will keep reassing this back to us...

This is a dup of 7479 which is a bug for non breaking space. In that bug, the problem is explained by sfraser@netscape.com and it also applies to all Latin1 8 bit characters. We can keep this bug as separated as 7479 is for non breaking space only while we need to do more verification. Reassigning to rickg@netscape.com.

I created a dependency link to 7479.

This bug should be fixed because 7479 has been fixed. Marina, please verify with the next build.

verified with 6/10/99 build. The body is sent correctly as Western (ISO-8859)