Bug 137398 - [iiimgcf] general event handling - gtk_im_context_reset()
Summary: [iiimgcf] general event handling - gtk_im_context_reset()
Alias: None
Product: Fedora
Classification: Fedora
Component: openoffice.org
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Dan Williams
QA Contact:
: 144557 (view as bug list)
Depends On:
Blocks: IIIMF
TreeView+ depends on / blocked
Reported: 2004-10-28 03:50 UTC by Lawrence Lim
Modified: 2014-03-26 00:51 UTC (History)
3 users (show)

Fixed In Version: RHBA-2005-296
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-04-26 06:59:00 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:296 normal SHIPPED_LIVE iiimf bug fix update 2005-06-09 04:00:00 UTC

Description Lawrence Lim 2004-10-28 03:50:05 UTC
Description of problem:
Creating a general bug which records the event handling issue for
OpenOffice.org with IIIMF.

Version-Release number of selected component (if applicable):

How reproducible:

chinput (zh_CN)
Steps to Reproduce:
1.toggle on (ctrl-space)
2.enter 'hong' (do not commit)
3.toggle off (ctrl-space)
4.toggle on (ctrl-space)
5.enter 'h'
Actual results:
Preedit buffer shows 'hong h'

Expected results:
Preedit buffer shows 'h'

xcin (zh_TW)
Steps to Reproduce:
1.toggle on (ctrl-space)
2.type 'aaaaa'
3.type 'shift-space' (another way to toggle off LE)
4.type 'a'

Actual results:
In this case, oowriter seems to hide the preedit buffer after typing
shift-space. And typing another char reveals the preedit buffer again.
Preedit buffer shows 'æ¥æ¥æ¥æ¥æ¥æ¥' equivalent of 'aaaaaa'

Expected results:
oowriter do not hide the preedit buffer.
Preedit buffer shows 'æ¥' equivalent of 'a'. 

Additional info:

Comment 1 Lawrence Lim 2004-10-28 04:15:52 UTC
Here's a better testcase for zh_CN locale using chinput. :)

chinput (zh_CN)
Steps to Reproduce:
1.toggle on (ctrl-space)
2.enter 'hong' (do not commit)
3.Press up or down arrow key
4.enter 'h'
Actual results:
Preedit buffer shows 'hong h'

Expected results:
Preedit buffer shows 'h'

Comment 2 Leon Ho 2004-10-28 12:32:03 UTC
The current event handling also affects the "right arrows" and "left
arrows". When LE is activiated, press right arrow or left arrow once
will be executed twice. (i.e. in oocalc, press right arrow will jump
from A column to C column)

Comment 3 Akira TAGOH 2004-10-29 05:50:12 UTC
Well, it looks like you contains multiple problem here - for first
testcase (both of zh_CN and zh_TW), it's duplicated bug with Bug#136643.
for second testcase, it's because of iiim immodule doesn't support
gtk_im_context_reset(). neither first testcase nor second testcase is
OOo bugs. and technically both are im-sdk bug.
I'm reassiging this to im-sdk to be tracking for gtk_im_context_reset

Comment 4 Leon Ho 2004-12-09 02:08:59 UTC
Marking it as item for RHEL4 U1

Comment 5 Akira TAGOH 2005-03-02 23:13:25 UTC
Fixed in 12.1.1-6.svn2208 for rawhide and 12.1-12.EL for RHEL4U1.

Comment 6 Lawrence Lim 2005-03-03 05:59:09 UTC
Tested 12.1-12.EL with openoffice.org-1.1.2-20.6.EL4 and Dan's recent 
libvclplug_gtk645li.so. zh_* and ja are working properly in oowriter. However,
hangulLE seems to be experiencing problem. Downgraded im-sdk to 12.1-10.EL and
hangulLE is working properly again.

Actual Result:
Unable to type korean char continuously. Have to input a single char, type enter
and proceed to the next char.

Expected Result:
Should be able to input korean text continously.

Test string: qkfrkd (ë°ê°)

Comment 7 Akira TAGOH 2005-03-03 14:08:51 UTC
Well, It's a bad effect after fixing gtk_im_context_reset() stuff and
OOo has that problem IMO. and it should be filed as OOo bug separately.

Comment 8 Dan Williams 2005-03-03 15:40:20 UTC
Reason is that when "commit" is called, iiimf calls "preedit-changed" as well
with an empty string, exactly like XIM does.  This is fine.  But OOo doesn't
treat the committed string and the preedit string differently, so when you do
the "preedit-changed", it erases the previously committed string.

Comment 9 Dan Williams 2005-03-03 18:57:57 UTC
So I fixed the original problem, but there's a new one with Korean:

