iBus blocks input in Java application

Bug #481656 reported by Piranha
244
This bug affects 52 people
Affects Status Importance Assigned to Milestone
Iced Tea
Confirmed
Medium
ibus
Unknown
Unknown
ibus (Ubuntu)
Invalid
Undecided
Unassigned
Nominated for Karmic by Funto
Nominated for Lucid by aalhadsaraf
icedtea-java7 (Ubuntu)
Invalid
Undecided
Unassigned
Nominated for Karmic by Funto
Nominated for Lucid by aalhadsaraf

Bug Description

Binary package hint: ibus

This is a very unfortunate bug, as it is hard to reproduce :(.

I use ThinkingRock, a Java application, and after some time the keyboard input stops working for this application, meaning I can still use my mouse to manipulate the program, but I cannot type anything. When closing the iBus Daemon the input works again after some seconds. Also restarting the Java application helps to postpone the problem until it occurs again some minutes later.

I'm using Ubuntu 9.10 with version 1.2.0.20090927-2ubuntu2 of iBus and version 2.2.1 of ThinkingRock. My Java version is 6-15-1.

Please notice: I do NOT want to input Chinese or Japanese or anything like it. I just want to normally use my keyboard. I also have NO input method selected, I have the input methods turned OFF.

I have yet to test this behavior with other Java applications (maybe it's a bug in ThinkingRock?), so I'd be happy if somebody can confirm this bug for other Java applications. Because the solution is to quit the iBus Daemon, I suspect iBus to be the problem.

Piranha (beni-urgent)
description: updated
Revision history for this message
In , Niklas-laxstrom+icedtea (niklas-laxstrom+icedtea) wrote :

I'm assuming this is related to ibus. Occasionally JOSM stops accepting any keyboard input when ibus is running (I had the same problem with some kde apps before installing ibus-tq). If I restart ibus daemon, JOSM crashes if I try to type anything into it.

64-bit Fedora 12, I'll attached the log.

Revision history for this message
In , Niklas-laxstrom+icedtea (niklas-laxstrom+icedtea) wrote :

Created attachment 273
Crash log

Revision history for this message
Felix Kaminsky (felixkaminsky) wrote :

I can reproduce the bug using freemind version 0.9 RC 6.

Pretty ugly when editing a mindmap.

Revision history for this message
Felix Kaminsky (felixkaminsky) wrote :

@ Piranha: thx killing ibus seems to work for the time being.

@ maintainers: The "pretty ugly" wasn't meant in an offensive way. But I consider it serious productivity bug.

Revision history for this message
Rolf Leggewie (r0lf) wrote :

How long does it take until you can't type anymore? FWIW, works fine for me so far. I can even type Japanese in freemind.

Revision history for this message
Piranha (beni-urgent) wrote :

Can take several hours. I don't know if it has any connection with how long you focus the window or type in an application.

Also remember: It does not seem to have anything to do with actually using various input methods. Just typing normally with no input methods activated results in this bug. Typing Japanese works perfectly, but that's not the problem.

Revision history for this message
Funto (funto66) wrote :

Got exactly the same problem, with FreeMind as well as its fork FreePlane (Java programs).
This problem also happens when using a Qt program, namely Qt Creator in my case, though the problem generally comes after I type "Ctrl+F" (find and replace). This also can also happen in temporary windows Qt Creator creates.
Example : I hit "New class", then a dialog box appears, the keyboard does not work anymore, then I close this dialog box, reopen it and then it works.

I have had these problems since I configured IBus for being able to type in Japanese, but as Piranha says, it does not seem to have anything to do with using various input methods, as input methods are turned OFF when the bug appears.

Hope this will be corrected before next version of Ubuntu...

Revision history for this message
HonestMistake (dj-ubntl) wrote :

Just wanted to add a "me too": It happens always when I work with JOSM, a Java program for editing OpenStreetMap data.
After some time I can't type any text into the dialog boxes anymore. I can't identify a trigger for this error, sometimes it occurs after 1 minute, sometimes it works for half an hour.

As in the other cases described before, the problem occurs while I have turned off Anthy and use standard input only.

After the error occurs I quit ibus, and after about 3 seconds text input works fine again.

Revision history for this message
In , Jon-vanalten (jon-vanalten) wrote :

Do I understand correctly that the app crashes only on ibus daemon restart?

You are probably right about this being an ibus issue. This might be related:
http://code.google.com/p/ibus/issues/detail?id=593

With a fix posted late Nov/09 and ibus making fairly frequent releases, there's a good chance that this fix has made it into F12 by now. Is this still happening for you?

Revision history for this message
larmahunter (charrah) wrote :

This bug affects all my Java programs that use Slick, a game library, for input. On the Slick forums they say it's the same thing even with SCIM, so perhaps there is some underlying problem with how input methods are handled. Lately I haven't even been able to end the iBus process, but that's probably unrelated.

Revision history for this message
larmahunter (charrah) wrote :

Further details for myself... In Slick programs the input doesn't work from the beginning. Turning off iBus while the program is running freezes it to the point where the JVM can't terminate it. Running them while iBus is not makes input work perfectly.

Revision history for this message
Peng Huang (shawn-p-huang) wrote :

Please try the latest ibus from my personal ppa. For some detail information, please read http://code.google.com/p/ibus/wiki/ReadMe

Revision history for this message
larmahunter (charrah) wrote :

Thanks Peng, using your PPA actually fixes this completely! I was a bit surprised, cause I had thought that it was an underlying problem somewhere else.

Revision history for this message
In , Omajid (omajid) wrote :

The crash-on-ibus-restart bug has been fixed upstream:
http://hg.openjdk.java.net/jdk7/swing/jdk/rev/bbadb9484f53

Revision history for this message
Dan Quade (danquade) wrote :

Minecraft is another good example where input does not work.
http://www.minecraft.net/play.jsp

Revision history for this message
Dan Quade (danquade) wrote :

Also, Peng's PPA is pretty useless now since there are no Maverick builds.

Revision history for this message
larmahunter (charrah) wrote :

Yeah I neglected to mention that it worked one time by coincidence then never again, so that's alright.

Revision history for this message
dreamon (dreamon) wrote :

I have the same problem in Netbeans and a vocabulary programme called JMemorize. It seems to be triggered when a dialogue box is opened, such as the box to search for text when you press CTRL + F. Hope this info helps somehow.

Revision history for this message
Piranha (beni-urgent) wrote :

I can confirm this. In my Java applications the bug usually occurred when a dialog box was opened. I didn't realize that first, but now that dreamon mentioned it, I remembered.

Revision history for this message
Dan Quade (danquade) wrote :

So Peng made the Maverick builds recently. I've tried them (from both his PPAs) and still no luck. Looks like we are stuck with this problem forever, because I doubt anyone will bother to fix it for so few people.

Revision history for this message
Dan Quade (danquade) wrote :
Revision history for this message
dreamon (dreamon) wrote :

In my experience Java programmes also crash very often when iBus is enabled, potentially causing severe data loss. There seems to be a certain incompatibility between iBus and Java -- both Sun Java and OpenJDK. Hope the Peng can look into this.

@unimatrix: This workaround only terminates the iBus daemon when a Java application is launched, doesn't it? We still have the problem of not being able to work with iBus in Java applications, e.g. when you need to enter text in a language that requires an input method framework.

Revision history for this message
Dan Quade (danquade) wrote :

@dreamon: Correct. That is why it is called a -workaround-, not a fix.

Revision history for this message
Dan Quade (danquade) wrote :

Another piece of information. I believe this bug only appears on 64-bit systems. Can somebody confirm or deny this?

Revision history for this message
dreamon (dreamon) wrote :

@unimatrix: Unfortunately this is not confined to 64-bit systems. I get this bug on two different 32-bit systems.

Revision history for this message
John Hu(Hsun-Cheng Hu) (huchengtw) wrote :

I met the same problem with 64bits maverick and 64bits Java from Oracle. The app I use is ArgoUML.

Revision history for this message
Sergei Medvedev (smedvedeff) wrote :

I have the same problem with OmegaT 2.2.3 on Ubuntu 10.04.

Revision history for this message
wanding zhou (zhouwanding) wrote :

same problem with using Cytoscape and Freeplane on ubuntu 10.04

Revision history for this message
Cale Gibbard (cgibbard) wrote :

I have the same problem with all Java apps not accepting keyboard input, particularly minecraft. Perhaps similarly, keyboard input in flash applications on the web is also flaky/broken for me when the ibus daemon is running (noticed this with UStream chat and many games).

This problem started on upgrading to Ubuntu 10.10 and didn't exist in 10.04 for me.

Revision history for this message
Michael Speth (conzar) wrote :

I also have this problem with most java applications specifically JMonkeyEngine related Apps.

Changed in ibus (Ubuntu):
status: New → Confirmed
Revision history for this message
In , Andrew John Hughes (ahughes) wrote :

Does this patch need backporting?

Revision history for this message
Qianqian Fang (fangq) wrote :

Having this problem on matlab GUI (written in Java) for years, see a few similar reports at ibus' bug tracker

http://code.google.com/p/ibus/issues/detail?id=419

appreciated if someone can look into a fix.

Revision history for this message
PowerKiKi (adrien-crivelli) wrote :

Same problem on a fresh Ubuntu 11.10 using gnome 2 and ibus. I meant to use ibus to type Korean but didn't get to set it up yet, so there is no input methode selected. When I have ibus daemon running Netbeans "loses" the keyboard. As soon as I quit ibus (right-click on the top-right icon -> quit), Netbeans "find" the keyboard back, without even restarting.

Revision history for this message
Marius B. Kotsbak (mariusko) wrote :

Strange. I had these symptoms without having the "ibus" package installed.

Revision history for this message
Marius B. Kotsbak (mariusko) wrote :

See also similar bug #925653.

Changed in icedtea:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
nomnex (nomnex) wrote :

If it provides any help, or information, you can read my bug report and the workaround: https://bugzilla.redhat.com/show_bug.cgi?id=800736. In my case, removing the ibus icon from the panel prevents losing keyboard input in Freemind.

Revision history for this message
nomnex (nomnex) wrote :

forget my previous comment. After a few hours respite, I lose keyboard input in the Freemind window...

Revision history for this message
xeo (thomas-pototschnig) wrote :

I'm using ibus on Kubuntu 11.10 (64Bit) and I also can reproduce this behaviour. In my case, everytime I pressed CTRL+F in the eclipse IDE the keyboard stopped working for this application. Sometimes kate didn't allow keyboard-input in a file open or file save dialogue.

The "XMODIFIERS=" workaround works fine.

Revision history for this message
Marius B. Kotsbak (mariusko) wrote :

Has anyone seen this bug in Ubuntu Precise (12.04) or newer? It is supposed to be fixed in upstream java.

Changed in icedtea-java7 (Ubuntu):
status: New → Incomplete
Changed in ibus (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Jorge Gustavo (jgr) wrote :

When I change to ibus, to write chinese characters, the JOSM (JAVA OpenStreetMap) editor does not let me introduce accented characters like 'Rua Cristóvão Colombo'. I can only write non-accented characters. If I disable ibus, I can write accented characters in JAVA applications.

Revision history for this message
Tobias (tobias-olsson) wrote :

I can confirm this for sun java 1.6.0_43-b01. I have to keep hammering keys and it's not easy to reproduce except when I least want it.

Killing ibus doesn't help, because the problem persist as long as ibus is running (it starts itself up again). Running the following simple script lets me type in the application again.

If the java application is closed and started again, the application accepts keyevents until at a random time it stops again.

I've debugged the application (it's my own app) and I can see no Events being handled for keys, so either it's lowlevel, or it's in ibus.

Running 12.10, but please note that I'm running HotSpot JVM, ie Oracle's binary distribution of java that isn't really modern when it comes to X11. If someone cares about this bug enough to investigate, I can try it on icedtea as well.

Revision history for this message
Tobias (tobias-olsson) wrote :

script was
while true; do killall ibus-daemon; done

Revision history for this message
Marius B. Kotsbak (mariusko) wrote :

Tobias, Sun/Oracle Java is no longer included in Ubuntu (but you could try the latest version, or 1.7.x). Please use OpenJDK instead, and reopen this bug report if you can reproduce it there.

Changed in ibus (Ubuntu):
status: Incomplete → Invalid
Changed in icedtea-java7 (Ubuntu):
status: Incomplete → Invalid
Revision history for this message
Eero Aaltonen (ejn) wrote :

Keyboard input stops working on java applications in Ubuntu 13.10.
$ java -version
java version "1.7.0_51"

So to confirm this I need to kill ibus?

Revision history for this message
tbys (tbys) wrote :

I am still seeing this problem in 14.04, or at least a problem which is very similar. I've had this problem for several years now using the Rubymine IDE (which is built on Java). I used to be able to restart ibus from the notification panel icon, but apparently that option has been removed :/ But fortunately ibus can be restarted from the command line now with "ibus restart".

Revision history for this message
Andrei (andrei-doom) wrote :

This has been first reported back in 2009 ? This issue is gunning down productivity, especially when it happens multiple times a day and you're telling me that half a decade later this still hasn't been fixed ? That's just inconceivable. And don't you start lecturing me as how open source works, etc. etc. etc. This is unacceptable, regardless of what type of software type, PERIOD. I bet if I come back here in another half decade, this is still unresolved... this is what happens when people just don't give a damn about their product anymore. Get your shit together man...

Revision history for this message
Karel Vervaeke (karel-vervaeke) wrote :

I'm also affected by this on 14.04 with IDEA's IntelliJ. I used to see it on older releases as well.
"ibus restart" helps to kick things back into cooperation.
It's hard to reproduce; I would say it happens about 5 times per week on average, but on a bad day I can get it several times in a matter of an hour or so.

Keyboard input never gets lost halfway typing something, but always right after a bit of window/desktop switching. I always switch windows/desktops using keyboard shortcuts (alt-tab for windows, ctrl-alt-j/k for desktops). During those I often hit Alt or Super by accident, opening the HUD or the launcher respectively. I have a strong feeling, but am not 100% certain that those are involved as well.

Revision history for this message
Tavis Elliott (tavise) wrote :

Also also affected on 14.04 with IntelliJ. I recently switched to Ubuntu from Linux Mint 14 on which never had this problem (probably because ibus isn't used there)

Killing ibus resolves the problem. (Will try XMODIFIERS= on next system restart)

Revision history for this message
Tanel Tammik (keevitaja) wrote :

I can reproduce this with PhpStorm 8.0.1 with following:

I keep switching open files with Ctrl + Tab very quickly and sometimes after 5 switches, sometimes 10 or so, keyboard freezes.

ibus restart releases the keyboard!

➜ bin java -version
Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar
java version "1.7.0_65"
OpenJDK Runtime Environment (IcedTea 2.5.2) (7u65-2.5.2-3~14.04ppa1)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)

Revision history for this message
José L. Domingo López (ubuntu-24x7linux) wrote :
Revision history for this message
José L. Domingo López (ubuntu-24x7linux) wrote :

Being hit by this one for a long time now, when using JOSM (all released stable JARs for a couple year now, if not more). Of course, while using Java version 7, which is the only release JOSM is "qualified" to run with:
"""
$ java -version
java version "1.7.0_72"
Java(TM) SE Runtime Environment (build 1.7.0_72-b14)
Java HotSpot(TM) Server VM (build 24.72-b04, mixed mode)
"""

I just arrived in this bug now, and tried the recommended "ibus restart" to get text input working again, but after a few seconds with input working again, the Java application died miserably. Just a few major highlight from the generated report, which I have just attached (hs_err_pid29918.log):
"""
Current thread (0x2760c000): JavaThread "AWT-EventQueue-0" [_thread_in_native, id=29948, stack(0x27b29000,0x27b7a000)]

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=2 (SEGV_ACCERR), si_addr=0x269bce28

Stack: [0x27b29000,0x27b7a000], sp=0x27b7841c, free space=317k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C 0x269bce28
j sun.awt.X11.XInputMethod.setXICFocusNative(JZZ)V+0
j sun.awt.X11.XInputMethod.setXICFocus(Ljava/awt/peer/ComponentPeer;ZZ)V+25
j sun.awt.X11InputMethod.activate()V+162
j sun.awt.im.InputContext.activateInputMethod(Z)V+169
j sun.awt.im.InputContext.focusGained(Ljava/awt/Component;)V+137
...
"""

Even if this is not entirely related to supported Ubuntu packages (there seems to be something related to Java 7 and Java applications), the fact is it seems "ibus" has some saying about it, and other Linux distros seem to be free from this significant nuisance. Considering this has been documented and reported for nearly six years now, if feels disappointing to see such a hot bug being disregarded for that long. I am not using the greatest and latest Ububtu, but I can't see it fixed in any later release either:
"""
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="14.10 (Utopic Unicorn)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.10"
VERSION_ID="14.10"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
"""

I don't know if this is related or not, but also at times with JOSM I experience the inability to enter Spanish characters instead of losing input completely to the application. As ibus seems to deal with "entering foreign characters", I suspect it may be the culprit for both problems.

Anyways, let's see if this gets addressed at some point in the very immediate future.

Thank you.

Revision history for this message
José L. Domingo López (ubuntu-24x7linux) wrote :

I 've spent a good few additional hours editing OSM data with the Java-based JOSM application, and since I started running the application by setting "XMODIFIERS=" for iBus I have no longer experienced any problem with text entry: neither failure to get any input text, nor the inability to enter special characters for Spanish.

So that _may_ look like a valid workaround, however, it's just based on my own experience for a limited time, and your mileage may vary.

information type: Public → Public Security
information type: Public Security → Public
Revision history for this message
Bhuvan Krishna (swecha) wrote :

I guess it is still not fixed. I tested with ubuntu 14.04 LTS updated on freemind 0.9. I am trying to type telugu text which is an indic text. I don't see the text if I try to type in freemind but if i copy text from another application like gedit or kate it shows the text. I think the bug still exists.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.