SUMMARY When opening some of the children of the toolbars menus they sometimes seem to open in standalone windows with a window header (minimize, maximize, close) STEPS TO REPRODUCE 1. Click on the toolbar item "View" 2. Move the cursor over some if the items which have child menus (i.e. those with a right chevron ">") OBSERVED RESULT The submenu sometimes opens in a standalone window EXPECTED RESULT The submenu should just be another layer in the main window SOFTWARE/OS VERSIONS Operating System: Fedora Linux 41 KDE Plasma Version: 6.3.2 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.12.15-200.fc41.x86_64 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 7840U w/ Radeon 780M Graphics Memory: 30.6 GiB of RAM Graphics Processor: AMD Radeon 780M
Created attachment 179053 [details] Video showing the strange child menu behavior
Thanks for the report, the video shows the issue well. Not something that can be fixed on Okteta side. On first thought this would be an issue of the window manager interacting with the widget toolkit on the menu window flags? So moving to kwin maintainers so they hopefully can find out if this is their side or perhaps upstream Qt5/Wayland issue... KWin maintainers: please note Okteta is still Qt5 domain.
One thing you can check is that the menu has the proper widget parent - if Qt can't figure out which (toplevel or popup) window the popups are supposed to attach to, it'll create a toplevel window instead of a popup. Qt 6 has better heuristics for figuring out which window a popup was supposed to be attached to, but it's best if the problem is properly fixed on the application side.
Closer observation reveals that this happens exactly when one popup should be shown while another one is still open. If I always wait for the previous popup to disappear (e.g. by moving the mouse to an entry which does not have children) then this problem never appears. This can even be seen in the video
(In reply to Zamundaaa from comment #3) > One thing you can check is that the menu has the proper widget parent This here is about menus part of the main menu bar menus tree. Those submenus are QMenus queried from QAction entries in QMenus plugged into QMenuBar. I guess the popup is controlled by QMenu::internalDelayedPopup(), and there the menu widget relation internally seems to be trracked by "d->activeMenu->d_func()->causedPopup.widget = this;". Many, if not all, of the submenus which seem affected by what people had observed are provided by KSelectAction. That one creates an internal QMenu instance, which it sets to itself via QAction::setMenu(). So there is no widget parent to this menu instance by default. And those QMenu instances will be accessed from QMenu containers which have those actions as entries, as by above referenced QMenu::internalDelayedPopup(). More precisely, the KSelectAction instances themselves are added to the QMainWindow's QMenuBar in one of the QMenu instances as created by KXmlGui's logic in Okteta's case. The KSelectionActions are owned by internal QObject instances, possibly not reachable from QMainWindow object child tree, so only lent into the menu's manifests. I connected to the QMenu::aboutToShow signal, and parentWidget is a nullptr at the time. KWin developers, would you know any data bits to set to help the heuristics you mentioned? Given the added observation "happens exactly when one popup should be shown while another one is still open" I suspect though perhaps some data lookup fails somewhere on the client or server side of the wayland protocols?