Closed GoogleCodeExporter closed 9 years ago
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 yukawa@google.com
on 28 Nov 2014 at 12:58
--- 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 f.takeya...@gmail.com
on 28 Nov 2014 at 4:25
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 yukawa@google.com
on 29 Nov 2014 at 2:24
Thank you. I understand the situation.
Original comment by f.takeya...@gmail.com
on 29 Nov 2014 at 4:16
This issue was closed by revision r386.
Original comment by yukawa@google.com
on 30 Nov 2014 at 8:51
Original issue reported on code.google.com by
f.takeya...@gmail.com
on 25 Nov 2014 at 2:36