A japanse word "namae" for "name" is not drawn on textwidgets

VERIFIED FIXED in M15

Status

()

P3
critical
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: tajima, Assigned: mozeditor)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
On any textwidget of mozilla, a japanese word "na-mae" for
Engish word "name' is not drawn properly, but the 1st
character for 'na' becomes about half-size of blank character.

The does not happen on composer widget, but on text field
widget, and it is a problem of drawing the character, but
as a data, the character is properly inserted into text 
buffer.

To reproduce:
 1. build mozilla from cvs tree. The problem does not happen
    on M13 build.
 2. cd to dist/bin and run mozilla
 3. In a URL field, on a navigator window, type in 'na-mae'
    with an XIM(e.g, kinput2 on Linux). Two japanese 	 
    characters are properly displayed when they are on XIM's
    over-the-spot window, but once when commit to the text
    field, the 1st character is not drawn properly.

Comment 1

19 years ago
Momoi-san, please take a look at this namae bug.

Comment 2

19 years ago
This is also reproducible with 2/14/2000 builds. 
All 1-line inptu fields, nav location, mail headers, etc. seem to be affected
by this.

The problem is observed starting with 2/11/2000 build. I don't see this problem with
2/10/2000 Win32 build.
This may have something with the "text" .xul tag evaughan talked about in Bug 20570,
maybe not directly but in some associarted way. I'm copying evaughan just in case.
The character which does not show is the very same one prominently figuring in
Bug 20570, i.e. \u540D.

Out of the 4 characters I mentioned originally in that bug, one other character
does not show.

\u4E08 ("above" in Kanji)

There could be others. I think we need to figure something out for M14 since
the effect could be found in other characters sharing common characteristics.
Marking it "beta1" until we know what is causing this.
Keywords: beta1
Target Milestone: M14

Comment 3

19 years ago
I've raised the severity to critical as this problem is cross-platform and could affect many
other characters.
Severity: normal → critical

Comment 4

19 years ago
Inability to input very common characters in Japanese -- a very serious problem.

Comment 5

19 years ago
CC'ing bobj and lyecies.

Comment 6

