Japanese input into the mail body disappears upon "send"

VERIFIED FIXED in M5

Status

MailNews Core
Composition
P3
normal
VERIFIED FIXED
19 years ago
9 years ago

People

(Reporter: Katsuhiko Momoi, Assigned: nhottanscp)

Tracking

Trunk
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: QA BLOCKER- ender changes maybe too risky for M5)

(Reporter)

Description

19 years ago
** 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.

Updated

19 years ago
QA Contact: 4080 → 1308

Updated

19 years ago
Assignee: kostello → ftang
Target Milestone: M5

Comment 1

19 years ago
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.

Updated

19 years ago
Assignee: ftang → kostello

Comment 2

19 years ago
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 ?

Updated

19 years ago
Assignee: kostello → ftang

Comment 3

19 years ago
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.

Updated

19 years ago
Assignee: ftang → nhotta

Comment 4

19 years ago
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.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 5

19 years ago
Accepting bug.
Adding ducarroz@netscape.com to cc because he is the owner of
nsComposeAppCore.cpp.
(Assignee)

Comment 6

19 years ago
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.

Updated

19 years ago
Whiteboard: QA BLOCKER

Comment 7

19 years ago
Adding to QA Blocker radar.
(Assignee)

Comment 8

19 years ago
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.
(Assignee)

Comment 9

19 years ago
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.
Assignee: nhotta → kostello
Status: ASSIGNED → NEW

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 10

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

Updated

19 years ago
Whiteboard: QA BLOCKER → QA BLOCKER- ender changes maybe too risky for M5

Updated

19 years ago
Assignee: kostello → nhotta
Status: ASSIGNED → NEW

Comment 11

19 years ago
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.
(Assignee)

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 12

19 years ago
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.
(Reporter)

Updated

19 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 13

19 years ago
** 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.
(Reporter)

Comment 14

19 years ago
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.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.