Bug 435278 - Search box (apparently) doesn't register itself as a text area, so even when it's in focus, Fcitx does not register it and does not allow text input or switching between languages.
Summary: Search box (apparently) doesn't register itself as a text area, so even when ...
Status: RESOLVED UPSTREAM
Alias: None
Product: plasmashell
Classification: Plasma
Component: Application Launcher (Kickoff) widget (other bugs)
Version First Reported In: 5.21.3
Platform: Arch Linux Linux
: NOR normal
Target Milestone: 1.0
Assignee: David Edmundson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-02 19:26 UTC by Alexander M.
Modified: 2021-04-10 11:22 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander M. 2021-04-02 19:26:21 UTC 
SUMMARY

Fcitx works by sitting in your tray and becoming activated whenever you focus a text area. For some reason, Kickoff does not work as expected, thus it is impossible to enter non-Latin text through Fcitx.


STEPS TO REPRODUCE

1. Install and setup Fcitx in whatever way you want and add at least a second layout (in my case the layouts in use are English, Greek and CJK).
2. Focus a text area like e.g. a browser's URL bar or a text editor.
3. Try to switch the language via Fcitx (NOT KDE's native layout manager, that's not what I'm talking about here): it works.
4. Try to type some text in the focused text area: it works.
5. Open Kickoff and make sure its Search box is focused.
6. Try to type some text: it doesn't work; instead the characters that are typed out are in whatever language/layout is selected in KDE's native layout manager (usually English in such a case because an IME is in use).
7. Now also try again to switch the language via Fcitx; yet again it doesn't work.


OBSERVED RESULT

When using Fcitx (and probably other IMEs as well, like IBus) the IME is not activated when focusing the Search box in Kickoff, and thus it's impossible to enter text or switch languages.


EXPECTED RESULT

When using Fcitx (and probably other IMEs as well, like IBus) the IME should become activated when focusing the Search box in Kickoff, and thus it should be possible to enter text or switch languages.


SOFTWARE/OS VERSIONS

OS: Arch Linux
KDE Plasma Version: 5.21.3
KDE Frameworks Version: 5.80.0
Qt Version: 5.15.2
Comment 1 Alexander M. 2021-04-03 09:15:33 UTC 
Turns out that this behavior is not limited to Kickoff's Search box, but is rather an issue with every single Qt text area on my system: Dolphin's address bar, the search box in System Settings, even the Search boxes in non-KDE (but still Qt) applications like qBittorrent. It's just that I hadn't noticed so far, because I never had any reason to try and use a language other than English in these other applications, while in Kickoff's search box I do (in order to search for documents and stuff).

Hmmm. Now that I think about it, I really can't believe I didn't notice this earlier, since I just realized it happens in Krunner as well, which is used in much the same way as Kickoff's search box (searching for documents and stuff).

So it apparently is a Qt5 bug/feature? Should I be reporting this somewhere else? Or maybe I should just surrender myself to the idea that Fcitx and IMEs in general will never Just Work™ in KDE... :P
Comment 2 Nate Graham 2021-04-06 03:00:14 UTC 
Since Dolphin and Plasma are both affected and use different Qt-derived UI toolkits (QtWidgets and QtQuick, respectively) I would say that this is either a local configuration problem, a bug in fcitx, or a bug somewhere in Qt.

Either way, CCing the fcitx maintainer. :)
Comment 3 Alexander M. 2021-04-09 15:57:57 UTC 
Apparently it's not an Fcitx bug because I just tested this with IBus instead of Fcitx and that doesn't work either. Further, it doesn't even work in Libreoffice when running under KDE with its kde/qt5 VCL. So yeah, everything so far points to this being some kind of Qt bug.
Comment 4 Alexander M. 2021-04-10 11:22:43 UTC 
Alright, I'm glad to report that as of today this has been magically fixed. I'm not exactly sure what fixed it; the only relevant package update was qt5-base earlier today, which on Arch includes the newly released KDE patch set for Qt5, which now that I think about it kind of makes sense, as this patch set is both a newly introduced ingredient in my previously-working KDE setup *and* is also a component of Qt, which I already suspected of being the culprit.

In any case, problem fixed.