Red Hat Bugzilla – Bug 217827
crashes when clicking during scim gtkimm preedit
Last modified: 2008-05-06 21:01:43 EDT
+++ This bug was initially created as a clone of Bug #213796 +++
+++ This bug was initially created as a clone of Bug #206120 +++
Description of problem:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.activate scim-chewing, ctrl-SPACE
2.launch gedit and enter ji3+Enter+ji3 (我我)
3.double-click several times after the second word 我
application crashed, pls see attached screenshot and details
-- Additional comment from email@example.com on 2006-09-12 04:53 EST --
Created an attachment (id=136060)
-- Additional comment from firstname.lastname@example.org on 2006-09-12 04:54 EST --
Created an attachment (id=136061)
-- Additional comment from email@example.com on 2006-09-12 05:02 EST --
And in oowriter, keep clicking after pre-edit word would clear all characters
before this word
-- Additional comment from firstname.lastname@example.org on 2006-09-14 05:43 EST --
Created an attachment (id=136246)
gdb gedit info
-- Additional comment from email@example.com on 2006-09-14 20:14 EST --
Created an attachment (id=136316)
gdb backtrace when the Bug Buddy windows pops up.
-- Additional comment from firstname.lastname@example.org on 2006-09-15 11:14 EST --
Xiaohong, can you reproduce the same gedit stacktrace after installing
gtk2-debuginfo and gtksourceview-debuginfo, please ?
-- Additional comment from email@example.com on 2006-09-28 01:44 EST --
Can you assist on Matthias' request please? install appropriate *-debuginfo for
Also do other scim IMEs crash in the same way?
-- Additional comment from firstname.lastname@example.org on 2006-10-11 04:19 EST --
After installed gtk2-debuginfo and gtksourceview-debuginfo, ran gdb and did same
steps to reproduce the bug, gedit didn't crash but got frozen.
Installed packages are...
And it seems that other scim IMEs couldn't crash in the same way.
-- Additional comment from email@example.com on 2006-10-11 04:20 EST --
Created an attachment (id=138224)
gdb gedit info
-- Additional comment from firstname.lastname@example.org on 2006-10-30 21:24 EST --
Problem happens with gtktextview and other scim IMEs in general, and does not seem
to be gedit or scim-chewing specific. Also happens with both scim and scim-bridge
-- Additional comment from email@example.com on 2006-11-01 21:02 EST --
(In reply to comment #12)
> does not seem to be [..] scim-chewing specific
Actually testing further on my own rhel5 testbox yesterday , I could only
reproduce this with scim-chewing.
-- Additional comment from firstname.lastname@example.org on 2006-11-02 03:10 EST --
After testing more with Caius, it seems there may be two issues: Caius has been
testing with the scim gtkimm whereas I am using the scim-bridge immodule.
With the scim gtkimm clicking does not always reset preedit, whereas it does with
the scim-bridge gtkimm. Hence one sees preedit movement and sometimes crashing
with the scim gtkimm but not scim-bridge for other IMEs too. However scim-chewing
crashes under both scim and scim-bridge gtkimms, so it seems to be an additional
So probably a separate bug should be opened for scim for the lack of reset on
-- Additional comment from email@example.com on 2006-11-02 20:27 EST --
Both multiple clicking with either scim-pinyin or scim-chewing preedit on a line in
a gtktextview can cause crashes.
-- Additional comment from firstname.lastname@example.org on 2006-11-10 02:49 EST --
*** Bug 214943 has been marked as a duplicate of this bug. ***
-- Additional comment from email@example.com on 2006-11-21 20:24 EST --
also happens with scim-anthy
-- Additional comment from firstname.lastname@example.org on 2006-11-21 20:26 EST --
and Chinese scim-tables
-- Additional comment from email@example.com on 2006-11-21 22:52 EST --
Reported in upstream tracker as
-- Additional comment from firstname.lastname@example.org on 2006-11-22 00:23 EST --
Created an attachment (id=141874)
Here is another backtrace using a gtktextview from gtk-demo.
-- Additional comment from email@example.com on 2006-11-22 04:41 EST --
Created an attachment (id=141887)
add hide preedit string in IMEngine reset method.
When user clicks the gtktextview, it will reset immodule (scim-bridge), and it
will cause IMEngine reseted. But scim-chewing does not hide preedit_string when
IMEngine reset is called. I think it's the root reason.
-- Additional comment from firstname.lastname@example.org on 2006-11-22 18:37 EST --
Bug #209575 has the same behavior which:
`GTK_IM_MODULE=scim-bridge gedit` which uses scim-bridge as IMMODULE.
It was also be called reset and crashes because chewing didn't follow the command.
After the fix which add focus_out() and focus_in() in reset function within
chewing, it works for scim-bridge.
However, when IME is started by:
`GTK_IM_MODULE=scim gedit` which uses scim built-in IMMODULE.
It still crashes though SCIM's reset function has called chewing's reset
function, but it just doesn't clear the preedit even same focus_in() and
focus_out() modifications are in chewing reset function.
Just my exp hope that helps. Please kindly point out if I got any info inaccurate.
-- Additional comment from email@example.com on 2006-11-22 20:57 EST --
Shawn, this problem is not specific to scim-chewing.
-- Additional comment from firstname.lastname@example.org on 2006-11-22 21:04 EST --
Just to clarify: there were two problems - one was scim-chewing not resetting
preedit (bug 206120) which affects both scim-bridge and the scim gtkimm.
It is already fixed in devel (rawhide).
This remaining bug is only related to the scim gtkimm and occurs for scim-anthy,
scim-hangul, scim-pinyin, scim-chewing, and scim-tables (and probably scim-m17n
However attachment 141887 [details] might be a more correct way of fixing the scim-chewing
crash? Perhaps you could attach it to the other bug?
-- Additional comment from email@example.com on 2006-11-22 22:47 EST --
im-scim has two modes to filter keys. One is snooper, another is overriding
gtkimcontext filter_keypress method. when im-scim uses snooper, gtktextview will
not get any key events, and then it will not reset imcontext when mouse clicked.
It will make gtktextview and scim in a wrong state.
There are two ways to fix it.
1. turn off snooper. (I am not sure if it has some impact)
2. snooper mouse event, reset im when mouse clicked. (I am not sure if can
snooper mouse events).
-- Additional comment from firstname.lastname@example.org on 2006-11-23 03:48 EST --
Created an attachment (id=141979)
Turn off snooper mode to avoid this bug.
The patch is for scim component. It will turn off snooper in im-scim, It can
avoid this bug.
-- Additional comment from email@example.com on 2006-11-24 01:24 EST --
I tried setting /FrontEnd/GtkIMModule/UseKeySnooper = false
but I still seem able to reproduce the crash.
-- Additional comment from firstname.lastname@example.org on 2006-11-24 03:47 EST --
It seems the config key does not work. :-(
But the patch to turn off the snooper does. :)
-- Additional comment from email@example.com on 2006-11-26 21:33 EST --
fixed in scim-1_4_5-4_fc7
-- Additional comment from firstname.lastname@example.org on 2006-11-28 01:50 EST --
Created an attachment (id=142262)
Appatch from email@example.com
On 11/28/06, Shawn Huang <firstname.lastname@example.org> wrote:
> > Yusuke TABATA wrote:
>> > > Jens Petersen wrote:
>> > >
>>> > >> It seems the key snooper of the scim gtk immodule can lead to crashes
>>> > >> during preedit when clicking in a gtk text buffer. (See
>>> > >>
>>> > >> for more details.)
>>> > >>
>>> > >> Can someone remind me what the key snooper function is useful for?
>>> > >>
>> > > Use of key snooper is work around for this issue.
>> > > http://bugzilla.gnome.org/show_bug.cgi?id=111438
>> > > FYI: Latest uim uses other method to avoid it.
>> > >
>> > > Anyway, I wonder if the crash really caused by snooper.
>> > >
> > I found when snooper is enabled, gtktextview will not get any key
> > events. If user clicks mouse button,
> > gtktextview will not reset IMContext, because he think IMContext did not
> > receive any key events. Then
> > gtktextview will calculate and show text selection, but the preedit
> > string was not cleaned. It will cause chaos
> > in gtktextview, and then crash.
> > I think we should enable snooper for hot keys, but skip other keys in
> > snooper callback. Does It make sense?
This way can't fix the issue mentioned in
IMHO, gtktextview should be fixed to avoid such crash even if the
preedit string was not cleaned. And im context should be reset no
matter whether it received any key events or not, when clicking mouse.
-- Additional comment from email@example.com on 2006-11-28 01:57 EST --
Could you review this patch for gtk from James Su (attachment 142262 [details])? Thanks.
-- Additional comment from firstname.lastname@example.org on 2006-11-29 23:40 EST --
file a bug on gnome bugzilla
-- Additional comment from email@example.com on 2006-11-30 00:51 EST --
Turn off snooper can work now very well. I close it temporarily.
fixed in scim-1_4_5-4_fc7 .
-- Additional comment from firstname.lastname@example.org on 2006-11-30 01:23 EST --
Thanks - it may be better to clone a separate gtk2 bug for the gtktextview patch.
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.
If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we're following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.
If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.
The process we're following is outlined here: