From e991cb39c202c3ee861246fad340efd90ffb727d Mon Sep 17 00:00:00 2001 From: En-En <39373446+En-En-Code@users.noreply.github.com> Date: Tue, 21 Oct 2025 12:24:09 +0000 Subject: [PATCH] fix: do not change owner on SelectionClear The SelectionClear event was previously calling `handle_new_owner`, which relies on `SelectionClear` being sent only after a `SetSelectionOwner` event. Even so, the `XFixes::SelectionEvent::SetSelectionOwner` event already handles this (and more obviously so). The result was that whenever Wayland owned the X selection and X took it back, `handle_new_owner` would be called twice, as would all of the machinery involved in acquiring a selection. This behavior manifests as a bug if Wayland quickly reclaims ownership of the selection, which can cause the selection event to be cancelled before getting the SelectionNotify response is received, resulting in an empty Wayland selection. --- src/xstate/selection.rs | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/src/xstate/selection.rs b/src/xstate/selection.rs index f2cdbee..39b1f33 100644 --- a/src/xstate/selection.rs +++ b/src/xstate/selection.rs @@ -267,6 +267,7 @@ trait SelectionDataImpl { server_state: &mut RealServerState, ) -> bool; fn atom(&self) -> x::Atom; + fn selection_clear(&mut self); } impl SelectionData { @@ -325,6 +326,10 @@ impl SelectionDataImpl for SelectionData { } } + fn selection_clear(&mut self) { + self.current_selection = None; + } + fn handle_new_owner( &mut self, connection: &xcb::Connection, @@ -722,13 +727,7 @@ impl XState { match event { xcb::Event::X(x::Event::SelectionClear(e)) => { let data = get_selection_data!(e.selection()); - data.handle_new_owner( - &self.connection, - self.wm_window, - &self.atoms, - e.owner(), - e.time(), - ); + data.selection_clear(); } xcb::Event::X(x::Event::SelectionNotify(e)) => { if e.property() == x::ATOM_NONE {