Red Hat Bugzilla – Bug 194537
forwarding keycode 0 causing not working on XIM
Last modified: 2014-06-18 05:08:24 EDT
Problem description: scim-hangul does not work correctly. If preedit string is available and input focus is moved to another window, preedit string is committed. After that, when input focus is moved back to the window, XIM cannot handle first key input. Test instruction is as follows: (It requires Korean locale and Korean fonts) 1. Login with Korean locale 2. Open gnome-terminal 3. Check XMODIFIERS and LANG environment variables $ echo $XMODIFIERS @im=SCIM $ echo $LANG ko_KR.UTF-8 4. Start gtk-demo with XIM $ GTK_IM_MODULE=xim gtk-demo 5. Double click "Application main window" on left-side list. "Application main window" will be displayed 6. Move input focus to text widget 7. Turn on SCIM with Ctrl+Space 5. Type "dlf", Korean character is displayed 6. Click desktop window to move window focus 7. Click "Application main window" window to move back window 8. Type "d", then "d" is displayed <== PROBLEM $ uname -a Linux host207 2.6.16-1.2122_FC5 #1 Sun May 21 15:01:01 EDT 2006 i686 i686 i386 GNU/Linux $ cat /etc/issue Fedora Core release 5 (Bordeaux) Kernel \r on an \m $ cat /etc/fedora-release Fedora Core release 5 (Bordeaux) ==================================================== Our test machine has following RPM packages: gtk2-2.8.17-1.fc5.1 scim-hangul-0.2.2-1.fc5.1 scim-1.4.4-9.2.fc5 scim-libs-1.4.4-9.2.fc5
Pardon me for living, but please explain to me why this bug in scim-*/scim- hangul is filed against 'xorg-x11' and not scim-hangul? You have to scroll past a lot of entries on the web form to get to the "x"'s, and "s" is surely on the way there, no?
correcting component. unsure why there is such a dramatic reaction to a mistake in classification.
Heh no no, that there reaction, above, wasn't dramatic.. that was the ' admirable restraint' reaction. I deleted my post three times before I had it toned down enough to be marginally diplomatic. And the reason behind it is mostly because of wasted time - if you want your bug to get fixed, file it against the component having the problem. If my car breaks down I don't tell Triple-A that I need a new tire when the problem is that the axle fell off. I mean, I'm quite certain you want your time wasted as little as do the rest of us, so likewise when we come to help it's more rewarding for us to be able to get right to it. :-)
------- Additional Comments From mharris@redhat.com 2006-06-12 14:20 EST ------- Right component, but assigned to wrong owner now... Be sure to click "reassign bug to owner and QA contact of selected component" when changing components to ensure the maintainers of the right component get the bug emails, and it shows up in their bug queries. Hope this helps.
Created attachment 131030 [details] LTC24382.patch
----- Additional Comments From shoji@jp.ibm.com 2006-06-16 06:08 EDT ------- 1st proposed patch. Please find the first proposed patch. This is the same IM "commit" issue as LTC bug #24055.
Sorry, is this issue also happened on another IMEs?
------- Additional Comments From takiguc@jp.ibm.com 2006-06-16 11:04 EDT ------- (In reply to comment #14) > Sorry, is this issue also happened on another IMEs? In case of FC5, I saw this problem with scim-hangul IME only. I tried scim-anthy, scim-tables..., these were OK.
how about another IMs? if this issue happens on scim-hangul only, it may be able to be fixed in scim-hangul. even if not, your patch may affects other IMs I'm afraid. I've confirmed that this issue happens on my machine, so I'll let me look into scim-hangul first and will figure this out.
----- Additional Comments From shoji@jp.ibm.com 2006-06-19 01:26 EDT ------- > In case of FC5, I saw this problem with scim-hangul IME only. This comment is fact. But other IMEs just do not return a preediting string when an associated IC unset the focus. The same problem was occured with SCIM-Anthy-0.8. SCIM-Anthy-1.0 stopped to return a preediting string as committed string when IC focus is out. Therefore, the problem was not occured. Please refer AnthyInstance::focus_out() method in src/scim_anthy_imengine.cpp file for both 0.8 and 1.0 releases. In 0.8 code, action_commit() is called to return the preedit string as a committed string. But in 1.0 code, it no longer calls action_commit(). This problem is occured when an IM server try to return a preediting string when the current IC is focus out. Please find the following sequence between SCIM and Client (include Xlib). 1. <Client> User hit some keys for preediting. 2. <Client> User operates to focus out from the client application. 3. <Client Xlib> Unregister all KeyPress/KeyRelease filter. 4. <SCIM> Receive IC focus out. 5. <SCIM> Send the current preediting string to <Client> 6. <Client Xlib> Recieve the preediting string as Commited string (CommitRecv). 7. <Client Xlib> PutBack dummy (fabricated) key press event with keycode=0. The current IC is marked FABRICATED. 8. <Client Xlib> _XimProtoMb/WcLookupString is called and obtain the preediting (commited) string. 9. <Client> User operates to focus in to the client application. 10. <Client> User hit a key (KeyPress event). 11. <Client Xlib> The KeyPress event passed to _XimProtoKeyPressFilter. But the IC is still marked FABRICATED, then the filter returns NOTFILTERED. 12. <Clinet Xlib> The KeyPress event is processed as normal (non IM related) key event, then the client displays alphabet character. The fundamental issue is when we should turne off the FABRICATED flag of the IC, if IC unset the focus. Usually, _XimProtoKeypress/KeyreleaseFilter turns off the FABRICATED flag. It works fine when IC has the focus and those filters are registered. But when unset the IC focus, then those filters are unregistered and no longer called until the IC has the focus again. So, the IC still has FABLICATED flag when the next key press is occured. My idea is that the FABLICATED flag is used for handling committed string. So, the flag must be turned off when the committed string handle is over. The original code calls _XimUnregCommitInfo() when the handling is over. Therefore, I added to turn off the FABLICATED flag in there If you have any other sophisticated solutions, it would be welcome. Regards, Shoji
changed: What |Removed |Added ---------------------------------------------------------------------------- Status|FIXEDAWAITINGTEST |TESTED ------- Additional Comments From takiguc@jp.ibm.com 2006-06-19 01:32 EDT ------- I tested Sugiyama-san's patch on FC5(i386), it worked fine.
ok, reassigning back to libX11.
btw I meant to say, have you tried another IMs (but not IM Engines) other than scim? such as kinput2/skk/uim/nabi/xcin etc etc. you will have to make sure if your patch won't breaks any IMs working. actually XIM specification was little vague and each IMs had a habit. your explanation sounds good though, modifying the low layer code must be carefully applied since this issue isn't necessarly happened on every IMs.
----- Additional Comments From shoji@jp.ibm.com 2006-06-20 19:46 EDT ------- I checked the fix with the following other IMs through XIM protocol. o kinput2 + canna o xcin o Ami o skkinput o uim-anthy I used "xterm" and "gtk-demo" for the test. I checked regualar text input with IM and set/unset IC operation during preediting. All of them works OK. None of them returns "preediting" string when IC unset focus. So, regular text input is a primary checkpoint. Regards,
Patches should be submitted to X.Org upstream at http://bugs.freedesktop.org in the 'xorg' component, so that the proper subsystem maintainers can review and scrutinize them. Once a patch has been accepted by X.Org and committed to CVS, we'll update to the new upstream release. Thanks in advance. Setting status to "NEEDINFO_REPORTER" and awaiting X.Org bug URL for tracking.
Please let us know the upstream X.Org bug report for this issue so we can track the progress occuring with this being accepted into the X.Org codebase. Once it has been reviewed by the upstream maintainers and accepted into the X.Org repository, we will include it in the next Fedora build of the package. Hopefully this can happen prior to the Fedora Core 6 test2 release to ensure maximum test coverage. Thanks in advance.
This looks similar to RH bug 201284, which has been upstream as <http://freedesktop.org/bugzilla/show_bug.cgi?id=7869>.
The above patch does not seem to affect bug 201284 though, so I guess they are separate issues.
Glen, do you know if a bug has been filed yet for this upstream at FreeDesktop bugzilla under libX11?
I confirmed the above patch also fixes the same problem with Japanese input when using scim-anthy.
I reported it upstream at freedesktop now.
Please confirm if the bug is "devel" related because the OS details Glen Johnson got in the first comment was Fedora Core release 5 (Bordeaux).
------- Additional Comments From takiguc@jp.ibm.com 2006-08-29 23:22 EDT ------- (In reply to comment #29) > ----- Additional Comments From cchance@redhat.com 2006-08-29 22:13 EST ------ - > Please confirm if the bug is "devel" related because the OS details Glen Johnson > got in the first comment was Fedora Core release 5 (Bordeaux). This problem is happened on FC5 and FC6 test2.
Please provide URL of submitted bug at upstream which referred.
Caius, it is below in External Bugzilla References.
changed: What |Removed |Added ---------------------------------------------------------------------------- Status|TESTED |SUBMITTED ------- Additional Comments From chavez@us.ibm.com (prefers email at lnx1138@us.ibm.com) 2006-09-05 17:11 EDT ------- https://bugs.freedesktop.org/show_bug.cgi?id=8059 worked for me
I have added the patch now, but to be honest I don't really understand this code, so basically I am trusting that this patch was tested with various input methods and found not to break. Fixed in rawhide, if/when releng moves the new package.