Bug 194537 - forwarding keycode 0 causing not working on XIM
Summary: forwarding keycode 0 causing not working on XIM
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: libX11
Version: rawhide
Hardware: i386
OS: Linux
medium
urgent
Target Milestone: ---
Assignee: Søren Sandmann Pedersen
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: FC6Target
TreeView+ depends on / blocked
 
Reported: 2006-06-08 20:23 UTC by IBM Bug Proxy
Modified: 2014-06-18 09:08 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-09-20 22:16:40 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
LTC24382.patch (1.64 KB, text/plain)
2006-06-16 10:01 UTC, IBM Bug Proxy
no flags Details


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 8059 0 None None None Never

Description IBM Bug Proxy 2006-06-08 20:23:51 UTC
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

Comment 1 Scott R. Godin 2006-06-14 15:49:57 UTC
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?


Comment 2 IBM Bug Proxy 2006-06-14 16:04:37 UTC
correcting component. unsure why there is such a dramatic reaction to a mistake
in classification.

Comment 3 Scott R. Godin 2006-06-14 16:28:39 UTC
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. :-) 


Comment 4 Jong Bae KO 2006-06-15 08:10:22 UTC
------- Additional Comments From mharris  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.


Comment 5 IBM Bug Proxy 2006-06-16 10:01:44 UTC
Created attachment 131030 [details]
LTC24382.patch

Comment 6 IBM Bug Proxy 2006-06-16 10:02:09 UTC
----- Additional Comments From shoji.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. 

Comment 7 Akira TAGOH 2006-06-16 13:03:51 UTC
Sorry, is this issue also happened on another IMEs?

Comment 8 IBM Bug Proxy 2006-06-16 15:02:10 UTC
------- Additional Comments From takiguc.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. 

Comment 9 Akira TAGOH 2006-06-16 16:57:22 UTC
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.

Comment 10 IBM Bug Proxy 2006-06-19 05:22:28 UTC
----- Additional Comments From shoji.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 

Comment 11 IBM Bug Proxy 2006-06-19 05:27:04 UTC
changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|FIXEDAWAITINGTEST           |TESTED




------- Additional Comments From takiguc.com  2006-06-19 01:32 EDT -------
I tested Sugiyama-san's patch on FC5(i386), it worked fine. 

Comment 12 Akira TAGOH 2006-06-19 06:29:39 UTC
ok, reassigning back to libX11.

Comment 13 Akira TAGOH 2006-06-19 06:44:47 UTC
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.


Comment 14 IBM Bug Proxy 2006-06-20 23:42:02 UTC
----- Additional Comments From shoji.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, 

Comment 15 Mike A. Harris 2006-07-11 14:58:13 UTC
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.


Comment 16 Mike A. Harris 2006-07-19 09:21:23 UTC
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.

Comment 17 Jens Petersen 2006-08-28 12:21:01 UTC
This looks similar to RH bug 201284, which has been upstream as
<http://freedesktop.org/bugzilla/show_bug.cgi?id=7869>.

Comment 18 Jens Petersen 2006-08-29 02:45:25 UTC
The above patch does not seem to affect bug 201284 though,
so I guess they are separate issues.

Comment 19 Jens Petersen 2006-08-29 02:47:22 UTC
Glen, do you know if a bug has been filed yet for this upstream
at FreeDesktop bugzilla under libX11?

Comment 20 Jens Petersen 2006-08-29 03:34:38 UTC
I confirmed the above patch also fixes the same problem with
Japanese input when using scim-anthy.

Comment 21 Jens Petersen 2006-08-29 12:49:07 UTC
I reported it upstream at freedesktop now.

Comment 22 Caius Chance 2006-08-30 02:13:08 UTC
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).

Comment 23 IBM Bug Proxy 2006-08-30 03:25:59 UTC
------- Additional Comments From takiguc.com  2006-08-29 23:22 EDT -------
(In reply to comment #29)
> ----- Additional Comments From cchance  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. 

Comment 24 Caius Chance 2006-09-05 03:47:27 UTC
Please provide URL of submitted bug at upstream which referred.

Comment 25 Jens Petersen 2006-09-05 07:51:51 UTC
Caius, it is below in External Bugzilla References.

Comment 26 IBM Bug Proxy 2006-09-05 21:16:08 UTC
changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|TESTED                      |SUBMITTED




------- Additional Comments From chavez.com (prefers email at lnx1138.com)  2006-09-05 17:11 EDT -------
https://bugs.freedesktop.org/show_bug.cgi?id=8059 worked for me 

Comment 27 Søren Sandmann Pedersen 2006-09-20 22:16:40 UTC
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.



Note You need to log in before you can comment on or make changes to this bug.