Last Comment Bug 5525 - Japanese input into the mail body disappears upon "send"
: Japanese input into the mail body disappears upon "send"
QA BLOCKER- ender changes maybe too r...
Product: MailNews Core
Classification: Components
Component: Composition (show other bugs)
: Trunk
: x86 Windows NT
P3 normal (vote)
: M5
Assigned To: nhottanscp
: Katsuhiko Momoi
Depends on:
  Show dependency treegraph
Reported: 1999-04-26 15:57 PDT by Katsuhiko Momoi
Modified: 2008-07-31 01:22 PDT (History)
8 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---


Description User image Katsuhiko Momoi 1999-04-26 15:57:30 PDT
** Observed with 4/26/99 Win32 build **

When you input Japanese data/strings into the mail body coposition
window for new mail, the text does appear in the window, btu when it
is sent out, on the receiving side, nothing of Japanese input shows
up. (In the source of the message, you see that the Japanese
input content does not exist at all.)

Japanese mail-send is a requriement for M5. This bug is blocking the
requirement to be met.
Comment 1 User image Greg Kostello 1999-04-26 16:34:59 PDT
Changed to M5 and reassigning to Frank Tang.
The XIF code now encodes the charset information and uses the specified I18N
encoder is used when converting to plain text or HTML. The current problem is
that the document charset variable is not being initialized. In this case, I
default to ISO-8859-1. Frank is working on this now.
Comment 2 User image Frank Tang 1999-04-27 15:24:59 PDT
Greg, I just check in the change to set the mCharacterSet in nsDocument. I am
not sure this fix the problem. I think you code still have some problem w/
nsString conversion. Could you please try it ?
Comment 3 User image Greg Kostello 1999-04-28 12:02:59 PDT
Frank, I'm reassigning this to you. I've looked through the code and we are
using the converter based on the charset identifier. I have no way of knowing if
this works on a Japanese system because I don't have Japanese installed on my
system. You will need to verify. If something else needs to be done, beyond
using the charset information, then it will most likely need to be done in M6.
Comment 4 User image Frank Tang 1999-04-28 13:35:59 PDT
greg, all the unicode conversion through unicode converter is working fine. The
problem is the following...
1. nhotta does not set the charset in nsIDocument correctly from messanger
composer. He will mail you the diff which do the right thing.
2. nsComposeAppCore::SendMessage2 call nsEditorAppCore::GetContentAsText which
call nsTextEditor::OutputText which all expect the output in nsString. Please
notice nsString is defined as using PRUnichar as the content. The problem is the
outstream output char* (which is in the document charset, say "ISO-2022-JP" and
then it use the aOutputString += strData which cast char* as ASCII back to
nsString (which is unicode). The problem is that line.
I think we probably need two version of nsTextEditor::OutputText and
nsEditorAppCore::GetContentAsText. One version return char* with charset info
and the other version return nsString which is always unicode. Naoki say it is
fine w/ him to use the char* one. But I think there are other places in our code
need the nsString version. For example, you need it when you put the unicode
version of data into the clipboard.

Reassign this back to nhotta untill he check in the fix for the charset menu
part. Nhotta, please then assign to kostello for fixing the interface +
implementation inconsistence problem.
Comment 5 User image nhottanscp 1999-04-28 14:12:59 PDT
Accepting bug.
Adding to cc because he is the owner of
Comment 6 User image nhottanscp 1999-04-28 14:42:59 PDT
I found that we cannot change SendMessage to use char* because it is accessible
by JavaScript, we need unicode here. Ender need to implement nsString version
(i.e. current inteface) correctly.
I still need to change nsComposeAppCore.cpp for charset menu, that's related but
a separate change from Ender's change.
Comment 7 User image leger 1999-04-28 16:44:59 PDT
Adding to QA Blocker radar.
Comment 8 User image nhottanscp 1999-04-28 18:25:59 PDT
Greg, my change is ready and reviewed. When do you think your change is ready?
Do you think it's going to make M5?
Although my change is separated from Ender, I was told to check in with your
change so that this bug can be verified.
Comment 9 User image nhottanscp 1999-04-29 10:07:59 PDT
I talked to Greg this morning, he is working on the Ender side change.
The current plan is let Ender to return nsString with (UCS2). Since my change
was needed for Ender to do a charset conversion, it's not needed for the current
Reasign to
Comment 10 User image Greg Kostello 1999-04-30 12:04:59 PDT
Accepting bug however the fix will require some signifigant changes. This is at
risk for M5.
Comment 11 User image Greg Kostello 1999-05-03 14:05:59 PDT
Completed checkin with changes to OutputText and OutputHTML.

Reassigning back to Nhotta. I believe that the Ender work is done, but I need
Naoki to confirm that the work is done as required.
Comment 12 User image nhottanscp 1999-05-03 15:04:59 PDT
I tested it's working on my local build with Ender's change (pulled around
13:15). Here is a summary of my test.
1) Open a new mail compose window.
2) View->Charset->ISO-2022-JP
3) Type Japanese (A, I, U, E, O) for the message body.
4) Send
5) In 4.5, I can see the Japanese text I sent. View source shows me the correct
info (i.e. Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit and body contains ISO-2022-JP text).

Now this is not blocking Japanese mail body send testing. Obviously, more
testing should be done by IQA as I only did a very simple case.
Comment 13 User image Katsuhiko Momoi 1999-05-04 19:55:59 PDT
** Checked with 5/3/99 Win32 M5 candidate build **

I'm going to mark this fix verified for now.
I tried to input somewhat long messages using the JPN IME
but this is extremely difficult to do because of severe
IME/Editor bugs. It is not just productive to test this further
given the state of the IME/Editor for M6.

When I could input 2-3 lines of Japanese text (nearly impossible to
do without an error by the way), I've confirmed that whatever I put
in went out and arrived at the recipient's mailbox without truncation
or disappearing.
There could be something else wrong with this but we should wait
until either 1) we can paste in Japanese text properly, 2)IME.Editor
bugs get resolved and we can input more easily.

Marking the fix verified for now.
Comment 14 User image Katsuhiko Momoi 1999-05-04 19:56:59 PDT

"It is not just productive to test this further
given the state of the IME/Editor for M6."

What I meant was "M5" above.

Note You need to log in before you can comment on or make changes to this bug.