GNOME Bugzilla – Bug 621659
Keyboard is broken when using IBus
Last modified: 2011-01-13 17:03:09 UTC
When using IBus as the input method, keyboard is completely unusable inside the Gnome Shell. In fact, character emitting keys are completely ignored, both in Run Dialog and in the Overview. This happens whatever the setting for IBus are, and even if you restart IBus or the Shell. Still, other keys like Super, Esc or Alt are correctly handled (that is, you can bring up the run dialog, but you cannot type anything inside it). A possible workaround is to switch to XCompose, which works as expected. Shell version: master/HEAD IBus version: 1.3.5-2.fc12
hm... i tried turning on ibus and everything still worked; i could even use the rawcode input method from inside the overview search entry What configuration do you have? And what gtk version?
Gtk is stock (1.2.10-70.fc13), not built from upstream. I have tried both Rawcode and no input method at all.
Sorry for Gtk I searched the wrong package, correct version is 2.20.1-1.fc13
Description of problem: Can not type anything in gnome-shell Version-Release number of selected component (if applicable): gnome-shell-2.31.2-2.fc14.i686 gtk2-2.21.2-1.fc14.i686 gtk3-2.90.2-2.fc14.i686 ibus-1.3.5-1.fc14.i686 How reproducible: always Steps to Reproduce: 1. im-chooser to enable ibus 2. move cursor to left top corner 3. type something in the find entry Actual results: Can not type anything Expected results: Additional info: For some reason, ibus have to processes keypress events in async mode. So gtk_im_context_filter_keypress always returns FALSE. and if ibus need ignore some keyevents, ibus im context will use gdk_event_put to forward the event back to the client window (the window is from gtk_im_context_set_client_window). https://bugzilla.redhat.com/show_bug.cgi?id=603576
I read code and found the client window is from gdk_window_foreign_new_for_display. and seems the clutter does not process events in gdk event queue.
Created attachment 165325 [details] [review] patch to make keyboard usable again with IBus This is quite annoying since even 'lg' is not usable if IBus is enabled :) I'm attaching a patch (to gnome-shell).
I put jhbuildrc to test the bug (& the patch) easily: http://ueno.fedorapeople.org/gnome-shell-ibus/ See README for the instruction.
Created attachment 169995 [details] [review] Install a GDK event handler to catch events queued by IBus Hmm, using gdk_event_put() is messy. There are some potential problems that might occur from that. But here's a patch that handles events from gdk_event_put() in what I think is a better way. I don't have a copy of recent IBUs around to test with, and I can't trigger the problem with IBus from Fedora 13, so testing would be appreciated. Thanks!
I tried your patch and confirmed that it basically works. However, There is a critical typo (the condition is opposite): + ClutterEvent *event_clutter = clutter_event_new ((event_gdk->type == GDK_KEY_RELEASE) ? + CLUTTER_KEY_PRESS : CLUTTER_KEY_RELEASE); I get the following error on key release. Window manager warning: Log level 128: 9 modifier_state = 42000000 JS ERROR: !!! Exception was: Error: value is out of range for Argument 'mask' (type guint64) Currently return value of shell_get_event_state() is ClutterModifierType, which is signed and can be a negative value. On js/ui/main.js:330, gnome-shell passes it to mutter's get_keybinding_action() as gulong. gjs treats it as a type error. This is addressed in my patch (changes to shell-global.[ch]).
Sorry about the press/release reversal. > I get the following error on key release. > > Window manager warning: Log level 128: 9 modifier_state = 42000000 > JS ERROR: !!! Exception was: Error: value is out of range for Argument > 'mask' (type guint64) > > Currently return value of shell_get_event_state() is ClutterModifierType, which > is signed and can be a negative value. On js/ui/main.js:330, gnome-shell > passes it to mutter's get_keybinding_action() as gulong. gjs treats it as a > type error. ClutterModifierType shell_get_event_state (ClutterEvent *event) { ClutterModifierType state = clutter_event_get_state (event); return state & CLUTTER_MODIFIER_MASK; } CLUTTER_MODIFIER_MASK = 0x5c001fff Isn't state & 0x5c001fff always a positive 32-bit integer? When exactly does: JS ERROR: !!! Exception was: Error: value is out of range for Argument 'mask' (type guint64) occur? Can you give the whole traceback
(In reply to comment #10) > ClutterModifierType > shell_get_event_state (ClutterEvent *event) > { > ClutterModifierType state = clutter_event_get_state (event); > return state & CLUTTER_MODIFIER_MASK; > } > > CLUTTER_MODIFIER_MASK = 0x5c001fff > > Isn't state & 0x5c001fff always a positive 32-bit integer? Hrm, perhaps this might be a bug of gjs: gjs> const Clutter = imports.gi.Clutter gjs> Clutter.ModifierType.RELEASE_MASK -1073741824 gjs> Clutter.ModifierType.MODIFIER_MASK -603971585 After quick look at SpiderMonkey, it treats 31bit integer values specially: INT_TO_JSVAL: ((jsval)(i) << 1) | JSVAL_INT JSVAL_TO_INT: (jsint) v >> 1 and there seems to be a missing JSVAL_TO_INT call somewhere. > When exactly does: > > JS ERROR: !!! Exception was: Error: value is out of range for Argument > 'mask' (type guint64) > > occur? Can you give the whole traceback FWIW, here it is: JS ERROR: !!! Exception was: Error: value is out of range for Argument 'mask' (type guint64) JS ERROR: !!! lineNumber = '0' JS ERROR: !!! fileName = 'gjs_throw' JS ERROR: !!! message = 'value is out of range for Argument 'mask' (type guint64)' JS ERROR: !!! stack = 'Error("value is out of range for Argument 'mask' (type guint64)")@:0 ("value is out of range for Argument 'mask' (type guint64)")@gjs_throw:0 @:0 _globalKeyPressHandler([object _private_Clutter_Stage],[object _private_Clutter_Event])@/home/ueno/gnome-shell/install/share/gnome-shell/js/ui/main.js:330 Error("Chained exception")@:0 ("Chained exception")@gjs_throw:0 '
Ah, problem here is that the range of a JS int is -0x40000000 - 0x3fffffff And anything outside of that range has to be represented as a more general number JSVAL_TO_INT is begin used on values outside that range in the enum handling in gjs. Will work on a patch.
GJS changes: bug 629705 gobject-introspection changes that they depend upon: bug 629704
OK, GJS changes finally landed. Dan - can you review my patch?
Comment on attachment 169995 [details] [review] Install a GDK event handler to catch events queued by IBus assuming it works, it looks good. >+ * There are a number of potential problems here; probably the worst >+ * problem is that IBus doesn't forward the timestamp with the event >+ * so that every key event that gets delivered ends up with >+ * GDK_CURRENT_TIME. did you file an ibus bug about this?
(In reply to comment #15) > (From update of attachment 169995 [details] [review]) > assuming it works, it looks good. > > >+ * There are a number of potential problems here; probably the worst > >+ * problem is that IBus doesn't forward the timestamp with the event > >+ * so that every key event that gets delivered ends up with > >+ * GDK_CURRENT_TIME. > > did you file an ibus bug about this? Don't remember doing so - filed one now as http://code.google.com/p/ibus/issues/detail?id=1184
Not easily able to test with IBus on this system, but it worked earlier for me and Daiki Ueno so I'll assume it still does. (I've tested it doens't break keyboard handling withought ibus running.) Pushed with the ibus issue reference added to the comment. Attachment 169995 [details] pushed as 870be02 - Install a GDK event handler to catch events queued by IBus