30304 - Short-cut keys for copy/paste are not working while IME is turned on.

Status: VERIFIED WONTFIX

(Core :: Internationalization, defect, P3)

Description

[ji]

OS: RH6.0 + Japanese package

While Japanese IME is turned on, short-cut keys for copy/paste (Alt c and Alt 
v) are not working. This is very inconvenient.  We have this function 
working for windows.

Steps of repro:
1. Launch composer in Ja locale
2. Trun on Japanese IME by pressing Shift + space key
3. Enter Japanese chars in the editor.
4. Highligh those JPN chars you enters and press Alt c
   you'll see the highlighted chars are erased,

Comment 1

[Frank Tang]

Is that true the IME will EAT the key up/down event ?

Comment 2

[Hidetoshi Tajima]

Accepted. I'll look into it, but from Monday.

Comment 3

[Hidetoshi Tajima]

Kinput2's problem. It seems that kinput2 does not
check Mod1Mask of input events. Actually, typing
Alt+c on kterm while Japanese conversion is ON
just inserts a character for 'c' into precomposed
window. I also verified Alt+c on Mozilla works fine
using Sun's XIM while japnese conversion is ON.

Comment 4

[Hidetoshi Tajima]

The highlighted chars are erased when you type
Alt+c while conversion is on, because kinput2
returns a plain 'c' instead of Alt+c, and it replaces
the previous selected chars with that 'c'. I don't
think we can fix the problem by modifying Mozilla codes, but kinput2 must be
fixed.

Comment 5

[bobj]

How do we file bugs against kinput2?
This info should be added to the release notes.

Comment 6

[Hidetoshi Tajima]

Bob, this is from README file of kinput2 source,
included in redhat6.1 ja source distribution:

* Bugs

If you find a bug, please send a bug report to [e-mail].
Please don't forget to include the description of your environment (your
machine, OS version, X window patchlevel, etc.) as well as the version
of kinput2 ("kinput2 -version" prints version information).

Comment 7

[ji]

Filed a bug to [e-mail] and will release note this bug.

Comment 8

[ji]

Changed the status to "verified".

Comment 9

[ji]

This is the reply from the engineer working on kinput2. Tajima-san,
please take a look at it and let me know if I need to reopen or file a
seperate bug for it. Thanks.

 don't think it is a kinput2's bug.  kinput2 simply performs
XLookupString() on the Alc+c keypress event, and alas, XLookupString()
returns ASCII character 'c'.  Maybe kinput2 should check Alt modifier
on keypress events and avoid calling XLookupString()..

Anyway, there is a work around.  If you just want kinput2 to send back
Alt+c to the application, add the following line to the definition of
mode "All" in file ccdef.kinput2.

        ""      mod1-c  ""      send-back

The default definition of mode All looks like:

        mode All        "?"
        ### ...
        ### ...
        ### ...
                ""      control-Kanji   ""      end-conversion goto Kana
                ""      shift-space     ""      end-conversion goto Kana
                ... more lines ...
        endmode

Insert the above line anywhere between "mode All" and "endmode".

If this doesn't work for you, please let me know.

                                                -- [e-mail]

Comment 10

[Hidetoshi Tajima]

Teruko-san, please try the workaround solution Ishisone-san mentioned,
and let me know whether it works or not.
If it works, we should write this information in Mozilla release notes.

Comment 11

[ji]

Changed the ccdef.kinput2 file in /usr/X11R6/lib/X11/ccdef as told.
But it didn't actually help. 
1.On kterm window, with IME on, pressing Alt C does't erase the highlited
  chars, but an extra c is inserted, and it dones't get the chars into the 
  buffer because pressing Alt v doesn't get those chars copied.
2. On mozilla's mail compose page, situation doesn't change at all.
   Pressing Alt C still erase the highlited chars.

I'll write Ishisone-san an email about this. At the same time, we may need
to investigate why mozilla doesn't get better as kinput2 does with the 
workaround.