Created attachment 137949 [details] Klipper menu inside a regular window SUMMARY On Wayland, pressing shortcut to "open klipper at mouse position" will open a menu inside a window (with title-bar and borders) if Klipper was started by/inside notification area on Latte (dock / panel). STEPS TO REPRODUCE 1. Start KDE Plasma Wayland session; 2. Start Latte dock with an layout containing notification area widget inside a latte dock / latte panel; (be sure that isn't any other notification area widget on another plasma panel or another instance of klipper running besides the one started inside latte dock) 3. Press shortcut to "open Klipper at mouse position" OBSERVED RESULT A Window will be opened (with tittle-bar and borders) containing a menu listing clipboard contents. EXPECTED RESULT A menu should be opened (without title-bar or borders) listing clipboard contents on this menu. SOFTWARE/OS VERSIONS Platform: Linux (Arch Linux) QT: 5.15.2+kde+r180-1 Desktop: KDE Plasma 5.21.4 (Wayland) ADDITIONAL INFORMATION If not using Latte dock, but regular plasma panel, pressing shortcut to "open klipper at mouse position" will open a menu at mouse position, without title-bar or borders.
May be related to Bug #430662
Confirmed. It probably needs a transient parent set.
bug 435013 is related
Tested from git master: This bug also affects klipper on default Plasma panel, not only Latte dock. If any window is focused, pressing "open klipper at mouse position" shortcut will open klipper with window decorations AND AT WRONG POSITION (not at mouse position) as reported by Bug 435013. If desktop is focused (e.g. click at desktop first), klipper will open once without window decoration and at the correct mouse position but, interspersed, closing klipper list and pressing shortcut again will than open klipper once at the wrong position and with window decorations. The expected behavior is: - When pressing the shortcut, klipper will always open without window decoration and always at the mouse position, not mattering if the focus is at some window or at desktop.
*** Bug 437624 has been marked as a duplicate of this bug. ***
Regarding comment 4: From my testing, opening the klipper menu after clicking the desktop works repeatedly. I've seen a similar alternating menu/window behavior - as was reported in the comment - in gwenview's tag editor combo box, where opening it once will show a menu and opening it a second time will show a window. This was documented in bug #438153.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1527
*** Bug 450793 has been marked as a duplicate of this bug. ***
*** Bug 435013 has been marked as a duplicate of this bug. ***
Git commit 338772ca404e35ee54d98ba6c8c8f5b9224b6d0f by David Redondo. Committed on 06/05/2022 at 07:27. Pushed by davidre into branch 'master'. Open Klipper under mouse also on wayland On Wayland if Plasma had no focus when the shortcut was invoked - the menu window is created as toplevel because it has no parent and there is no current focusWindow - the application can't know the currrent cursor position We use a newly introduced request on plasma_surface to open under the cursor. As it can only be called before mapping a buffer to a surface, the menu is hidden before being shown again. FIXED-IN:5.25 M +1 -0 klipper/CMakeLists.txt M +34 -1 klipper/klipper.cpp M +11 -0 klipper/klipper.h https://invent.kde.org/plasma/plasma-workspace/commit/338772ca404e35ee54d98ba6c8c8f5b9224b6d0f
Git commit 0521870150184769045e6bcec460ff87313d10c8 by David Redondo. Committed on 06/05/2022 at 07:27. Pushed by davidre into branch 'master'. klipper: Set FramelessWindowHint When Plasma does not have focus on Wayland, we can't avoid Qt creating a xdg_toplevel. It will get a decoration by default by KWin. Setting the flag avoids this. M +1 -0 klipper/klipper.cpp https://invent.kde.org/plasma/plasma-workspace/commit/0521870150184769045e6bcec460ff87313d10c8
This causes Plasma to crash when I invoke the menu using Meta+V. See Bug 453578.