ibus predict window is shown at the previous cursor position

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open a html file or access a page which has textarea in Firefox(a sample 
html file is attached).

2. Type the following keys to input "今日の天気は晴れ" in the textarea.
"kyouno<space>tenkiha<space>hare"

3. See the position of ibus predict window for "hare".

What is the expected output?
ibus predict windows is shown at the position of "hare".

What do you see instead?
ibus predict window is shown at the position of "tenkiha".
See attached screenshot.

What version of the product are you using? On what operating system?

Ubuntu 14.10 Utopic Unicorn (development branch)
ibus-mozc:
  Installed: 1.15.1857.102-1
firefox:
  Installed: 31.0~b6+build2-0ubuntu1

Please provide any additional information below.

Original issue reported on code.google.com by nob...@nobuto-murata.org on 7 Aug 2014 at 12:56

• Blocked on: Deprecation of the iBus client code. #287

Attachments:

• firefox-textarea.png
• textarea.html

[GoogleCodeExporter]

Thank you for the report.  I'm able to reproduce this issue with Ubuntu 14.04 
with Mozc-1.13.1651.102.  However, I no longer have enough spare time to work 
on Linux IBus client of Mozc.  Therefore this issue will not be fixed until 
someone volunteers to fix it.  Please feel free to contact us if you find the 
root cause or come up with some patches to address this issue.

Thank you for your understandings.

Original comment by yukawa@google.com on 7 Aug 2014 at 4:24

• Changed state: VolunteersNeeded
• Added labels: OpSys-Linux, Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Note: this issue is also reproducible with GEdit on Ubuntu 14.04.

BTW, I just took a look at ibus-mozc code and had a feeling that we are not 
able to fix this issue in ibus-mozc in a reliable way.  This probably came from 
a limitation of GTK+ immodule.  If I understood correctly, there is no reliable 
way to retrieve the screen coordinates of composing characters in Linux 
desktop.  In the case of your report, GTK+ immodule doesn't provide the way to 
retrieve the screen coordinates of "はれ".

To work around against this unfortunate limitation, IBus-mozc has used 
gtk_im_context_set_cursor_location signal to estimate the location of the 
composing text.  Unfortunately, this isn't perfect.
https://developer.gnome.org/gtk3/stable/GtkIMContext.html#gtk-im-context-set-cur
sor-location

If you hope a reliable fix of this behavior, I'd suggest you to file a feature 
request for GTK+ immodule and IBus upstream to enable IMEs to retrieve the 
screen coordinates of the composing characters.  AFAIK such limitation doesn't 
exist in Windows, OSX, and Chromium OS.  For example, following Windows APIs 
are powerful enough for Mozc to show suggestion windows at the expected 
location on Windows OS.  We absolutely need similar APIs in Linux desktop.
http://msdn.microsoft.com/ja-jp/library/windows/desktop/dd318634.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms538781.aspx

Original comment by yukawa@google.com on 7 Aug 2014 at 6:08

[GoogleCodeExporter]

Revised the summary because this issue is not specific to Firefox

Original comment by yukawa@google.com on 7 Aug 2014 at 6:11

• Changed title: ibus predict window is shown at the previous cursor position

[GoogleCodeExporter]

Correction for my comment #2.

wrong:   http://msdn.microsoft.com/en-us/library/windows/desktop/ms538781.aspx
correct: http://msdn.microsoft.com/en-us/library/windows/desktop/ms538782.aspx

Original comment by yukawa@google.com on 7 Aug 2014 at 6:14

[GoogleCodeExporter]

Ah right, with the keystroke "kyouno<space>tenkiha<space>hare", this issue is 
reproducible both on firefox and gedit.

However with the keystroke "kyouno<space><enter>tenkiha<space><enter>hare", 
it's reproducible only on firefox. The behavior in gedit is slightly better.

Original comment by nob...@nobuto-murata.org on 8 Aug 2014 at 5:15

[GoogleCodeExporter]

> However with the keystroke "kyouno<space><enter>tenkiha<space><enter>hare", 
it's reproducible only on firefox. The behavior in gedit is slightly better.

It isn't surprising at all.  I guess ibus-mozc is calling IBus APIs (which 
eventually mapped into GTK+ immodule APIs) in the same way on both 
applications, but it does not mean that each application calls back 
gtk_im_context_set_cursor_location in the same way.  For instance, if the 
target application never calls back gtk_im_context_set_cursor_location, 
ibus-mozc never receives the screen coordinates of the cursor.  In this 
scenario, of course, it is impossible for ibus-mozc to show 
suggestion/candidate window at the appropriate position. 

You can find some related comments in the IBus itself.
https://github.com/ibus/ibus/blob/130d3108902ed3e7c61930e3a24ee957c3d3e658/ui/gt
k3/propertypanel.vala#L108
        /* FIXME: set_cursor_location() has a different behavior
         * in embedded preedit by applications.
         * GtkTextView applications, e.g. gedit, always call
         * set_cursor_location() with and without preedit
         * but VTE applications, e.g. gnome-terminal, and xterm
         * do not call set_cursor_location() with preedit.
         * firefox and thunderbird do not call set_cursor_location()
         * without preedit.
         * This may treat GtkIMContext and XIM with different ways.
         * Maybe get_preedit_string() class method.
         */

Let me summarize the situation for IME developers on Linux desktop.
1. Only cursor position can be retrieved via IME APIs.  There is no common way 
to retrieve the screen coordinates of an arbitrary character.
2. The application may or may not provide the cursor position. It even depends 
on the timing and application-internal state.

Perhaps we could improve the behavior of ibus-mozc when it is used with Firefox 
31, but I'm not sure if we can call it as a proper "Fix".

Original comment by yukawa@google.com on 8 Aug 2014 at 2:09

[GoogleCodeExporter]

Original comment by yukawa@google.com on 21 Apr 2015 at 6:16

• Now blocked on: Deprecation of the iBus client code. #287

[yukawa]

I confirmed that 9fbcdd5 does fix the case of gedit but the original issue in Firefox persists as of Firefox Nightly 2015-08-31. Probably there were two different issues and the firefox-specific one cannot be fixed in ibus-mozc side. I've just reported as Mozilla Bug 1200506 for firefox-specific one.