bhrebec/xwayland-satellite
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

fix: do not change owner on SelectionClear

Browse source 
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.
This commit is contained in:
En-En 2025-10-21 12:24:09 +00:00 • committed by Supreeeme
parent 34bf07db05
commit e991cb39c2
1 changed files with 6 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

13
src/xstate/selection.rs
View file

@ -267,6 +267,7 @@ trait SelectionDataImpl {
server_state: &mut RealServerState,
) -> bool;
fn atom(&self) -> x::Atom;
fn selection_clear(&mut self);
}
impl<T: SelectionType> SelectionData<T> {
@ -325,6 +326,10 @@ impl<T: SelectionType> SelectionDataImpl for SelectionData<T> {
}
}
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 {