Created attachment 180815 [details] A Screencast Demonstrating How To Consistently Reproduce This SUMMARY When I invoke a submenu, then directly switch a menu, that menu is unnecessarily limited in height. It appears to be limited to the height of the previous menu, but since I've solely one example to test with, IDK. STEPS TO REPRODUCE 1. Invoke "Education" > "Science" with two entries. 2. Invoke "Games" or "Development", when they contain more than two entries (each). OBSERVED RESULT The next context menu is limited in height, causing it to render a scroll bar. EXPECTED RESULT The context menu's height should adapt to its content, as it does otherwise. SOFTWARE/OS VERSIONS > Operating System: Fedora Linux 42 > KDE Plasma Version: 6.3.4 > KDE Frameworks Version: 6.13.0 > Qt Version: 6.9.0 > Kernel Version: 6.14.4-300.fc42.x86_64 (64-bit) > Graphics Platform: Wayland
Can reproduce.
*** Bug 488197 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/3023
Git commit bf2cfe5f31c2837966178fb951c3f5cb1d824501 by Christoph Wolk. Committed on 27/05/2025 at 18:32. Pushed by cwo into branch 'master'. applets/kicker: fix Plasma.dialog being inappropriately resized Kicker reuses the current level's cascading popup when a new one is opened, rather than creatinga completely new one. This usually works out but fails if the submenu itself has a submenu - the submenu gets resized correctly, but afterwards is resized again to its previous size. The specific cause seems to be the subsubmenu hiding itself, if we instead wait until it is destroyed on the next event loop clear, the resizing doesn't happen. So let's not hide it. This seems to be fast enough even on old computers to not lead to perceptible lingering subsubmenus, and even if it did happen in some rare situations, this would seem preferable to having a menu that's the wrong size long-term. M +0 -1 applets/kicker/package/contents/ui/ItemListDialog.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/bf2cfe5f31c2837966178fb951c3f5cb1d824501
Git commit 01f8cbbbc111d67e709ec9616cdb158d60e245b0 by Christoph Wolk. Committed on 27/05/2025 at 19:34. Pushed by cwo into branch 'Plasma/6.4'. applets/kicker: fix Plasma.dialog being inappropriately resized Kicker reuses the current level's cascading popup when a new one is opened, rather than creatinga completely new one. This usually works out but fails if the submenu itself has a submenu - the submenu gets resized correctly, but afterwards is resized again to its previous size. The specific cause seems to be the subsubmenu hiding itself, if we instead wait until it is destroyed on the next event loop clear, the resizing doesn't happen. So let's not hide it. This seems to be fast enough even on old computers to not lead to perceptible lingering subsubmenus, and even if it did happen in some rare situations, this would seem preferable to having a menu that's the wrong size long-term. (cherry picked from commit bf2cfe5f31c2837966178fb951c3f5cb1d824501) Co-authored-by: Christoph Wolk <cwo.kde@posteo.net> M +0 -1 applets/kicker/package/contents/ui/ItemListDialog.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/01f8cbbbc111d67e709ec9616cdb158d60e245b0
This bug still exists and is reproducible on current release version. There is a timing dependence and possibly the previous attempt at a fix made it less likely to occur under ideal circumstances, but when thermal throttling kicks in and CPU runs at a few hundred MHz then it becomes very apparent the underlying issue is NOT fixed.
Please try again in Plasma 6.6 once that is out - I could in edge cases still reproduce it after that patch, but I can't reproduce it anymore after intense reworking of the popup sizing that have already landed in the dev branch of 6.6.