Closed Bug 27699 Opened 26 years ago Closed 26 years ago

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

Categories

(Core :: DOM: Editor, defect, P3)

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: tajima, Assigned: mozeditor)

References

Details

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.
Momoi-san, please take a look at this namae bug.
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
I've raised the severity to critical as this problem is cross-platform and could affect many other characters.
Severity: normal → critical
Inability to input very common characters in Japanese -- a very serious problem.
CC'ing bobj and lyecies.
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).
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.
cc-ing joe, who owns a lot of the code that looks at specific character input
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
Need to know how broad the problem is please.
Whiteboard: [NEED INFO]
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.
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
i may know what this is. assigning to me...
Assignee: beppe → jfrancis
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.
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]
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
Closed: 26 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+]
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.
Depends on: 27954
** 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
I continue to be amazed at momoi's energy and thoroughness.
Now that bug 27954 has been fixed. We should back out jfrancis' workaround and see if the fix for bug 27954 fixes this problem.
Re-opening, so that jfrancis backs out his workaround. Removing beta1 and PDT+.
Status: VERIFIED → REOPENED
Keywords: beta1, regression
Resolution: FIXED → ---
Whiteboard: [PDT+]
right. will do when we open for m15.
m15 now
Target Milestone: M14 → M15
I think this is a dup of 27954. momoi, can you verify. Mark it fixed 27954 fix it.
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.
fixed. sujay, i'll have to verify this myself.
Status: REOPENED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
** 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.