Version: 6.3.0.0.alpha0+ Build ID: 2ee85baac60dde5238e42483d610edf28fcffc6b CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: kde5; Locale: en-GB (en_GB.UTF-8); UI-Language: en-US Calc: threaded Version: 6.3.0.0.alpha0+ Build ID: 12edea426a31f57a9d5b1c65b34fb1336c5534e9 CPU threads: 1; OS: Linux 4.18; UI render: default; VCL: kde5; Locale: en-GB (en_GB.UTF-8); UI-Language: en-US Calc: threaded Steps to reproduce: 0) Start a Wayland session of KDE Plasma 1) start LibreOffice Writer 2) Hover mouse pointer over some tolbar icon, e.g. the one for printing or PDF export 3) Observe what happens 4) click the toolbar icon Results: for 3): Nothing seems to happen. Tooltip is not shown. for 4): Tooltip is shown while left-clicking the icon (i.e. start appearing when pressing the mouse button and disappears on release) Expected result: Tooltip should show up in step 2/3 above. Notes: * This is not reproducible when using X11 instead of Wayland. * This works when using the gtk3 VCL plugin on Wayland instead. * It works as expected with toolbar icons e.g. in kdiff3 (other KDE/KF5 application, self-built from source).
On pc Debian x86-64 with master sources updated today, I could reproduce this. Indeed, with only kde5+wayland (not kde5+x11)
I can confirm this - it looks like hovering (= getting the cursor position without any buttons pressed) is just generally broken with wayland.
(In reply to Fabian Vogt from comment #2) > I can confirm this - it looks like hovering (= getting the cursor position > without any buttons pressed) is just generally broken with wayland. True. I've examined this a bit, will add more details here.
Created attachment 151309 [details] Demo patch to add some debug output This patch adds some debug output that is generated when moving the mouse. For the X11 case, the output is contantly generated while moving the mouse. For the Wayland case, this only happens when a mouse button is pressed, which is the reason why hovering is broken as described by Fabian.
As far as I understand, the underlying issue is a Qt bug and I've created an upstream issue about this, s. more details there: https://bugreports.qt.io/browse/QTBUG-75766 The problem goes away when commenting out the following line in Qt5Frame constructor for testing (s. [1]): m_aSystemData.aWindow = m_pQWidget->winId(); As described at [2], the call to 'QWidget::winId()' forces "the old behavior with native windows" where the described issue occurs (s. Qt bug report). Removing that totally is certainly not a good idea, though, this is at least used for the video playback via GStream etc. in Impress. Removing it would break that and lead to a crash for the X11 case as well (doesn't work on Wayland as of now). Wayland probably needs another implementation, though, since the result of 'QWidget::winId()' probably doesn't help much anyway. S. also commit c0d4f3ad3307c "implement wayland handle passing for gstreamer" for gtk3. [1] https://gerrit.libreoffice.org/plugins/gitiles/core/+/caa6de6c97b0c2fc82c6a2699a1e84b9d2eb9dbd/vcl/qt5/Qt5Frame.cxx#158 [2] https://doc.qt.io/qt-5/qwidget.html#native-widgets-vs-alien-widgets
Change in Gerrit: https://gerrit.libreoffice.org/#/c/72164/ Separate bug report for video playback: bug 125219
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/0e3c3b842e14b9646d3697cf1266be21359e0f13%5E%21 tdf#122293 qt5: Use "alien widgets" by default on Wayland It will be available in 6.3.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.