SUMMARY Submenus do not appear immediately when the mouse hovers over them. This happens with both the global menu in the decoration. It happens in both Wayland and X11 STEPS TO REPRODUCE 1. Add the global menu panel or the appmenu button in the decoration 2. Scroll to an item that opens a submenu (those with a > sign) OBSERVED RESULT the submenu does not open. It is necessary to pass a second time, or click EXPECTED RESULT the submenu should open on mouseover SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 6.4.1 KDE Frameworks Version: 6.15.0 Qt Version: 6.9.1 Kernel Version: 6.16.0-rc4-1-MANJARO (64-bit) Graphics Platform: X11 (the bug is present also on Wayland) Processors: 8 × 11th Gen Intel® Core™ i5-1135G7 @ 2.40GHz Memory: 16 GiB of RAM (15.3 GiB usable) Graphics Processor: Intel® Iris® Xe Graphics
I might add that the same problem occurs with the decoration I maintain https://github.com/guiodic/material-decoration and which uses its own libdbusmenuqt
Created attachment 182862 [details] video
Hmm do you know whether lidbusmenuqt actually attempts to show a submenu? libdbusmenuqt is an IPC-heavy library, it won't be surprising if some async bits are mishandled.
(In reply to Vlad Zahorodnii from comment #3) > Hmm do you know whether lidbusmenuqt actually attempts to show a submenu? > libdbusmenuqt is an IPC-heavy library, it won't be surprising if some async > bits are mishandled. Everything worked fine with Plasma 6.3.
(In reply to Guido from comment #4) > (In reply to Vlad Zahorodnii from comment #3) > > Hmm do you know whether lidbusmenuqt actually attempts to show a submenu? > > libdbusmenuqt is an IPC-heavy library, it won't be surprising if some async > > bits are mishandled. > > Everything worked fine with Plasma 6.3. Hmm I saw this issue in Plasma 6.3 too. But I don't know where the bug is.
The only difference might be that I ran a dev version of Qt.
(In reply to Vlad Zahorodnii from comment #6) > The only difference might be that I ran a dev version of Qt. Yes, that could be the problem, a bug in Qt6.
It looks like https://github.com/qt/qtbase/commit/353ce5344fbde5a6cecbdd2c131e1cf0f4b7f383 added some guards for showing empty menus. However, the QMenu in libdbusmenuqt kind of relies on populating QMenu's asynchronously, i.e. show an empty sub-menu and then add actions later. I think the issue can be worked around by prefetching the next level of menu items.
(In reply to Vlad Zahorodnii from comment #8) > It looks like > https://github.com/qt/qtbase/commit/353ce5344fbde5a6cecbdd2c131e1cf0f4b7f383 > added some guards for showing empty menus. However, the QMenu in > libdbusmenuqt kind of relies on populating QMenu's asynchronously, i.e. show > an empty sub-menu and then add actions later. I think the issue can be > worked around by prefetching the next level of menu items. Makes sense. I presume this is related to the bug in search inside the menu, too.
(In reply to Vlad Zahorodnii from comment #8) > It looks like > https://github.com/qt/qtbase/commit/353ce5344fbde5a6cecbdd2c131e1cf0f4b7f383 > added some guards for showing empty menus. However, the QMenu in > libdbusmenuqt kind of relies on populating QMenu's asynchronously, i.e. show > an empty sub-menu and then add actions later. I think the issue can be > worked around by prefetching the next level of menu items. What do you think of this solution? https://github.com/guiodic/material-decoration/commit/9ef1f37cfafc489cb4be3e6251eb25c29574c53a
(In reply to Guido from comment #10) > (In reply to Vlad Zahorodnii from comment #8) > > It looks like > > https://github.com/qt/qtbase/commit/353ce5344fbde5a6cecbdd2c131e1cf0f4b7f383 > > added some guards for showing empty menus. However, the QMenu in > > libdbusmenuqt kind of relies on populating QMenu's asynchronously, i.e. show > > an empty sub-menu and then add actions later. I think the issue can be > > worked around by prefetching the next level of menu items. > > What do you think of this solution? > > https://github.com/guiodic/material-decoration/commit/ > 9ef1f37cfafc489cb4be3e6251eb25c29574c53a In 6.5, plasma will likely adopt a slightly different way to handle QMenu objects. https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5688#note_1275314 The global menu applet would load the second level ahead of time (for better responsiveness), and also add a placeholder action just in case. In my testing, I haven't noticed any issues with submenu anymore. Regarding the linked patch, I'm not sure how exactly it fixes the bug.
(In reply to Vlad Zahorodnii from comment #11) > (In reply to Guido from comment #10) > > (In reply to Vlad Zahorodnii from comment #8) > > > It looks like > > > https://github.com/qt/qtbase/commit/353ce5344fbde5a6cecbdd2c131e1cf0f4b7f383 > > > added some guards for showing empty menus. However, the QMenu in > > > libdbusmenuqt kind of relies on populating QMenu's asynchronously, i.e. show > > > an empty sub-menu and then add actions later. I think the issue can be > > > worked around by prefetching the next level of menu items. > > > > What do you think of this solution? > > > > https://github.com/guiodic/material-decoration/commit/ > > 9ef1f37cfafc489cb4be3e6251eb25c29574c53a > > In 6.5, plasma will likely adopt a slightly different way to handle QMenu > objects. > https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/ > 5688#note_1275314 > > The global menu applet would load the second level ahead of time (for better > responsiveness), and also add a placeholder action just in case. In my > testing, I haven't noticed any issues with submenu anymore. > > Regarding the linked patch, I'm not sure how exactly it fixes the bug. It installs an EventFilter, it's just a workaround for my decoration, but I think it can also be applied to Plasma. Anyway, it works and doesn't give any more trouble. But surely the solution you have in store for Plasma 6.5 is better.