nsComposeAppCore should not use ToNewCString for unicode conversion

VERIFIED FIXED in M5

Status

MailNews Core
Internationalization
P1
normal
VERIFIED FIXED
19 years ago
9 years ago

People

(Reporter: nhottanscp, Assigned: nhottanscp)

Tracking

Trunk
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

19 years ago
ToNewCString only works for Latin1.
Compose need to convert unicode to a mail charset (can be taken from a pref and
the charset menu).
I will mail a sample code to Jean-Francois.
(Assignee)

Updated

19 years ago
Component: Composition → Internationalization
QA Contact: 4080 → 1308
Target Milestone: M4

Comment 1

19 years ago
Actually, ToNewCString only works for ASCII (not Latin1) since it probably
is just casting off the high byte of the UCS character.
(Assignee)

Updated

19 years ago
Assignee: ducarroz → nhotta
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 2

19 years ago
I checked in the code to do the conversion.
We still have two problems before we can do the verification.
#4388 - Enable 8-bit input for 8859-1
#4394 - libmime to export QP/Base64 encoders

Updated

19 years ago
Priority: P3 → P1

Comment 3

19 years ago
Changed to P1 -- needed for M4.
(Assignee)

Comment 4

19 years ago
#4394 has been resolved. I verified it (for QP only) by putting 8 bit characters
hard coded.
#4388- By using 4/2 build, I cannot input 8 bit chars but paste from other app
is working. As my build is crashing in Ender when I try to send, I cannot try
pasted 8 bit string with the new QP code. I will try again on Monday.
(Assignee)

Comment 5

19 years ago
It doesn't work on 4/5 build.
I pulled the today's build. In the message composer, a returned text from Ender
does not contain 8 bit characters. They are visible in the view but they are
seemed to be stripped out.

Comment 6

19 years ago
nhotta: Please clearify which file use ToNewCString, and in what action will
cause such code get code.
(Assignee)

Comment 7

19 years ago
It was in nsComposeAppCore.cpp, the fix was checked in.
The bug is still open because there is a blocking bug (#4388) prevents the
verification.
(Assignee)

Updated

19 years ago
Target Milestone: M4 → M5
(Assignee)

Comment 8

19 years ago
Changing to M5 since #4388 is M5.
(Assignee)

Updated

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

Comment 9

19 years ago
Change status to 'FIXED' verification is blocked by #4388.
To verify this, try non us-ascii characters in the body then check the message
in 4.5.

Comment 10

19 years ago
This fix can be verified now for Latin 1 as the 2 blocking bugs have
been resolved. For Japanese, it's still not possible to see the results
of send.
I can go ahead and verify this based on Latin 1 send which is
now working for the header and body, or can wait until the
Japanese send becomes possible.
(Assignee)

Comment 11

19 years ago
You can verify this by sending Latin1 body.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 12

19 years ago
** Checked with 4/29/99 Win32 build **

It is possible to send Latin 1 mail body containing 8-bit
characters in it. They are properly QP-encoded in Latin 1.
This confirms that the fix is working OK.

Marking the fix verified.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.