7614 - GTK widget set isn't converting GTK keysyms into Unicode before passing them to the XP event path

Status: VERIFIED FIXED

(Core :: XUL, defect, P3)

Description

[tague]

GTK widget set isn't converting GTK keysyms into Unicode before passing them to
the XP event path.  Instead it it passing the raw gtk key syms (not event
characters) down into the xp-event path.

This is inconsitent with other platforms.

Comment 1

[Peter Trudelle]

I'm not clear where this conversion is supposed to be happening. reassigning to
mcafee for triage, cc'ing saari & pavlov

Comment 2

[tague]

The translation has to happen in the platform-dependent part of the widgets.  In
the case of GTK, the translation needs to occur after the key_press handler has
gotten the GtkKeyEvent but before the call to DispatchWindowEvent in
nsWindow::OnKey.

Comment 3

[Chris McAfee]

Tague says this can get fixed in M8.

Comment 4

[Chris McAfee]

Any unicode input method (e.g. german keyboard input) will not work
until this is fixed.

Comment 5

[don]

Move to M11.

Chris, are you palnning on fixing this or is this something that's better for
Pavlov?

Comment 6

[Erik van der Poel]

The Sun code that I checked in and Pavlov rearranged ought to be converting
key events to Unicode now, though I'm not sure about the keysyms (as opposed to
the characters in the buffer). The Sun guys don't have a Bugzilla account yet,
but we're working on that. In the meantime, this bug is better assigned to
erik or pavlov.

Comment 7

[Chris McAfee]

erik.

Comment 8

[Frank Tang]

Akkana Tague, and Pavlov, is this still an issue ?

Comment 9

[Akkana Peck]

It's not sending raw keysyms; it's sending ascii characters in the char code.
It doesn't try to do any intelligent unicode mapping, just sends the ascii
character.  That's the meaning behind the comment in nsGtkEventHandler.cpp:

  // placeholder for something a little more interesting and correct

If sending ascii is okay when not doing IM, then someone please say so and take
out the comment ...  Pavlov and I were under the impression that it was supposed
to be doing something more with unicode.

Comment 10

[tague]

no sending ascii is never okay, even when not dealing with IME/XIM.  you have to
send Unicode data down, otherwise the text input gets corrupted (even for
English).

See how the key handling operatings on Mac and Windows.

Comment 11

[Frank Tang]

move to M12.  add [e-mail] to the cc list.
We are talking about the char code field or key code field here ?

Comment 12

[Frank Tang]

toshi-san : could you help ?

Comment 13

[Paul MacQuiddy]

giving me rest of phillips open qa contact bugs, sorry for spam

Comment 14

[bobj]

Teruko,
I spoke to ftang.  He thinks this may cause problem for non-ASCII, non-IME
cases.  Will you try using non-ASCII using a non-US (e.g., Fr, De) keyboard
layout and also try using dead-key entry?  Thanks.

Comment 15

[Teruko Kobayashi]

Changed QA Contact to [e-mail].

After I changed French keyboard layout under linux; I tried to type accended
characters "ιθηΰω" in
http://babel/tests/brower/bft/latin_1/bft_browser_form_latin_1.html

When first time you type those characters in the first text field. the
characters are not displayed.
Then, you move to the next text field or third field.  The characters sometimes
are displayed correctly.
The same behavior happens in Location bar and Find field of Find on this page
dialog.  These characters are displayed correctly in Composer.  Dead key does
not work-separate bug 20932
Tested 120608 Linux build.

Comment 16

[bobj]

The symptoms described, no longer match the summary.
If the character are appearing correctly sometimes, then the Unicode conversion
must be working.  Let's create a new bug with the new symptoms and mark this
bug as WORKSFORME.

Comment 17

[Teruko Kobayashi]

What was the original symptoms?

Comment 18

[Frank Tang]

I think one way to solve it quickly is to take the keysym2ucs.c from the xterm
source code http://www.clark.net/pub/dickey/xterm/xterm.tar.gz to fix it. We
need to convert keysym to Unicode for those keysym that XmbLookupString does not
handle because it is out of the scope of locale encoding.

Comment 19

[Frank Tang]

reassign to ftang

Comment 20

[Frank Tang]

fix check in after r=pavlov

Comment 21

[Frank Tang]

I think my fix also fix 20932. Please test that also.

Comment 22

[Teruko Kobayashi]

I verified this in 2000012513 Linux build.