+++ 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):
scim-chewing-0.3.1-4.fc6

How reproducible:
always

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 我
  
Actual results:
application crashed, pls see attached screenshot and details

Expected results:


Additional info:

-- Additional comment from xwang on 2006-09-12 04:53 EST --
Created an attachment (id=136060)
screenshot


-- Additional comment from xwang on 2006-09-12 04:54 EST --
Created an attachment (id=136061)
details


-- Additional comment from xwang 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 xwang on 2006-09-14 05:43 EST --
Created an attachment (id=136246)
gdb gedit info


-- Additional comment from cchance on 2006-09-14 20:14 EST --
Created an attachment (id=136316)
gdb backtrace when the Bug Buddy windows pops up.


-- Additional comment from mclasen 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 llch on 2006-09-28 01:44 EST --
Can you assist on Matthias' request please? install appropriate *-debuginfo for
symbols.

Also do other scim IMEs crash in the same way?


-- Additional comment from xwang 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...
gtk2-debuginfo-2.10.4-4.fc6
gtksourceview-debuginfo-1.8.0-1.fc6
scim-1.4.4-35.fc6
scim-debuginfo-1.4.4-35.fc6
scim-chewing-0.3.1-7.fc6
scim-chewing-debuginfo-0.3.1-7.fc6
gedit-2.15.9-1.fc6
gedit-debuginfo-2.15.9-1.fc6

And it seems that other scim IMEs couldn't crash in the same way.


-- Additional comment from xwang on 2006-10-11 04:20 EST --
Created an attachment (id=138224)
gdb gedit info


-- Additional comment from petersen 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
im modules.

-- Additional comment from petersen 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 petersen 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
problem.

So probably a separate bug should be opened for scim for the lack of reset on
click.

-- Additional comment from petersen 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 petersen on 2006-11-10 02:49 EST --
*** Bug 214943 has been marked as a duplicate of this bug. ***

-- Additional comment from petersen on 2006-11-21 20:24 EST --
also happens with scim-anthy

-- Additional comment from petersen on 2006-11-21 20:26 EST --
and Chinese scim-tables

-- Additional comment from petersen on 2006-11-21 22:52 EST --
Reported in upstream tracker as
https://sourceforge.net/tracker/index.php?func=detail&aid=1600910&group_id=108454&atid=650539

-- Additional comment from petersen on 2006-11-22 00:23 EST --
Created an attachment (id=141874)
gtk2.backtrace

Here is another backtrace using a gtktextview from gtk-demo.

-- Additional comment from phuang 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 cchance 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 petersen on 2006-11-22 20:57 EST --
Shawn, this problem is not specific to scim-chewing.

-- Additional comment from petersen 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
too).

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 phuang 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 phuang 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 petersen 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 petersen 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 phuang on 2006-11-26 21:33 EST --
fixed in scim-1_4_5-4_fc7

-- Additional comment from phuang on 2006-11-28 01:50 EST --
Created an attachment (id=142262)
Appatch from james.su

Hi,

On 11/28/06, Shawn Huang <phuang> 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
>>> > >>
https://sourceforge.net/tracker/?func=detail&atid=650539&aid=1600910&group_id=108454

>>> > >> 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
http://bugzilla.gnome.org/show_bug.cgi?id=111438

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 phuang on 2006-11-28 01:57 EST --
hi mclasen, 
Could you review this patch for gtk from James Su (attachment 142262 [details])? Thanks.

-- Additional comment from phuang on 2006-11-29 23:40 EST --
file a bug on gnome bugzilla
http://bugzilla.gnome.org/show_bug.cgi?id=380753


-- Additional comment from phuang 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 petersen on 2006-11-30 01:23 EST --
Thanks - it may be better to clone a separate gtk2 bug for the gtktextview patch.