ibus-mozc + XIM: preedit text is not cleared after preedit commit triggered by focus change

[GoogleCodeExporter]

The original report of this was filed in openSUSE's bugzilla:
https://bugzilla.opensuse.org/show_bug.cgi?id=906143

Although preedit text of ibus-mozc is committed when an application lost focus, 
the preedit text seems not to be cleared; when the application gets focus 
again, the preedit text is shown again.

This problem happens only when ibus-mozc is used via XIM.

Original issue reported on code.google.com by [email protected] on 25 Nov 2014 at 2:36

[GoogleCodeExporter]

Thank you for the report.

To make the bug report self-contained, can you copy the repro steps and 
actual/expected behavior from the original report?  Also, it would be a great 
help for us if you can confirm that the same issue is reproducible with the 
latest version of Mozc on Ubuntu 12.04 or 14.04.

Thanks!

Original comment by [email protected] on 28 Nov 2014 at 12:58

• Added labels: OpSys-Linux

[GoogleCodeExporter]

--- cited from boo#906143 
--------------------------------------------------------------
1. Open gnome-terminal
2. Type "GTK_IM_MODULE=xim gedit"
3. Turn on IME and select "Japanese Mozc" on Language Panel.
    (Press left side of icon on language panel by right mouse button)
4. Type "a", Japanese "A" is displayed
5. Move input focus to gnome-terminal, and move back input focus to gedit
6. Japanese "A" is committed, type "i", Japanese "I" should be displayed, 
   But previous Japanese "A" is also displayed on preedit string, so "AI" is displayed.
--------------------------------------------------------------------------------
--------

I confirmed this bug with ibus-mozc 1.15.1868.102 on openSUSE 13.2
Unfortunately, I don't have build environment on Ubuntu; I cannot check on it 
soon.

Original comment by [email protected] on 28 Nov 2014 at 4:25

[GoogleCodeExporter]

Thank you for updating the repro steps.  I can reproduce the issue with Mozc 
2.16.1926.102 on Ubuntu 14.04.  It also turns out that this is one of the most 
fragile part of IBus.  According to our commit log, we have had changed the 
logic here at least 2 times to address issues found around focus-in/out in 
Chromium OS since we stopped using IBus in Chromium OS.  Let me summarize the 
history behind focus handling in ibus-mozc.

1. In version 1.1.773.102 (r58) and prior, ibus-mozc simply have had reverted 
the on-going composition text by calling |RevertSession(engine)| from 
|FocusOut|, which is called when Mozc loses input focus.  So far so good.

2. In version 1.2.809.102 (r61), ibus-mozc changed to call 
|SubmitSession(engine)| in |FocusOut| to commit the on-going composition text 
rather than revert it because of the requirement in Hangul version of Mozc 
(used only in Chrome/Chromium OS). http://crbug.com/201221

https://code.google.com/p/mozc/source/diff?spec=svn61&r=61&format=side&path=/tru
nk/src/unix/ibus/mozc_engine.cc&old_path=/trunk/src/unix/ibus/mozc_engine.cc&old
=58#sc_svn58_454

3. In version 1.3.911.102 (r77), ibus-mozc started relying on 
IBUS_ENGINE_PREEDIT_COMMIT flag in ibus_engine_update_preedit_text_with_mode 
API so that the IBus can commit the on-going composition text on behalf of the 
Mozc when Mozc loses focus.  This was a workaround for the asynchronous nature 
of IBus.  Here is the excerpt from http://crbug.com/201660 which explains why 
calling |SubmitSession(engine)| from |FocusOut| didn't work well.
| 1. Omni box(gtk) send FocusOut event to ibus.
| 2. IBus send FocusOut event to Engine
| 3. Omni box send FocusIn event to ibus.
| 4. Engine send IBus to commit preedit string.(in case of Hangul)
| 5. IBus send to Omni box to commit string.
| 6. IBus send FocusIn event to Engine.
In short, we cannot reliably commit text from |FocusOut|.  We addressed this 
issue by adding a new IBUS_ENGINE_PREEDIT_COMMIT flag into IBus with working 
closely with IBus upstream.

https://code.google.com/p/mozc/source/diff?spec=svn77&r=77&format=side&path=/tru
nk/src/unix/ibus/mozc_engine.cc&old_path=/trunk/src/unix/ibus/mozc_engine.cc&old
=73#sc_svn73_496

BTW, you might be wondering why this issue is not reproducible when 
GTK_IM_MODULE=ibus.  I found that when gedit is launched with 
GTK_IM_MODULE=ibus, gedit or someone calls gtk_im_context_reset (or 
ibus_im_context_reset) to reset the IM context when gedit gains input focus.  I 
haven't investigated further about who is actually calling gtk_im_context_reset 
(or ibus_im_context_reset) though.  Anyway, this can explain the reason why 
ibus-mozc can reset its state, because Mozc internally calls 
|RevertSession(engine)| from |Reset| handler.

Finally, one of the simplest solution of this issue would be calling 
|RevertSession(engine)| from |FocusOut| again, as we have had done until 
1.2.809.102 (r61).

Original comment by [email protected] on 29 Nov 2014 at 2:24

• Changed state: Started

[GoogleCodeExporter]

Thank you. I understand the situation.

Original comment by [email protected] on 29 Nov 2014 at 4:16

[GoogleCodeExporter]

This issue was closed by revision r386.

Original comment by [email protected] on 30 Nov 2014 at 8:51

• Changed state: Fixed