Description: Under Wayland, when the cursor is in the input line of LibreOffice Calc, doing anything that follows will cause LibreOffice Calc to crash immediately: - Using the hotkey (meta+space) to toggle the fcitx input method; - Trying to input anything when any input method of fcitx is enabled. However, toggling the fcitx input method with tray icon does not trigger the crash, although attempting to input anything afterwards will cause it to crash. This bug does not happen under X11. This bug does not happen at any places other than the input line. Steps to Reproduce: 1. Install Wayland and fcitx (along with any input methods) 2. Open LibreOffice Calc and click on the input line 3. Press the hotkey (meta+space) to toggle the input method Actual Results: LibreOffice Calc crashes Expected Results: It should not crash Reproducible: Always User Profile Reset: Yes Additional Info: Version: 24.2.1.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.1-4 Calc: threaded Operating System: Arch Linux KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.8.1-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × Intel® Core™ i7-10875H CPU @ 2.30GHz Memory: 15.5 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics Manufacturer: LENOVO Product Name: 82AX System Version: Lenovo Legion Y7000P2020H The following message will be shown in the terminal when crashing: [destroyed object]: error 0: width and height must be positive and non-zero The Wayland connection experienced a fatal error: 协议错误 (协议错误 means protocol error)
Couldn't reproduce with LO 24.2.1.2 using kf5 (cairo+wayland), fcitx 4.2.9.8-5, Ubuntu 22.04 + GNOME 42.9 Michael, maybe you have an idea?
(In reply to Huanyu Liu from comment #0) > Steps to Reproduce: > 1. Install Wayland and fcitx (along with any input methods) > 2. Open LibreOffice Calc and click on the input line > 3. Press the hotkey (meta+space) to toggle the input method On Debian testing, pressing meta+space doesn't toggle for me after just installing, then manually killing ibus and running the `fcitx` command, setting up 2 additional input methods (German, Japanese) after right-clicking the entry in the panel. Ctrl+Space shows some popup mentioning German, but otherwise seems to have no effect, and no crash. I'm not a regular fcitx user. Can you describe in more detail how to set this up if the above is not enough? Is this specific to any particular input methods? > The following message will be shown in the terminal when crashing: > [destroyed object]: error 0: width and height must be positive and non-zero > The Wayland connection experienced a fatal error: 协议错误 > > (协议错误 means protocol error) Can you please collect + attach a backtrace? https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU/Linux:_How_to_get_a_backtrace Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8950105f2e140f199518b8b637504706a84e3c6a CPU threads: 12; OS: Linux 6.6; UI render: default; VCL: kf5 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
(In reply to Michael Weghorn from comment #2) > On Debian testing, pressing meta+space doesn't toggle for me after just > installing, then manually killing ibus and running the `fcitx` command, > setting up 2 additional input methods (German, Japanese) after > right-clicking the entry in the panel. > Ctrl+Space shows some popup mentioning German, but otherwise seems to have > no effect, and no crash. Sorry, Meta+Space is my customized hotkey (because Ctrl+Space is used frequently in lots of applications); the default one is indeed Ctrl+Space... > I'm not a regular fcitx user. Can you describe in more detail how to set > this up if the above is not enough? > Is this specific to any particular input methods? I've just installed GNOME and managed to get fcitx to work. Well, everything works perfectly and it seems to be a bug specific to KDE... fcitx is not shipped with any "usable" input methods---only keyboard layouts. You need to install extra packages for "usable" input methods. I'm using Rime (for Chinese) and Mozc (for Japanese), and both will make LibreOffice Calc crash, so I think it's not specific to particular input methods. To get fcitx to work for KDE under Wayland, you need to set the virtual keyboard in the system settings to fcitx and then do log-out-and-log-in. (fcitx will warn you for this if it's your first time to run it) By the way, fcitx is specifically designed for KDE; GNOME users will be more likely to use ibus. > Can you please collect + attach a backtrace? > https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU/Linux: > _How_to_get_a_backtrace Strangely, LibreOffice Calc dies silently and returns zero, leaving no backtrace at all...
(In reply to Huanyu Liu from comment #3) > Strangely, LibreOffice Calc dies silently and returns zero, leaving no > backtrace at all... Correction: it returns 255, not 0. Still no backtrace.
(In reply to Huanyu Liu from comment #3) > I've just installed GNOME and managed to get fcitx to work. Well, everything > works perfectly and it seems to be a bug specific to KDE... Can you try whether starting LO with environment variable SAL_USE_VCLPLUGIN=gtk3 works in a KDE Plasma session as well (please double-check that "Help" -> "About LibreOffice" says "VCL: gtk3" then. > fcitx is not shipped with any "usable" input methods---only keyboard > layouts. You need to install extra packages for "usable" input methods. I'm > using Rime (for Chinese) and Mozc (for Japanese), and both will make > LibreOffice Calc crash, so I think it's not specific to particular input > methods. > > To get fcitx to work for KDE under Wayland, you need to set the virtual > keyboard in the system settings to fcitx and then do log-out-and-log-in. > (fcitx will warn you for this if it's your first time to run it) Thanks. It's somehow not offered for me in the virtual keyboard section in KDE system settings, but what works for me is to kill ibus, start fcitx, and start LO with environment variable QT_IM_MODULE=fcitx set. Still no crash for me when switching to mozc then (now also using a customized Super+Space shortcut), and typing Japanese characters also works fine. What version of fcitx are you using? The one I tested is Debian package with version 1:4.2.9.9-1 (i.e. major version 4), but there's also a fcitx5 package (version 5.1.7-1) available that I haven't tried so far. > > _How_to_get_a_backtrace > > Strangely, LibreOffice Calc dies silently and returns zero, leaving no > backtrace at all... Does that mean you still get the crash the same way as before, but there's no backtrace or is the behavior already different earlier?
(In reply to Michael Weghorn from comment #5) > Can you try whether starting LO with environment variable > SAL_USE_VCLPLUGIN=gtk3 works in a KDE Plasma session as well (please > double-check that "Help" -> "About LibreOffice" says "VCL: gtk3" then. With the environment variable SAL_USE_VCLPLUGIN=gtk3, LO does not crash anymore and everything works as expected. By the way, in a previous version (half a month ago) of LO, setting it to kf6 will make any component of LO unable to save anything as a new file, so I set it to kf5 as a workaround. Now it seems that this bug has been fixed. However, setting it kf6 will also cause the crash described here. > Thanks. It's somehow not offered for me in the virtual keyboard section in > KDE system settings, but what works for me is to kill ibus, start fcitx, and > start LO with environment variable QT_IM_MODULE=fcitx set. > Still no crash for me when switching to mozc then (now also using a > customized Super+Space shortcut), and typing Japanese characters also works > fine. > > What version of fcitx are you using? The one I tested is Debian package with > version 1:4.2.9.9-1 (i.e. major version 4), but there's also a fcitx5 > package (version 5.1.7-1) available that I haven't tried so far. I'm using fcitx5 with version 5.1.8-1 in the Arch Linux repository. It seems that fcitx4 (no suffix in the package name) has been discontinued, but not removed from the repository. > Does that mean you still get the crash the same way as before, but there's > no backtrace or is the behavior already different earlier? LO Calc still crashes with return code 255, but doesn't leave any backtrace.
(In reply to Huanyu Liu from comment #6) > (In reply to Michael Weghorn from comment #5) > > > Can you try whether starting LO with environment variable > > SAL_USE_VCLPLUGIN=gtk3 works in a KDE Plasma session as well (please > > double-check that "Help" -> "About LibreOffice" says "VCL: gtk3" then. > > With the environment variable SAL_USE_VCLPLUGIN=gtk3, LO does not crash > anymore and everything works as expected. > > By the way, in a previous version (half a month ago) of LO, setting it to > kf6 will make any component of LO unable to save anything as a new file, so > I set it to kf5 as a workaround. Now it seems that this bug has been fixed. These were bugs in KF6, fixed in the meantime, see tdf#159701 for details. > However, setting it kf6 will also cause the crash described here. Does it work with kf5 instead? > I'm using fcitx5 with version 5.1.8-1 in the Arch Linux repository. It seems > that fcitx4 (no suffix in the package name) has been discontinued, but not > removed from the repository. Good to know. I might retry with that on my Debian testing if it also happens with kf5, otherwise need to switch to a VM that has Plasma 6.
(In reply to Michael Weghorn from comment #7) > > However, setting it kf6 will also cause the crash described here. > > Does it work with kf5 instead? No. Setting SAL_USE_VCLPLUGIN to either kf5 of kf6 will cause the crash, but gtk3 will not. > > I'm using fcitx5 with version 5.1.8-1 in the Arch Linux repository. It seems > > that fcitx4 (no suffix in the package name) has been discontinued, but not > > removed from the repository. > > Good to know. I might retry with that on my Debian testing if it also > happens with kf5, otherwise need to switch to a VM that has Plasma 6. I didn't remember experiencing this bug before upgrading to Plasma 6 (using Plasma 5 + KF5), so maybe it's a bug specific to Plasma 6.
[Automated Action] NeedInfo-To-Unconfirmed
Update: Apart from the input line of LO Calc, the same crash is also found to happen in the comment region of Writer, Draw and Impress, but NOT in the comment region of Calc.
(In reply to Huanyu Liu from comment #10) > Update: Apart from the input line of LO Calc, the same crash is also found > to happen in the comment region of Writer, Draw and Impress, but NOT in the > comment region of Calc. I've retested with fcitx5 on Debian testing now (package fcitx5 5.1.7-1), but still cannot reproduce a crash with either the Calc input line or comments in Writer when using the kf5 VCL plugin. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1e2de7ffd0a41c716f12f41d95ad7a462d120c6d CPU threads: 12; OS: Linux 6.6; UI render: default; VCL: kf5 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
Update 2: The same crash is also found to happen in the input region of LO Math.
After some investigation, I think I've found out the root causes of this crash! (Yeah, root cause*s* indeed...) First, I tried to search for the error message "width and height must be positive and non-zero" and finally found it here: https://invent.kde.org/plasma/kwin/-/blob/master/src/wayland/xdgshell.cpp#L863-L879 It seems that this error will be triggered when you are attempting to set the size of something to a non-positive value, and the error message is KWin-exclusive. Then, I launched LO with `WAYLAND_DEBUG=1` and reproduced the crash. When toggling fcitx in the main region of LO Writer, the following logs were produced: [3215568.634] -> xdg_wm_base@3.create_positioner(new id xdg_positioner@51) [3215568.638] -> xdg_positioner@51.set_anchor_rect(209, 310, 1, 1) [3215568.641] -> xdg_positioner@51.set_anchor(6) [3215568.643] -> xdg_positioner@51.set_gravity(8) [3215568.644] -> xdg_positioner@51.set_size(62, 71) [3215568.646] -> xdg_positioner@51.set_constraint_adjustment(9) When toggling fcitx in the comment region of LO Writer, the following logs were produced (and then crashed): [3215568.677] -> xdg_wm_base@39.create_positioner(new id xdg_positioner@57) [3215568.681] -> xdg_positioner@57.set_anchor_rect(0, 0, 1, 0) [3215568.684] -> xdg_positioner@57.set_anchor(6) [3215568.701] -> xdg_positioner@57.set_gravity(8) [3215568.703] -> xdg_positioner@57.set_size(62, 71) [3215568.705] -> xdg_positioner@57.set_reactive() [3215568.706] -> xdg_positioner@57.set_constraint_adjustment(9) Note that `set_anchor_rect(0, 0, 1, 0)` will indeed trigger the error message mentioned above. I thought that these logs are related to fcitx positioning its candidate window and found the relevant code here: https://github.com/fcitx/fcitx5-qt/blob/master/qt5/platforminputcontext/fcitxcandidatewindow.cpp#L496-L590 According to the code of fcitx5-qt, it is indeed difficult to reproduce this crash... You have to use KWin, Qt>=6.6.0, fcitx5-qt and Wayland all at the same time... By the way, fcitx5-qt is not completely adapting to Qt6, but adding patches for Qt6 to the existing Qt5 code, so the relevant code is in the qt5 directory. fcitx5-qt is roughly doing the following things: (1) Request the current cursor position of the "host" window from Qt; (2) Convert it to the native coordinate; (3) Clamp the cursor position within the window if it is out of bound; (4) Show the candidate window at the (possibly clamped) cursor position. However, there is a bug at Step (3) such that only the width is properly handled (while the height is possibly set to 0 thus causing the crash). Actually, the clamping process is seldom encountered, so most of the time everything goes OK. I'll report this bug to fcitx5-qt later. At the LO side, the problem is that the cursor position is not correctly reported to Qt at certain places (input line of Calc, comment region of Writer & Draw & Impress and input region of Math). Actually, the cursor is not blinking at (and only at) these places; this might be related to the crash. Under X11, LO does not crash, but the candidate window of fcitx is indeed displayed at the wrong position. This is not the case when using `SAL_USE_VCLPLUGIN=gtk3` under Wayland, so it should be a Qt-exclusive issue.
I opened a new issue for fcitx5-qt: https://github.com/fcitx/fcitx5-qt/issues/60
(Moved to tdf#160838, as the description is no longer accurate.)
(In reply to Huanyu Liu from comment #14) > I opened a new issue for fcitx5-qt: > https://github.com/fcitx/fcitx5-qt/issues/60 Thanks a lot for the excellent analysis and even suggesting how to fix the cause of the crash, which I see has been applied upstream now! And thanks for moving the remaining issue to a separate bug, that's helpful.
Thank you both! Changing resolution to "not our bug" as a more appropriate one. https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/RESOLVED#MOVED