Tudor Brindus 7d52b4d0b5 xwayland/selection: ignore requests for anything but the newest data ... Our internal state machine gets screwed up if selection events are not monotonically increasing in time, and we can enter a self-copy loop from the proxy window that exhausts all pipes. Snippet of logs when this occurs: 00:00:46.238 [wlr] [xwayland/selection/incoming.c:487] XCB_XFIXES_SELECTION_NOTIFY (selection=277, owner=4194626) 00:00:46.238 [wlr] [xwayland/selection/incoming.c:487] XCB_XFIXES_SELECTION_NOTIFY (selection=277, owner=2097153) 00:00:46.238 [wlr] [xwayland/selection/outgoing.c:378] XCB_SELECTION_REQUEST (time=58979563 owner=2097153, requestor=2097153 selection=277, target=279, property=278) 00:00:46.238 [wlr] [xwayland/selection/outgoing.c:397] ignoring old request from timestamp 58979563; expecting > 58979563 00:00:46.238 [wlr] [xwayland/selection/outgoing.c:29] SendEvent destination=2097153 SelectionNotify(31) time=58979563 requestor=2097153 selection=277 target=279 property=0 00:00:46.238 [wlr] [xwayland/selection/incoming.c:453] XCB_SELECTION_NOTIFY (selection=277, property=0, target=279) Note that 2097153 is `selection->window`, and 4194626 is Emacs. The race occurs if the selection owner changes back to our proxy window between when we get `XCB_XFIXES_SELECTION_NOTIFY` for Emacs and when we call `xcb_convert_selection` in `incoming.c:source_send` -- the ConvertSelection request can end up hitting our proxy window, but the timestamp will be rejected. Fixes #2192.		2021-02-15 13:50:14 +01:00
..
dnd.c	xwayland/selection: use one target window per selection	2021-02-04 17:06:14 +01:00
incoming.c	xwayland/selection: use one X11 window per incoming transfer	2021-02-04 13:33:59 +01:00
outgoing.c	xwayland/selection: ignore requests for anything but the newest data	2021-02-15 13:50:14 +01:00
selection.c	xwayland/selection: use one target window per selection	2021-02-04 17:06:14 +01:00