https://bugs.documentfoundation.org/show_bug.cgi?id=173230
Bug ID: 173230
Summary: gtk3 on Wayland loses every second copy - LibreOffice
clears the selection before re-claiming it and the
clipboard manager wins the gap
Product: LibreOffice
Version: 25.8.5.2 release
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: LibreOffice
Assignee: [email protected]
Reporter: [email protected]
Blocks: 100156, 108843
Description:
On Wayland with the gtk3 VCL plugin, every second Ctrl+C from a Writer document
is lost. The clipboard keeps the previously copied text and the newly copied
text never reaches the clipboard at all, so it also never appears in the
clipboard manager's history. It is not intermittent and not a timing accident:
it is deterministically every second copy, which is why the common workaround
"just press Ctrl+C again" appears to work and then fails again on the next
copy.
Steps to reproduce:
1. KDE Plasma 6.6.5 Wayland session, Klipper at default settings (its "Prevent
empty clipboard" option is on by default).
2. Start LibreOffice Writer with SAL_USE_VCLPLUGIN=gtk3 (native Wayland, not
XWayland).
3. Select some text in the document, press Ctrl+C, paste into another
application. Works.
4. Select DIFFERENT text in the same document, press Ctrl+C, paste again.
Actual result: step 4 pastes the text from step 3. The text selected in step 4
is not on the clipboard and does not appear in the clipboard manager history.
Repeating step 4 works, the one after that fails again, and so on.
Expected result: each Ctrl+C places the current selection on the clipboard.
Root cause:
LibreOffice takes two different paths depending on whether it already owns the
clipboard. When it does not own it, it creates the data source and claims the
selection in one step, and that always works. When it already owns the
clipboard - which is exactly the case after a successful copy from the same
document - it first sends wl_data_device.set_selection(nil), destroys its data
source, and only about 11-16 ms later creates the new source and claims the
selection again. During that window the clipboard is empty, a clipboard manager
with a "prevent empty clipboard" feature restores the previous entry, and its
restore is processed after LibreOffice's new claim. The compositor then cancels
LibreOffice's fresh data source and LibreOffice does not retry.
Captured with WAYLAND_DEBUG=1 on the LibreOffice process. Working copy,
LibreOffice does not own the clipboard:
[1137632.482] -> wl_data_device_manager#9.create_data_source(new id
wl_data_source#67)
[1137632.509] -> wl_data_device#28.set_selection(wl_data_source#67, 5239)
[1137634.104] wl_data_device#28.selection(wl_data_offer#4278190080)
[1137634.125] wl_data_source#67.send("text/plain;charset=utf-8", fd 28)
Failing copy, LibreOffice already owns the clipboard:
[1142839.580] -> wl_data_device#28.set_selection(nil, 5297)
[1142839.589] -> wl_data_source#67.destroy()
[1142850.221] wl_data_device#28.selection(nil)
[1142850.252] wl_data_device#28.selection(wl_data_offer#4278190082)
[1142850.290] -> wl_data_device_manager#9.create_data_source(new id
wl_data_source#67)
[1142850.318] -> wl_data_device#28.set_selection(wl_data_source#67, 5297)
[1142852.166] wl_data_source#67.cancelled()
[1142852.173] -> wl_data_source#67.destroy()
The difference between the two is exactly the leading set_selection(nil). Note
that the failing sequence is otherwise identical and uses the same input serial
(5297) for both the nil and the real claim, so this is not a stale serial
problem.
Suggested fix:
Do not send the intermediate nil selection when replacing clipboard contents.
Claiming the new selection replaces the old one by itself, and destroying the
old source afterwards is sufficient. SDL fixed the same class of problem this
way in commit dfcbd16b4c7b1666eaa2e45b51a0ab9657ae3fed, whose commit message
reads: "Sending a nil selection followed by immediately destroying the
selection offer is redundant, and avoiding intermediate nil offers helps some
clipboard managers avoid potential race conditions." The LibreOffice case is
worse than SDL's, because here the nil is sent while replacing rather than
while clearing, so the gap does not merely confuse the clipboard manager - it
causes the newly copied data to be discarded.
Workaround for affected users: SAL_USE_VCLPLUGIN=kf6. The Qt backend claims the
selection in one step and never sends the intermediate nil. Verified over
repeated copies: the selection is claimed once each time and
wl_data_source.cancelled() never occurs.
Note that turning off the clipboard manager's "prevent empty clipboard" option
does NOT help. Tested: the protocol sequence including the cancellation was
byte-for-byte identical afterwards.
Version information:
LibreOffice 25.8.5.2 580(Build:2), packages libreoffice-core / libreoffice-gtk3
4:25.8.5-0tux1
GTK 3.24.41-4ubuntu1.3, libwayland-client 1.24.0
KWin / plasma-workspace 6.6.5, Wayland session
TUXEDO OS (Ubuntu 24.04 base), kernel 7.0.0-108029-tuxedo
Referenced Bugs:
https://bugs.documentfoundation.org/show_bug.cgi?id=100156
[Bug 100156] [META] Wayland-related bugs
https://bugs.documentfoundation.org/show_bug.cgi?id=108843
[Bug 108843] [META] Clipboard bugs and enhancements
--
You are receiving this mail because:
You are the assignee for the bug.
