** 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.

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.

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 ?

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.

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.

Accepting bug. Adding ducarroz@netscape.com to cc because he is the owner of nsComposeAppCore.cpp.

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.

Adding to QA Blocker radar.

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.

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 plan. Reasign to kostello@netscape.com.

Accepting bug however the fix will require some signifigant changes. This is at risk for M5.

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.

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.

** 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.

Correction: "It is not just productive to test this further given the state of the IME/Editor for M6." What I meant was "M5" above.