[IME]There is no highlight appreas on an one double-byte(kanji) Japanese candidate in Composer

VERIFIED FIXED in mozilla0.9.1

Status

()

Core
Internationalization
P2
major
VERIFIED FIXED
17 years ago
7 years ago

People

(Reporter: Yuying Long, Assigned: mjudge)

Tracking

({inputmethod, intl})

Trunk
mozilla0.9.1
x86
Windows ME
inputmethod, intl
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
On 02-12 Win32 Mtrunk build and RTM 6.01-ja.

When you try to type some Japanese words including an one bouble byte "kanji", 
there is no underline/highlight appears on this "kanji" in Composer/Editor IME.
I saw it on my WinME-ja machine, and I checked it is reproducible on Win98-ja 
and WinNT-ja too.  

Steps to reproduce:
1. Launch N6 and open Composer.
2. Type some Japanese string including one bouble-byte "kanji", there is a red 
underline under the character.
3. Hit space key.

Expected result:
The candidate character will be highlight and you can hit the space key to 
choose the right "kanji" or some other choices.

Actual result:
There is no highlight/underline appears, and the cursor appears in font of this 
"kanji", looks like it has been converted to a "kanji" that display, and this 
displaying "kanji" actually has not get determined yet.
(Reporter)

Comment 1

17 years ago
reassign to yokoyama.
Assignee: nhotta → yokoyama
Summary: [IME]There is no highlight appreas on an one double-byte(kanji) Japanese candidate in Composer → [IME]There is no highlight appreas on an one double-byte(kanji) Japanese candidate in Composer

Comment 2

17 years ago
Yuying, did you type Japanese "kanji" as hiragana?

I observed this on 2001021204 Mtrunk build, but I could not reproduce it.
I could see the red underline.  
Severity: normal → major
Keywords: intl
QA Contact: teruko → ylong
(Reporter)

Comment 3

17 years ago
The red inderline appears when it still in "hiragana", but after you hit the 
space key, it becomes a "kanji" but not be highlighted.  I can show you tomorrw.
Notice it doesn't happen in one Japanese word that more than one kanji 
character. 

Comment 4

17 years ago
Yuying, could you reproduce on other Windows (Linux or Mac)??
(Reporter)

Comment 5

17 years ago
It can reproduce on WinME-ja, Win98.  A little diffrent on WinNT, but you still 
can't see the candidate not been highlighted and the cursor appreas in front of 
the "kanji".  
It can't reproducible on Mac and Linux cause they have different IME.

Updated

17 years ago
Status: NEW → ASSIGNED

Updated

17 years ago
Target Milestone: --- → mozilla1.0

Comment 6

17 years ago
Roy - Please accept priority P2, and target milestone to M0.9.1

Keywords: nsbeta1
Priority: -- → P2

Updated

17 years ago
Target Milestone: mozilla1.0 → mozilla0.9.1

Comment 7

17 years ago
thanks roy!

Comment 8

17 years ago
Just a note:
shanjian suggests me to take a look at 
struct TextStyle in nsTextFrame. (layout/html/base/src/nsTextFrame.cpp)

Comment 9

17 years ago
It seems if the IME preedit text is one unicode (either it is in katakana, Kanji 
or other text), then we didn't draw the highlight. If the IME preedit text is > 
1 unicode, then it will draw. 

Comment 10

17 years ago
roy and I debug together. It looks like in the nsTextFrame code. The aDetails is 
null in the case the length of per range information is 1. We turn on the debug 
code in editor/base/IMETxn.cpp and it seems we get the information correctly 
there. So the problem really happen in the nsSelection level which we are not 
familiar with. 
mjudge, can you help us looking at this ?

the other way to tigger this is type the following in japanese
jinjinjinjinjin and them hit return
each "jin" will convert to one kanji and each kaji there is part of one range. 
Somehow we draw no ime underline in this case. 

I suspect there are some code like
if( start + 1 < end) {
 //do something
}
somewhere while it really should be
if( start + 1 <= end) {
 //do something
}
or
if( start < end) {
 //do something
}

in the selection code.

Comment 11

17 years ago
mjudge , yokoyama and I debug together. and we find the problem and have a fix. 
the same fix also fix a table dialog problem . mjudge ask me to reassign this 
back to him.
Assignee: yokoyama → mjudge
Status: ASSIGNED → NEW

Comment 12

17 years ago
Created attachment 35211 [details] [diff] [review]
patch

Comment 13

17 years ago
sr=hyatt
(Assignee)

Comment 14

17 years ago
fixed
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 15

17 years ago
Fixed verified on 05-22-06 Win32 trunk build.
Status: RESOLVED → VERIFIED
Keywords: inputmethod
You need to log in before you can comment on or make changes to this bug.