GNOME Bugzilla – Bug 108424
XIM won't work after input Backspace/Del on candidate window
Last modified: 2011-02-04 16:12:02 UTC
When I input some Japanese and the candidate window of kinput2 is shown, XIM won't work after push Backspace key or Delete key. status window is missing. and even if Ctrl+space is pressed, a space is just inputed. XIM isn't responded. When I change the input method to default for example, then revert it again, this phenomenon may often recovers.
Isn't it old metacity's bug 95454? Otherwise, with what applications does this problem happen? Does this happen with the latest gtk+ on the CVS HEAD? I once saw a similar problem on mozilla composer with the version of metacity older than 2.4.3. But the recent version seems to be okay. I'm using 2.5.0.
No, it's not related metacity. I don't mean the focus issue. basically when Backspace/Del key is pressed, the candidate window is closed and should be waiting the input again on the preedit line. but actually the preedit line is closed, then I won't type any Japanese. It's GTK+2 specific problem. I don't see this on GTK+1.2 and other X applications. I don't try HEAD stuff yet, though.
I can confirm this bug as well. It seems to happen with all GTK2 apps (using 2.2.1 here on gentoo) xchat, gedit, gnome-terminal, gvim(gtk2) all show the problem in exactly the same way. If you press backspace while the candidate window is showing, the window disappears, and all that is left is the pre-edit string. But as soon as you try to type, the pre-edit string disappears and shift-space no longer works. For me, I seem to have to restart each application every time. Not sure if it happens with other non-jap XIM's.
Some additional info. After trying serveral other XIM servers, the only that seems to be affected is the kinput2 + canna combination (though I did not try kinput2 + wnn) I also tried skkinput and atokx, which appear to not have the same problems The interaction model of skk is quite different than kinput2, which may explain the difference, but atokx is essentially the same.
Actual problem is, when the candidate window appears, the focus is obviously changed so that GTK+ handles XIM with OnTheSpot now. and the candidate is candelled by BS/Del key, kinput2 (I use) is going to update the status window. but it's failed - I guess it's also another focus issue? I don't know - , and kinput2 continues had XIM_ERROR as BadProtocol. When the applications rather than the candidate window actually has the focus, then press BS/Del key, the input via XIM works fine. probably we can fix this problem on kinput2, but GTK+ 1.2 should also works with OnTheSpot. I'd say it's probably GTK+ 2 bug.
Perhaps when the callback for status window and preedit is used, it may be spec that XIM server doesn't have to get a focus, though.
Since I had some trouble reproducing, here are exact instructions using: kinput2-canna-wnn6-v3.1-4 Canna-3.6-12 (Red Hat 9 versions) Logged in in en_US.UTF-8 * Run kinput2 and testgtk LANG=ja_JP.eucJP kinput2 -canna & LANG=ja_JP.eucJP XMODIFIERS=@im=kinput2 testgtk * Open the entry test, clear the contents of the first entry (backspace) * Enter <shift><space> nichi <space> <space> to bring up the candidate selection window. * Hit Backspace to cancel the candidate selection window * Hit the left arrow key. At this point, the IM connection is broken and input cannot be restarted. However, I see no reason to think this is a GTK+ bug; it hasn't been reproduced with other input methods, and other usres of kinput2 (like GTK+-1.2) typically use OverTheSpot rather than OnTheSpot. I think it just needs to be debugged what is going on in kinput2. Leaving this open for the moment, even though I rather doubt it's a GTK+ bug.
I'm closing this as NOTAGNOME. the scenario is here: Well, sets the X resource to prevent this problem like the below. *SeparateConversion.input: false *selectionShell.input: false *auxShell.input: false By that, this problem doesn't appear. It looks like kinput2 doesn't have the codes to validate the callbacks. when the candidate window is opened and has a focus, then press the backspace key, kinput2 is going to update the status window. but the window focus isn't returned to the original window. so it's failed, then get a BadProtocol error. So I think nothing is what gtk+ can do for this problem at this point.