Created attachment 183873 [details] demo and clipboard selection monitor **Bug Description** When an XWayland application attempts to write to the clipboard while KWin currently holds clipboard data provided by a Wayland-native application, a focus change occurring during the write process will often cause the write to fail. More precisely, the write is overwritten by `kwin_wayland`. **Reproduction Demo** I wrote a demo application to reproduce this issue: * The **main window** monitors and displays the current clipboard content. * It contains a **button** that opens a popup window for writing to the clipboard. * Clicking the button opens a window with a text input field and a button, prompting the user to enter some text. * After entering text, pressing the button writes the text to the clipboard and closes the popup window, causing a focus change. **Observed Behavior** * If the clipboard initially contains content copied from a **Wayland-native** application, after performing the above steps, there is a high probability that the main window still shows the old Wayland-provided clipboard content instead of the newly written text. * If we first use `xclip` to set the clipboard to something written by an **XWayland** application and then repeat the steps, the main window correctly shows the new text every time. **Additional Investigation** I also wrote a **clipboard selection monitor**. When the clipboard contains Wayland-provided content: * The clipboard selection is briefly owned by the demo, but is then immediately re-owned by `kwin_wayland`. When the clipboard contains XWayland-provided content: * This re-ownership does not occur. Looking into KWin’s source code, I found that: * When KWin receives a **selection change** from an XWayland client, it does not update the selection immediately. https://github.com/KDE/kwin/blob/e39731feabc643db9c5a6d8c945c29209a047158/src/xwayland/clipboard.cpp#L117 * Instead, it waits until a **selection property change** event is received to obtain a new offer and update the selection. https://github.com/KDE/kwin/blob/e39731feabc643db9c5a6d8c945c29209a047158/src/xwayland/clipboard.cpp#L133 * Between these two events, other events (e.g., focus changes) can occur. * If the focus changes before the new offer is obtained, `kwin_wayland` calls `checkWlSource`, which writes the Wayland-side clipboard content back into XWayland, overwriting the new content from the XWayland application. https://github.com/KDE/kwin/blob/e39731feabc643db9c5a6d8c945c29209a047158/src/xwayland/clipboard.cpp#L73 **Attachments** 1. The demo application described above. * Depends on Qt6 Widgets and is built with CMake. 2. The clipboard selection monitor program. * Depends on libxcb, libxcb-xfixes, and libxcb-res. * Can be built with: ```bash g++ clipboard_xres_with_targets.cpp -o xcb_clipboard_monitor -lxcb -lxcb-xfixes -lxcb-res ```
In progress with https://invent.kde.org/plasma/kwin/-/merge_requests/7990
Git commit 3976a8c08695ad0f3c1d10b410b44a72599dddae by Vlad Zahorodnii. Committed on 06/10/2025 at 13:25. Pushed by vladz into branch 'Plasma/6.5'. xwayland: Decouple selection sync'ing from focus changes The current selection should be unaffected by the active window. For example, if a client sets a selection and then active window changes, that selection should still remain set. The current selection should only change when it's set explicitly (either by an X or a Wayland client). Regarding snooping clipboard contents, our SelectionRequest handler has a guard to protect us against that case. (cherry picked from commit 947d2c5ad0746d807b04f6bb382e1d4ddb1b7f29) M +9 -51 src/xwayland/clipboard.cpp M +0 -6 src/xwayland/clipboard.h M +8 -49 src/xwayland/primary.cpp M +0 -6 src/xwayland/primary.h https://invent.kde.org/plasma/kwin/-/commit/3976a8c08695ad0f3c1d10b410b44a72599dddae