SUMMARY On wayland the appmenu dos not have the behaviour expected and is unasable. STEPS TO REPRODUCE 1. configure the decoration to have the appmenu 2. Click on the appmenu 3. and try to interact with one of the some items OBSERVED RESULT menu is detached on an external windows and it is difficult to interact with it EXPECTED RESULT having the menu in the windows and easily used SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.16.4 (available in About System) KDE Plasma Version: 5.16.4 KDE Frameworks Version: 5.61.0 Qt Version: 5.13 ADDITIONAL INFORMATION
Can you please provide a screenshot?
Created attachment 122476 [details] menu was expected to not be detached by the way, spectacle was not able to take a screenshot of that problem (no possible to take delayed screenshot as one of the problem) so I took it with my phone.
@vlad xdg_popup menus by protocol definition need to have parent toplevel. Qt has a "failsafe" that if you create a window of type popup without a parent it will raise it to be a toplevel to be spec compliant. Neither of that matters as it's in the wrong position anyway. We can't do internal hacks as the the menu is shown from kded, because (pre-wayland irony) we didn't want kwin to turn into a monolith of having all these things. Given showing a remote menu is by definition remote, we could move the menu code into Kwin. Alternatively we could use the plasmashell protocol in kded to explicitly override decorations and set a position.
*** Bug 426614 has been marked as a duplicate of this bug. ***
Created attachment 132444 [details] Screenshot Still an issue in Plasma 5.20.0 / Framework 5.75.0. Here's a screenshot from me which shows the exact difference.
*** Bug 428820 has been marked as a duplicate of this bug. ***
Seeing this here on wayland on live-git frameworks/plasma (updated just a few hours ago) too. A partial workaround is creating a window rule: Matching: Window class: Exact Match: kded5 org.kde.kded5 Match whole window class: Yes Window type: Normal Window title: Exact Match: KDE Daemon Size & Position: Initial placement: Force: Under Mouse That at least gets the window near where it should be. However, it still has a titlebar, and the window rule no-titlebar option is buggy, see (my) bug #429168. Further and I believe related (and not fixed by the above window rule), the menu behavior with a pointer is buggy. The selection won't reliably stay under the pointer and attempting to navigate to a submenu most often results in both the submenu and original menu closing, forcing a re-click of the appmenu in the titlebar. To work around that I'm often forced to keyboard-navigate the appmenu, except AFAIK there's no hotkey set and no way to set one to trigger the appmenu itself (alt-F for example to trigger the file submenu may or may not work, depending on the app), so that must be done by pointer-click, after which one can keyboard-navigate.
*** This bug has been marked as a duplicate of bug 430662 ***