https://bugs.kde.org/show_bug.cgi?id=508004
Bug ID: 508004
Summary: XWayland application somtimes failed to write
clipboatd with focus changed
Classification: Plasma
Product: kwin
Version First master
Reported In:
Platform: Arch Linux
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: xwayland
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Created attachment 183873
--> https://bugs.kde.org/attachment.cgi?id=183873&action=edit
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
```
--
You are receiving this mail because:
You are watching all bug changes.
