47568 - kinput2 doesn't work correctly

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P2)

Description

[Koike Kazuhiko]

kinput2 doesn't work correctly.

(1) Turn on kinput2 in text area and type some word.
(2) Hit space bar twice. "Candidate selection" window appears.
(3) Select one of the candidate by mouse.
(4) kinput2 goes crazy. It shows strange behaviour.

This problem was originally reported on Japanized bugzilla.

http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=170

Comment 1

[Hidetoshi Tajima]

Teruko-san, can you confirm if the problem is reproducible or not?

Comment 2

[Teruko Kobayashi]

I can reproduce this in 2000-08-08-08-M18 Linux build.

What I see is following.
1. Open Composer
2. Turn on kinput2
3. Type "kannji" and hit space to show candidate window
4. Select one character by mouse or allow key
   At this time, the characters are still hightlighted.
5. Hit the enter to commit
   The characters are not committed.  At this time, the IME status window is 
[kannji].  It should be back to [hiragana] mode and the characters are 
committed.

I tried this several times after I open the new Composer.
Kinput2 sometimes works fine.  Sometimes it behaves as I mentioned above.

Sometimes it behaves the following.
1. Turn on kinput2
2. Type "kannji" and hit enter to commit the kannji characters
   The characters I typed will disapear.

I tested the different character coding menu, Shift_JIS, Euc-jp, or 
Auto-detect(Japanese).  I did not find the consistancy, yet.  I am testing more.

Comment 3

[Teruko Kobayashi]

I found out the Composer Window was not forcued my previous case2.
 
When the candidate window is open, the Composer Windows foucus will lose.
After I select the character and commit it, it should focus again.  However, 
sometimes it does not focus again.  At that time, if you type some Japanese 
characters, it will disapear.

Comment 4

[Masaki Katakai]

I also meet the problem that composer didn't get an input focus
after candidate window was closed and composer didn't
accept any key input. I found the problem (lose input focus)
happens at first operation after composer is invoked.
When I clicked on composer after the problem, input focus could
be movied to composer even when input focus was moved to
candidate window.

Comment 5

[Teruko Kobayashi]

Nominating this for beta3.

Comment 6

[Frank Tang]

nsbeta3+ per i18n bug meeting

Comment 7

[Frank Tang]

add jfrancis to the cc list.

Comment 8

[Frank Tang]

mark this as P2.

Comment 9

[Frank Tang]

tajima said they have the fix in hand. They are currently do more testing before 
sending out for code review. 

Comment 10

[Hidetoshi Tajima]

A combined patch is posted to the attachment of bugid 47833, waiting for
check-in approval.
marked WORKSFORME.

Comment 11

[Frank Tang]

reopen
tajima- you should mark "FIXED" when you check in the code.
WORKFORME mean it work for  you WITHOUT any changes.

Comment 12

[Hidetoshi Tajima]

checked in the code(r=pavlov,a=waterson).

Comment 13

[Frank Tang]

mark it fixed

Comment 14

[Teruko Kobayashi]

I verified this in 2000-09-11-08 Linux build.

Comment 15

[Koike Kazuhiko]

The problem still remains with Linux 2000091108.

(1) Type "kannji" and hit space bar twice. Candidate selection window appears.
(2) Hit Enter key. "kannji" remains highlighted and any key doesn't accepted.

Is this an another bug?

Comment 16

[Frank Tang]

clear the status line after reopen

Comment 17

[Masaki Katakai]

I've filed new bug against Editor (or Layout),

 http://bugzilla.mozilla.org/show_bug.cgi?id=52416

It seems that Editor does not update the text
when Editor does not have an input focus, which causes
this problem. I'd like to ask Editor people to
evaluate this problem. Thanks.

Comment 18

[selmer (gone)]

pdt agrees w/Frank, nsbeta3-

Comment 19

[Masaki Katakai]

Here is the workaround of sawmill window managers. We can
configure window manager not to allow IME window grabs the
input focus. I recommend this setting on your desktop to
work XIM properly.

1) Start GNOME Control Center
2) Select Sawmill window manager -> Matched Windows
3) Click Add... button
4) Specify your Mozilla's IME status window in Matchers field
        Name=Mozilla IM Status 
        You can use Grab... feature to get name of window.
5) Select "never-focus" on Actions field
6) Click OK

7) Click Add... button again
8) Specify your IME's name in Matchers field

   when you use kinput2, please specify "Kinput2",

        Class=Kinput2 

   when you use ATOK X for Linux, please specify "Kinput2",

        Class=Jp\.co\.justsystem\.atok12\.LookupAux/
		jp\.co\.justsystem\.atok12\.LookupAux

9) Select "never-focus" on Actions field
10) Click OK

I will prepare XIM readme for this setting.

Comment 20

[Linda Baliman]

Adding nsbeta1 keyword.  Setting Priority to P1.

Adding mcarlson to cc-list.

Comment 21

[Linda Baliman]

Lowering priority to P2.  Sun says this is not a show-stopper bug for them.

Comment 22

[Hidetoshi Tajima]

This is blocked by the bugid 52416 and that is targeted for "future".

Comment 23

[Teruko Kobayashi]

Changed QA contact to [e-mail].

Comment 24

[Hidetoshi Tajima]

reassign.

Comment 25

[Jaime Rodriguez, Jr.]

Marking as nsbeta1-

Comment 26

[Cindy Roberts]

Marking nsbranch- as it was decided in the August bug triage that we wouldn't
have enough time in eMojo to fix this.  Let's revisit for MachV.

Comment 27

[elaineking]

removed keyword nsbranch since it now has nsbranch-, per pdt mtg.

Comment 28

[Jaime Rodriguez, Jr.]

nominating ...

Comment 29

[Frank Tang]

the origional bug report in japanese bugzilla said it is fixed. Please open new
bug report if there are other issue. 

Comment 30

[Yuying Long]

Mark as verified per original problem has been fixed.