Bug 194537

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  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.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.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.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.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.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.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. 

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.com (prefers email at lnx1138.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.