** 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.
Adding firstname.lastname@example.org to cc because he is the owner of
I found that we cannot change SendMessage to use char* because it is accessible
(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
Reasign to email@example.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.
3) Type Japanese (A, I, U, E, O) for the message body.
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
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.
"It is not just productive to test this further
given the state of the IME/Editor for M6."
What I meant was "M5" above.