signalKey: PRESS 114 (Unicode 0x72), time 1820681158.
signalIMPreeditChanged: called with text 'ë°'.
   ^ I just pressed 'r'
signalKey: filtered by IM, returning.
signalKey: RELEASE 114 (Unicode 0x72), time 1820681289.
signalKey: filtered by RELEASE matching, returning.
signalKey: PRESS 107 (Unicode 0x6B), time 1820684218.
signalIMPreeditChanged: called with text 'ê°'.
   ^ I just pressed the second 'k'
signalIMCommit: called with text 'ë°'.
   ^ LE decides to commit 'qkfr'
EndExtTextInput: called.
   ^ EndExtTextInput() calls resetIMContext()
resetIMContext: resetting...
   ^ now gtk_im_context_reset() is called
signalIMCommit: called with text 'ê°'.
   ^ which causes the LE to commit the _next_ text in the preedit buffer
resetIMContext: done
signalKey: filtered by IM, returning.
signalKey: RELEASE 107 (Unicode 0x6B), time 1820684310.
signalKey: filtered by RELEASE matching, returning.
signalKey: PRESS 100 (Unicode 0x64), time 1820709739.
signalIMPreeditChanged: called with text 'ã'.
signalKey: filtered by IM, returning.
signalKey: RELEASE 100 (Unicode 0x64), time 1820709864.
signalKey: filtered by RELEASE matching, returning.
signalKey: PRESS 32 (Unicode 0x20), time 1820711989.
signalIMCommit: called with text 'ã'.
EndExtTextInput: called.
resetIMContext: resetting...

So, it seems that the gtk_im_context_reset() during "signalIMCommit" causes the
Korean LE to commit the text in the preedit buffer that shouldn't really be there.

Comment 10 Dan Williams 2005-03-03 21:34:11 UTC
Ok, seems to be fixed now with changes to OOo to not call gtk_im_context_reset()
during a "commit" signal, but to still EndExtTextInput internally.

Comment 11 Dan Williams 2005-03-07 06:02:42 UTC
Fixed in:

RHEL3: 1.1.2-22.2.2.EL3
RHEL4: 1.1.2-22.6.EL4

Still needs to be forward-ported to 1.1.3 for FC2 & FC3.

Comment 12 Dan Williams 2005-03-07 06:07:07 UTC
eek, back to ASSIGNED since this is for Fedora Core not RHEL.  Also moving back to 
"openoffice.org" component since it's an OOo issue mostly.

Comment 13 Akira TAGOH 2005-03-18 04:44:29 UTC
So when will you push the updated package then?

Comment 14 Akira TAGOH 2005-03-31 06:54:15 UTC
FYI, the latest IIIMF which contains the implementation of
gtk_im_context_reset() was pushed for rawhide. what we need to do is fixing OOo
now. reassigning to dcbw.

Comment 15 Dan Williams 2005-04-04 18:10:07 UTC
RHEL4 patch applied to FC3 builds, now doing local build for functional
verification before pushing to beehive

Comment 16 Dan Williams 2005-04-04 18:10:45 UTC
removing self as CC since its my issue...

Comment 17 Dan Williams 2005-04-05 20:09:29 UTC
FC3 testing packages are at:


Please verify that these issues have been resolved and that the packages work
correctly with IIIMF that has gtk_im_context_reset()

Comment 18 Dan Williams 2005-04-05 20:11:47 UTC
*** Bug 144557 has been marked as a duplicate of this bug. ***

Comment 19 Dan Williams 2005-04-05 20:13:03 UTC
Warren: can you test and verify the packages in Comment 17?

Comment 20 Dan Williams 2005-04-05 20:38:00 UTC
hmm, my short testing in ja_JP.UTF-8 with im-sdk 12.1-10.FC3 seems to indicate
that resetting is not happening to the preedit string.  More investigation required.

Comment 21 Lawrence Lim 2005-04-06 08:38:30 UTC
Dan: I will update you with my findings by tomorrow morning.

Comment 22 Lawrence Lim 2005-04-06 11:50:55 UTC
Tried the OOo package from Comment 17, I have similar situation as well for CJK
locale with oowriter and oocalc. The preedit string actually commits to the
application if I switch off the LE with preedit buffer != NULL.

Comment 23 Dan Williams 2005-04-06 14:23:24 UTC
Seems to work for me when I build the im-sdk in the FC-3/ dir of package CVS. 
Patches for gtk_im_context_reset() are present in the specfile there but not in
current 12.1-10.FC3 packages available for FC3.

Comment 24 Jay Turner 2005-04-26 06:59:00 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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