https://bugs.kde.org/show_bug.cgi?id=525861
UsharbiSin <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] See Also| |https://github.com/hluk/Cop | |yQ/pull/3742 --- Comment #5 from UsharbiSin <[email protected]> --- I’d like to link a CopyQ-side fix relevant to this report, which has now been merged: - PR: [CopyQ #3742 — Fix Wayland clipboard MIME data lifetime during slow reads](https://github.com/hluk/CopyQ/pull/3742) - Commit: [73b9fe63a43a73d14ba4750bcb042d42b66a1583](https://github.com/hluk/CopyQ/commit/73b9fe63a43a73d14ba4750bcb042d42b66a1583), merged into master on October 9. The relevant trigger was in CopyQ’s `ClipboardDataGuard`: after a clipboard read exceeded 100 ms, it called `QCoreApplication::processEvents()` while still retaining a borrowed MIME-data pointer. On the KGuiAddons Wayland path, processing those events can execute the deferred clipboard-mutex unlock. This allows the background clipboard thread to replace and destroy the offer while CopyQ is still using its MIME data. Thus, there is synchronization in KGuiAddons, but CopyQ could prematurely release that protection by processing events during the read. The fix removes `processEvents()` from the clipboard-read path. The same PR also fixes a related GNOME extension issue: a slow client’s notification timeout must not unregister it and stop subsequent clipboard updates. Regression tests were added for MIME-data lifetime during slow reads, deferred clipboard changes, and GNOME notification timeouts. Focused checks passed on X11 and native Wayland, including GNOME with an XWayland clipboard source. Slow-read and clipboard-replacement tests also confirmed that subsequent copies continued to appear in the history. -- You are receiving this mail because: You are watching all bug changes.
