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

VERIFIED FIXED in M13

Status

()

P3
normal
VERIFIED FIXED
20 years ago
19 years ago

People

(Reporter: tague, Assigned: ftang)

Tracking

Trunk
Other
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: patch need review, URL)

(Reporter)

Description

20 years ago
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.

Updated

20 years ago
Assignee: trudelle → mcafee

Comment 1

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

Updated

20 years ago
Blocks: 7470
(Reporter)

Comment 2

20 years ago
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.

Updated

20 years ago
Target Milestone: M7

Updated

20 years ago
Target Milestone: M7 → M8

Comment 3

20 years ago
Tague says this can get fixed in M8.

Updated

19 years ago
Target Milestone: M8 → M9

Updated

19 years ago
Target Milestone: M9 → M10

Updated

19 years ago
Blocks: 12673

Comment 4

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

Updated

19 years ago
Target Milestone: M10 → M11

Comment 5

19 years ago
Move to M11.

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

Comment 6

19 years ago
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.

Updated

19 years ago
Assignee: mcafee → erik

Comment 7

19 years ago
erik.

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

19 years ago
Assignee: erik → ftang
Status: ASSIGNED → NEW
(Assignee)

Comment 8

19 years ago
Akkana Tague, and Pavlov, is this still an issue ?

Comment 9

19 years ago
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.
(Reporter)

Comment 10

19 years ago
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.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

19 years ago
Target Milestone: M11 → M12
(Assignee)

Comment 11

19 years ago
move to M12.  add tajima@eng.sun.com to the cc list.
We are talking about the char code field or key code field here ?
(Assignee)

Updated

19 years ago
Assignee: ftang → tajima
Status: ASSIGNED → NEW
(Assignee)

Comment 12

19 years ago
toshi-san : could you help ?

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 13

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

Comment 14

19 years ago
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

19 years ago
Changed QA Contact to teruko@netscape.com.

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.

Updated

19 years ago
QA Contact: paulmac → teruko

Updated

19 years ago
Target Milestone: M12 → M13

Comment 16

19 years ago
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

19 years ago
What was the original symptoms?

Updated

19 years ago
OS: Windows NT → Linux
(Assignee)

Comment 18

19 years ago
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)

Updated

19 years ago
Assignee: tajima → ftang
Status: ASSIGNED → NEW
Whiteboard: patch need review
(Assignee)

Comment 19

19 years ago
reassign to ftang
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 20

19 years ago
fix check in after r=pavlov
(Assignee)

Comment 21

19 years ago
I think my fix also fix 20932. Please test that also.

Comment 22

19 years ago
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.