https://bugs.documentfoundation.org/show_bug.cgi?id=173064
--- Comment #7 from Tanaka Takayuki <[email protected]> --- My first test for this bug was not enough, so I checked the conditions and tested again. I found that several environment variables change the behavior: - QT_IM_MODULE / QT_IM_MODULES: native Wayland input context, fcitx, or ibus - QT_QPA_PLATFORM: xcb or wayland - SAL_USE_VCLPLUGIN: kf6, qt6, qt5, or gtk3 My environment is Ubuntu 26.04, Plasma 6.6.6, Qt 6.10.2, Fcitx 5.1.19, and LibreOffice 26.2.5.2. For this test, I used: SAL_USE_VCLPLUGIN=kf6 QT_QPA_PLATFORM=wayland Then I changed the Qt input method setting. When QT_IM_MODULE / QT_IM_MODULES is not set, Qt uses the native Wayland input context, and I can reproduce the issue. But when I use the Fcitx Qt input context: QT_IM_MODULES=fcitx \ QT_QPA_PLATFORM=wayland \ SAL_USE_VCLPLUGIN=kf6 \ libreoffice --calc I cannot reproduce the issue. So, using the QT_IM_MODULES=fcitx can be a workaround in my environment. However, the Fcitx documentation recommends not setting QT_IM_MODULE on KDE Plasma Wayland: https://fcitx-im.org/wiki/Using_Fcitx_5_on_Wayland The KDE community page also gives similar information. It says that QT_IM_MODULE may be set for individual applications if needed: https://discuss.kde.org/t/kde-plasma-wayland/9014 So, QT_IM_MODULES=fcitx solves the issue in my environment, but it is not the recommended general setting for KDE Plasma Wayland. One more note: The Fcitx language selection popup is opened by a keyboard event (Ctrl+Space). So it is possible that the cursor position is updated by the keyboard event before the popup is shown. I am not sure about this. Also, since I can reproduce similar behavior in Firefox, there may also be a Wayland input method issue in Firefox. I found an existing Firefox bug about Fcitx5 candidate window position on KDE Wayland: https://bugzilla.mozilla.org/show_bug.cgi?id=1865779 -- You are receiving this mail because: You are the assignee for the bug.
