This is not a problem in IBus, but a problem of how XIM works.
If the handler program of XIM is not responsive (died, suspended, or
just two slow), then the program that it is used to input to will die
without rescue, this is essentially what happened as described
"predictable way to crash other apps".
To avoid such problem, port the application to use any of the IM
Modules, or just start IBus using the recommended way.
** Changed in: ibus (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to ibus in Ubuntu.
https://bugs.launchpad.net/bugs/997620
Title:
predictable way to crash other apps via ibus
Status in “ibus” package in Ubuntu:
Invalid
Bug description:
I can reliably crash third-party apps the following way on an up-to-
date lucid system.
1) start ibus-daemon on the command-line
2) start third-party app
3) toggle input via ibus
4) Ctrl-Z on ibus to put it in the background
All apps using ibus will essentially lock up at this stage. Typing
"bg" to keep ibus running in the background is not possible. You have
to switch to the virtual terminal for that where a "killall -s CONT
ibus-daemon" will allow you to regain control of your X session. But
all apps using ibus at that stage will crash a few seconds later and
have to be restarted.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/997620/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
