Bug 160838 - LibreOffice does not report the correct cursor position for IME at certain places unless using gtk3 VCL plugin
Summary: LibreOffice does not report the correct cursor position for IME at certain pl...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
24.2.1.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:24.8.0
Keywords:
: 161286 (view as bug list)
Depends on:
Blocks: KDE, KF5
  Show dependency treegraph
 
Reported: 2024-04-27 04:20 UTC by Huanyu Liu
Modified: 2024-05-27 13:55 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Huanyu Liu 2024-04-27 04:20:16 UTC
Description:
This bug is move from tdf#160275 to make the description more accurate.

Background information: For a few non-Latin scripts (especially Chinese and Japanese), an IME (input method engine/editor) is needed for inputting. When an IME is enabled, the keystrokes on the keyboard is first sent to the IME. The IME will do the transcription and show a candidate box for you to select the intended character sequence, as the transcription process is not one-to-one (e.g. in Chinese Pinyin, shizi → 狮子, 十字, 师资, ...). After you select the intended candidate, the corresponding character sequence will be inputted. For ease of inputting, the candidate box is usually shown near the cursor of the "host" program.

The problem is that LO does not report the correct cursor position at certain places, so the candidate box will be shown at the wrong position (usually at the top-left corner of the window). "Certain places" includes:
- Input line of Calc;
- Comment region (Ctrl+Alt+C) of Writer, Impress and Draw (but not Calc);
- Input region of Math.
This only happens at these certain places, and everything works well at other places.

Furthermore, the IME has different behaviors when using different VCL plugins:
- gtk3: Everything works well (even at the places mentioned above);
- kf5, qt5, kf6, qt6, gen: The candidate box is shown at the wrong position, but IME is still usable;
- gtk4: IME is not usable at all; every keystroke is directly sent to LO.
Again, this only happens at the places mentioned above.

I noticed that all these places have one thing in common: The cursor does not blink. I think this should be related to the bug.

