SUMMARY The issue is particularly evident with those applications that use a lot of context menus with submenus. The context menus' submenus are quite often misplaced, at time very far away from their corresponding parent menu, at times partially below it. This makes using these applications a bit frustrating. A typical application showing the problem is Libreoffice (tried with the kf5 VCL - the default on KDE). STEPS TO REPRODUCE 1. Open application using context menus with submenus (e.g. libreoffice) 2. Open a context menu by right clicking 3. Go to an entry that has a submenu and open it OBSERVED RESULT The submenu is often misplaced EXPECTED RESULT The submenu should open to the side of its parent menu SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2 Kernel Version: 6.12.12-2-MANJARO (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-4750HQ CPU @ 2.00GHz Memory: 15.5 GiB of RAM Graphics Processor: Mesa Intel® Iris® Pro Graphics P5200 Manufacturer: Notebook Product Name: W740SU ADDITIONAL INFORMATION - may be related to bug https://bugs.kde.org/show_bug.cgi?id=488208 - may be related to the way in which the wayland protocols work: I am learning that wayland prevents applications from deciding where to position their windows and that all the transient windows must be transient for the top one which is different from X11 where in a 2 level menu, the secondary menu is attached to the first level, not to the parent window...
Thank you for the bug report! Please note that Plasma 6.2.5 will not be supported for much longer by KDE; supported versions are 5.27., and 6.3 or newer. Please upgrade to the latest version as soon as your distribution makes it available to you. Plasma is a fast-moving project, and bugs in one version are often fixed in the next one.
I can reproduce this myself on git master, and have been able to for a while; I shamefully never reported it. Easy way to reproduce: 1. tile a Dolphin window to the right side of the screen 2. Click the hamburger menu button (if it's not visible, press Ctrl+M to hide the main menubar) 3. Hover over any menu item that has a child menu It can be quite an annoying usability issue since with the parent menu partially covered up, it''s hard to go to another menu lower down in the list.
This is a Qt bug. It provides bad positioning information for popups.
Is there a Qt bug number to follow?
Two; I put them in the "See Also" field at the top of the bug report.
Sorry for missing them. Do you think https://bugs.kde.org/show_bug.cgi?id=488208 might also be a Qt problem?
I don't know; I'll let KWin developers make that determination.
Sorry if this appears as a bit of an aside, here, but I am trying to collect information to make a more appropriate report. LibO developers have closed the corresponding issue on their application indicating that also https://bugs.kde.org/show_bug.cgi?id=488208 is a Qt5 bug. Now the interesting bit is that they say that the bug is present on distros like arch that build Qt5 almost unpatched from the sources in the KDE repository https://invent.kde.org/qt/qt/qt5 which I understand is a repo where KDE accumulates Qt5 patches that do not make it upstream. Conversely, they say that the bug *is not present* on debian derivatives, that build Qt5 from the upstream Qt sources carrying a large number of debian-specific downstream patches (most of which, I would say, are from the KDE repo). See: https://bugs.documentfoundation.org/show_bug.cgi?id=148019#c9 > It's unclear to me why the bug doesn't show on Debian these days > (while I could reproduce there in the past), but still does on Arch. > It might e.g. be Debian has a different set of patches applied So a fix may be already floating around, remaining missed because of the quirky development model of Qt5 where at this point there seems to be no full agreement on what should be considered "upstream" and on who should review and apply patches, so that patches remain downstream-only and may get lost. So my questions are: - What is the current development model of Qt5? Is it now happening at Qt or at KDE via a soft fork? I understand it got moved at KDE because Qt stopped releasing updates to Qt5, is it still the case? - Is there a tracker to report bugs for the KDE Qt5 tree?
Obviously, another possibility is that you do not see the issue in debian because debian might still be at plasma 5. So it may be the case that a bug in Qt5 is only triggered on the latest Kwin and not in the Kwin that was shipped in plasma5.
Update: some more tests have been carried out by a LibO user/developer that is on debian testing. The issue of LibO menus getting a window title when on the Qt5 or kf5 VCL is not present in debian testing even on Plasma6 and in other window managers. Looking into this would be precious since even if plasma has migrated to Qt6, there is still a huge amount of software that is Qt5. Libreoffice itself is trying to move to Qt6 for its Qt VCLs, but its official upstream binaries are still Qt5 only.