19 years ago
This is just a wild guess, but perhaps the editor is looking for Carriage
Return (CR = 0x0D) and Backspace (0x08), and doing something special with them.
Or, if it's not the editor, some other part of Mozilla. The codes mentioned
above are 540D and 4E08. The low bytes are 0D and 08, so Mozilla may be
stripping the high byte somehow (e.g. one of nsString's dangerous methods), and
then treating 0D and 08 specially (e.g. removing them, or something).

Comment 7

19 years ago
Erik, your comment seems to point to a right direction.
I reported today in Bug 27692 that the Fullwidth Hyphen-Minus (\uFF0D)
cannot be entered into the Mail headers or other 1-line input fields.

Comment 8

19 years ago
cc-ing joe, who owns a lot of the code that looks at specific character input

Comment 9

19 years ago
Assinging myself as QA contact as this bug seems to have relationship to 2 other bugs I filed.
It could also affect localizability involving certain characters.
QA Contact: sujay → momoi

Comment 10

19 years ago
Need to know how broad the problem is please.
Whiteboard: [NEED INFO]

Comment 11

19 years ago
The problem I have confirmed so far that 
we cannot enter or display any character whose
2nd byte values in Unicode ends in 0D or 0A.

There will be quite a few characters in the Uncode
chart which matches this condition.
In Japanese, this condition includes characters like 
"name" (namae), "above" (ue), "damage" (son), "clothes" (fuku), 
"non-" (fu- as in fukanou), etc.

If we are shipping to Japan, this defect is fatal. There is
no way I can certify a build containing this defect for Beta 1 --
damage to our reputation will be too much since these
characters will not show in search form, nav location field, 
Address Book card, mail headers (subject), etc. and they are
used way too often to be ignored.

Comment 12

19 years ago
The problem here is a regression from M13 and specifically from
2/10/2000 builds. So marked in Keywords field.
Chanegd the platform to All.
Keywords: regression
OS: Linux → All
Hardware: PC → All
(Assignee)

Comment 13

19 years ago
i may know what this is.  assigning to me...
Assignee: beppe → jfrancis

Comment 14

19 years ago
ftang@netscape.com helped accumulate more data.
Now we know that all characters with the following 2nd 
bytes in Unicode will have this problem:

0x09
0x0A
0x0D
0x20

These cover a lot of characters.

Comment 15

19 years ago
Dear PDT team,
The words that momoi mentions are very common words.  This should be a beta1
stopper.  Cleared the "[NEED INFO]" from the White board.
Whiteboard: [NEED INFO]
(Assignee)

Comment 16

19 years ago
I have checked in a fix for the problem of ime text not working for characters 
that end in 0x0A or 0x0D.  It was only happening in single line edit fields.  
There was some code for single line edit fields that tries to replace carraige 
returns and line feeds with spaces, since CR and LF are illegal in single line 
edit fields.  That code had no way to tell what character set we were in.  For 
now I've turned that conversion off if it's an ime insert.

I haven't seen any trouble with the other values so far.  If 09 and 209 are 
really a problem, then that is a different bug.  Marking fixed.
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Updated

19 years ago
Whiteboard: [PDT+]

Comment 17

19 years ago
Doesn't the editor keep the data in PRUnichar?
If so, why aren't we matching for PRUnichar CR, LF, etc.
Those should be 2-byte characters: 0x00 0x0d, 0x00 0x0a, etc.

Updated

19 years ago
Depends on: 27954

Comment 18

19 years ago
** Checked with 2/17/2000 Win32 build **

I checked all the 0x0D and 0x0A characters reported so
far in this bug. They now can be input and displayed in
1-line field.

So I believe this workaround is effective for these
types of characters.

The 0x09 and 0x20 problem which was discovered by ftang
actually had to do with copy/pasting. So, if you copy
characters such as \u4E09 and \u4e20 from Mail Compose
text field and tried to paste into Subject or other headers,
it fails to paste -- you get nothing. In fact, I'm not able to
copy \u__0D and u\__0A, either, into 1-line fields with the
above build.

Apparently, copy/paste is another victim of the more general
problem reported elsewhere. Hopefully, Bug 27954 will take care
of this problem in copy/paste.

I'll file a new bug to mark dependency of the copy/paste
problem on Bug 27954.

Marking the current fix verified.
Status: RESOLVED → VERIFIED

Comment 19

19 years ago
I continue to be amazed at momoi's energy and thoroughness.

Comment 20

19 years ago
Now that bug 27954 has been fixed.  We should back out jfrancis' workaround
and see if the fix for bug 27954 fixes this problem.

Comment 21

19 years ago
Re-opening, so that jfrancis backs out his workaround. Removing beta1 and PDT+.
Status: VERIFIED → REOPENED
Keywords: beta1, regression
Resolution: FIXED → ---
Whiteboard: [PDT+]
(Assignee)

Comment 22

19 years ago
right.  will do when we open for m15.
(Assignee)

Comment 23

19 years ago
m15 now
Target Milestone: M14 → M15

Comment 24

19 years ago
I think this is a dup of 27954. momoi, can you verify. Mark it fixed 27954 fix 
it.

Comment 25

19 years ago
Frank, we have already verified jfrancis's workaround above.
This bug was re-opened because the fix by rickg will now make it possible to 
remove the workaround. Joe has targeted the removal for M15. 
M14 will go out with Joe's workaround though it is not needed strictly speaking. 
(Assignee)

Comment 26

19 years ago
fixed.  sujay, i'll have to verify this myself.
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED

Comment 27

19 years ago
** Checked with 5/9/2000 Mac/Win32/Linux build **

I tried all the original  problem charactesr using Japanese IMEs on the above OSs
and the builds from 5/9. The problem characters now display without 
a problem. If Joe has removed the workaround, then rickg's fix (Bug 27954) is
holding for these cases.
Marking the fix verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.