Currently, I am using the fcitx5 IME. The 5.1.4 version of fcitx5-qt had a bug that would cause LO to crash (see tdf#160275) under Wayland, but it was fixed in the 5.1.6 version. The current bug happens under both Wayland and X11.

Steps to Reproduce:
1. Install the fcitx5 framework and setup it according to the instructions on the official website;
2. Launch LO (optionally with environment variable SAL_USE_VCLPLUGIN) and navigate to any one of the above-mentioned places (e.g. comment region of Writer);
3. Toggle the IME with keyboard shortcut (Ctrl+Space by default);
4. (Optionally) try typing something if you have installed any "usable" IMEs (see other information below). 

Actual Results:
The candidate box is not shown at the correct position.

Expected Results:
The candidate box should appear around the cursor.


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Please bear in mind that fcitx5 itself does not ship with any "usable" IMEs; only keyboard layouts (which do not use a candidate box actually) are provided. However, toggling the IME with keyboard shortcut will show an indicator near the cursor, which shares the same code with the "actual" candidate box and also fails at the above-mentioned places. You can install a "usable" IME (e.g. Rime for Chinese, Mozc for Japanese) to summon the "actual" candidate box.

Version: 24.2.2.2 (X86_64) / LibreOffice Community
Build ID: 420(Build:2)
CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: kf6 (cairo+wayland)
Locale: zh-CN (zh_CN.UTF-8); UI: zh-CN
24.2.2-2
Calc: threaded
Comment 1 Michael Weghorn 2024-04-29 05:07:22 UTC
Thanks for the excellent bug report!

The discussion in tdf#160275 has some more details on how to set up fcitx.

> Additional Info:
> (...) However, toggling the IME with keyboard shortcut will show an
> indicator near the cursor, which shares the same code with the "actual"
> candidate box and also fails at the above-mentioned places.

That's indeed helpful for quick testing. In my testing:

* The indicator shows up at the right position when switching layouts using the Super+Space shortcut (manually configured, s. discussion in tdf#160275) while the cursor is in a Writer doc for all of gtk3, gtk4, kf5.
* It shows up at the right place in Calc's input line for gtk3 and gtk4.
* It shows up at the wrong place (top-left of the window) when using Calc's input line with kf5.
* It does not show up at all for qt6 in either a Writer doc or Calc's input line, but a regular space is inserted. (That seems to be a separate issue and sounds similar to what you described for gtk4.)

> - gtk4: IME is not usable at all; every keystroke is directly sent to LO.

Haven't yet done any further tests using an actual input method, but as mentioned above, at least the language indicator shows up at the right position for me on Debian testing, so this is likely a separate issue.

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 35843892dfec1edbf53c33f60205f4568ae47f12
CPU threads: 32; OS: Linux 6.6; UI render: default; VCL: kf5 (cairo+wayland)
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: CL threaded

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 35843892dfec1edbf53c33f60205f4568ae47f12
CPU threads: 32; OS: Linux 6.6; UI render: default; VCL: qt6 (cairo+wayland)
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: CL threaded

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 35843892dfec1edbf53c33f60205f4568ae47f12
CPU threads: 32; OS: Linux 6.6; UI render: default; VCL: gtk3
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: CL threaded

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 35843892dfec1edbf53c33f60205f4568ae47f12
CPU threads: 32; OS: Linux 6.6; UI render: default; VCL: gtk4
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: CL threaded
Comment 2 Michael Weghorn 2024-04-29 08:39:50 UTC
(In reply to Michael Weghorn from comment #1)
> * It does not show up at all for qt6 in either a Writer doc or Calc's input
> line, but a regular space is inserted. (That seems to be a separate issue
> and sounds similar to what you described for gtk4.)
I can no longer reproduce that problem with qt6 any more after resetting my LO profile. It now behaves the same as kf5.

I also noticed that the proper position (e.g. in Writer doc) is potentially only shown on Super+Space once the first character has been typed, not right after opening a new doc.
Comment 3 Commit Notification 2024-04-30 15:36:47 UTC
Michael Weghorn committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/691c61146d3d627d24fec336550a0d4933549cda

tdf#160838 editeng: Report IME cursor pos more reliably

It will be available in 24.8.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 4 Commit Notification 2024-04-30 15:36:49 UTC
Michael Weghorn committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/63a62abae01e7beb15d1e7cb12c469b42253bf1b

tdf#160838 qt: Update IM cursor position also on modifier change

It will be available in 24.8.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 5 Michael Weghorn 2024-04-30 15:41:46 UTC
(In reply to Michael Weghorn from comment #2)
> I also noticed that the proper position (e.g. in Writer doc) is potentially
> only shown on Super+Space once the first character has been typed, not right
> after opening a new doc.

With the commits from comment 3 and comment 4, the position of the keyboard layout/language indicator is OK now in my tests, and also the problem from comment 2 about the position only being correct in Writer e.g. after typing is fixed.

I haven't tested with a real IME yet.

Could you please test with a daily development build (from tomorrow or later) whether this actually works for you now as expected and report back here?

(Marking as fixed for now, since the issues I could reproduce no longer occur. Please reopen if your issue is still reproducible.)
Comment 6 Huanyu Liu 2024-05-02 13:57:43 UTC
As of Daily Build 2024-05-02_04.49.07:

The issue is fixed at the following places:
- Input line of Calc;
- Comment region of Writer;
- Input line of Math (i.e. the lower region where everything is treated as plain text; I don't know whether this is the correct name).

The issue persists at the following places:
- Comment region of Impress & Draw;
- Display region of Math (i.e. the upper region where the equation is rendered; although I think no one would ever use an IME here).

I also noticed that at the places where the issue persists, you have to "activate" the cursor before using an IME. Otherwise, all keystrokes are sent to LO directly as described in Description (gtk4) and Comment 1 (qt6). Here "to activate the cursor" means "to summon a cursor at any other place (e.g. to create a textbox, to invoke the Find Bar with Ctrl+F, to click on the Font Selection dropdown menu)". After "activation", the IME is usable, but the candidate box is shown at the wrong place.

Furthermore, I noticed that in the comment region of Impress & Draw, characters of certain scripts (CJK, Arabic, Thai, Javanese, Devanagari, etc.) are apparently smaller than the others (Latin, Greek, Cyrillic, etc.), while in the comment region of Writer & Calc, character size is OK. I don't know whether this is related to the issue.

I can only use kf5 and gen for Daily Build versions, so I haven't tested with other VCL plugins.
Comment 7 Michael Weghorn 2024-05-03 06:08:56 UTC
(In reply to Huanyu Liu from comment #6)
> As of Daily Build 2024-05-02_04.49.07:
> 
> The issue is fixed at the following places:
> - Input line of Calc;
> - Comment region of Writer;
> - Input line of Math (i.e. the lower region where everything is treated as
> plain text; I don't know whether this is the correct name).
> 
> The issue persists at the following places:
> - Comment region of Impress & Draw;
> - Display region of Math (i.e. the upper region where the equation is
> rendered; although I think no one would ever use an IME here).

Indeed, I can reproduce that and did a bibisect.

The position stops being reported correctly for kf5 with 

    commit a39a3f1ad1e5e39b09ce474c0f4c0f9f4e174bbe
    Author: Caolán McNamara
    Date:   Tue Feb 9 12:07:27 2021 +0000

        weld impress annotation window

> I also noticed that at the places where the issue persists, you have to
> "activate" the cursor before using an IME. Otherwise, all keystrokes are
> sent to LO directly as described in Description (gtk4) and Comment 1 (qt6).
> Here "to activate the cursor" means "to summon a cursor at any other place
> (e.g. to create a textbox, to invoke the Find Bar with Ctrl+F, to click on
> the Font Selection dropdown menu)". After "activation", the IME is usable,
> but the candidate box is shown at the wrong place.

At least for comments in Draw, this is a regression from 

    commit 36348c21c5499f539fd354de6a980fa7a59218bd
    Author: Caolán McNamara
    Date:   Fri Feb 26 14:38:30 2021 +0000

        drop intermediate vcl container for impress annotation floating toplevel

@Caolán: Any thoughts?
Comment 8 Stéphane Guillou (stragu) 2024-05-27 13:55:29 UTC
*** Bug 161286 has been marked as a duplicate of this bug. ***