After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 621659 - Keyboard is broken when using IBus
Keyboard is broken when using IBus
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Dan Winship
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2010-06-15 15:32 UTC by Giovanni Campagna
Modified: 2011-01-13 17:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to make keyboard usable again with IBus (6.63 KB, patch)
2010-07-06 05:45 UTC, Daiki Ueno
none Details | Review
Install a GDK event handler to catch events queued by IBus (5.33 KB, patch)
2010-09-10 22:13 UTC, Owen Taylor
committed Details | Review

Description Giovanni Campagna 2010-06-15 15:32:02 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
Comment 1 Dan Winship 2010-06-18 14:38:08 UTC
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?
Comment 2 Giovanni Campagna 2010-06-20 14:55:09 UTC
Gtk is stock (1.2.10-70.fc13), not built from upstream.

I have tried both Rawcode and no input method at all.
Comment 3 Giovanni Campagna 2010-06-20 14:56:38 UTC
Sorry for Gtk I searched the wrong package, correct version is 2.20.1-1.fc13
Comment 4 Peng Huang 2010-06-23 02:07:42 UTC
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
Comment 5 Peng Huang 2010-06-23 02:48:03 UTC
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.
Comment 6 Daiki Ueno 2010-07-06 05:45:26 UTC
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).
Comment 7 Daiki Ueno 2010-07-14 02:38:50 UTC
I put jhbuildrc to test the bug (& the patch) easily:

http://ueno.fedorapeople.org/gnome-shell-ibus/

See README for the instruction.
Comment 8 Owen Taylor 2010-09-10 22:13:52 UTC
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!
Comment 9 Daiki Ueno 2010-09-13 09:13:45 UTC
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]).
Comment 10 Owen Taylor 2010-09-13 21:27:32 UTC
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
Comment 11 Daiki Ueno 2010-09-14 02:41:16 UTC
(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
'
Comment 12 Owen Taylor 2010-09-14 13:18:36 UTC
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.
Comment 13 Owen Taylor 2010-09-14 20:05:16 UTC
GJS changes: bug 629705
gobject-introspection changes that they depend upon: bug 629704
Comment 14 Owen Taylor 2011-01-13 01:18:01 UTC
OK, GJS changes finally landed. Dan - can you review my patch?
Comment 15 Dan Winship 2011-01-13 15:11:01 UTC
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?
Comment 16 Owen Taylor 2011-01-13 16:58:53 UTC
(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
Comment 17 Owen Taylor 2011-01-13 17:03:06 UTC
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