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.
I'm not clear where this conversion is supposed to be happening. reassigning to mcafee for triage, cc'ing saari & pavlov
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.
Tague says this can get fixed in M8.
Any unicode input method (e.g. german keyboard input) will not work until this is fixed.
Move to M11. Chris, are you palnning on fixing this or is this something that's better for Pavlov?
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.
Akkana Tague, and Pavlov, is this still an issue ?
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.
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.
move to M12. add email@example.com to the cc list. We are talking about the char code field or key code field here ?
toshi-san : could you help ?
giving me rest of phillips open qa contact bugs, sorry for spam
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.
Changed QA Contact to firstname.lastname@example.org. 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.
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.
What was the original symptoms?
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.
Assignee: tajima → ftang
Status: ASSIGNED → NEW
Whiteboard: patch need review
reassign to ftang
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
fix check in after r=pavlov
I think my fix also fix 20932. Please test that also.
I verified this in 2000012513 Linux build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.