Commit Graph

20 Commits

Author SHA1 Message Date
Tudor Brindus 2118a3ce47 xwayland/selection: flush connection after changing xwm selection owner
This was the actual underlying cause of #2192; we were not getting the
XFIXES_SELECTION_NOTIFY event in time.
2021-02-15 13:50:14 +01:00
Tudor Brindus 2fa257313a xwayland/selection: use one target window per selection
Previously, the clipboard and primary selections shared the same window.
This was racey, and could have led to pasting failures.

On xfixes selection owner change notification, the logic for requesting
the supported mimetypes of the new owner's selection looks like:

  xcb_convert_selection(
    xwm->xcb_conn,
    selection->window,
    selection->atom,
    xwm->atoms[TARGETS],
    xwm->atoms[WL_SELECTION],
    selection->timestamp
  );

This means ask the selection owner to write its TARGETS for the
`selection->atom` selection (one of PRIMARY, CLIPBOARD, DND_SELECTION)
to `selection->window`'s WL_SELECTION atom.

However, `selection->window` is shared for both PRIMARY and CLIPBOARD
selections, and WL_SELECTION is used as the target atom in both cases.
So, there's a race when both selections change at the same time.

The CLIPBOARD selection might support mimetypes {A, B, C}, and the
PRIMARY only {A, B}. If the ConvertSelection requests/responses "cross
on the wire", so to speak, wlroots can end up believing that the PRIMARY
selection also supports C.

A Wayland client may then ask for the PRIMARY selection in C format,
which will fail with "convert selection failed".

This commit fixes this by using a separate window for PRIMARY and
CLIPBOARD target requests, so that WL_SELECTION can be used as the
target atom in both cases.
2021-02-04 17:06:14 +01:00
Tudor Brindus 7964a313e8 xwayland/selection: use one X11 window per incoming transfer
This commit introduces logic for using a new X11 window for each
incoming transfer, rather than having a global window for each selection
source.

This eliminates a whole class of bugs involving multiple concurrent
incoming transfers.

For now, we retain the outgoing transfer queue, and the selection
source-specific windows to support it. Source-specific windows are no
longer used in the incoming path, and will be removed in a future PR.

Refs #1497.
2021-02-04 13:33:59 +01:00
Tudor Brindus dd4c8aa45e xwayland/selection: make xwm_selection_init take a wlr_xwm_selection *
This makes it consistent with xwm_selection_finish.
2021-01-31 19:17:04 +01:00
Tudor Brindus b3d782f818 xwayland/selection: introduce `xwm_selection_transfer_init`
Currently, all this does is initialize `wl_client_fd` to -1, so that
comparisons with 0 are meaningful.
2021-01-31 19:17:04 +01:00
Tudor Brindus aa86a022fa xwayland/selection: make xwm_selection_finish take a wlr_xwm_selection *
Previously it took a wlr_xwm *, which was a bit surprising in that it
freed members of wlr_xwm *, not just its respective selections.
2021-01-31 19:17:04 +01:00
Tudor Brindus b6ba595862 xwayland/selection: destroy all selections on Xwayland restart
Previously, Xwayland could restart, and we'd get events for transfers
pointing to the previous (now freed) xwm instance. This led to
use-after-free segfaults.

Closes #2565.
2021-01-31 10:24:59 +01:00
Tudor Brindus 211c1e23be xwayland/selection: end incr transfer on empty prop, not next selection
Previously, `transfer->incr` was being cleared on the next selection.
However, if the next selection was *also* incremental, it's possible
that `xwm_handle_selection_property_notify` would route us to
`xwm_get_incr_chunk` instead of `xwm_selection_get_data`.
2021-01-29 10:18:03 +01:00
Tudor Brindus 703c17ae41 xwayland/selection: refactor remaining incremental transfer code 2021-01-29 10:18:03 +01:00
Tudor Brindus 23148d283f xwayland/selection: extract out property requests
Apart from reducing duplication, this has the positive side-effect of
allowing all deallocs to use
`xwm_selection_transfer_destroy_property_reply`, as opposed to the
latter and a mix of ad-hoc `free`s.
2021-01-29 10:18:03 +01:00
Tudor Brindus e75f483aeb xwayland/selection: rename Wayland-facing data and helpers
Previously, wlr_xwm_selection_transfer.source_fd meant:

- the source of data in a Wayland -> X11 copy (good)
- the destination of data in a X11 -> Wayland copy (confusing)

This made reading through xwayland/selection/incoming.c difficult: in
many places, "source" actually means "destination".
2021-01-25 21:02:55 +01:00
emersion 4cb0697e57 data-device, primary-selection: add request_set_selection
This makes compositors able to block and/or customize set_selection requests
coming from clients. For instance, it's possible for a compositor to disable
rich selection content (by removing all MIME types except text/plain). This
commit implements the design proposed in [1].

Two new events are added to wlr_seat: request_set_selection and
request_set_primary_selection. Compositors need to listen to these events and
either destroy the source or effectively set the selection.

Fixes https://github.com/swaywm/wlroots/issues/1138

[1]: https://github.com/swaywm/wlroots/issues/1367#issuecomment-442403454
2019-01-24 11:38:23 +01:00
emersion 06467d2e12
primary-selection: add a serial argument
The serial needs to be bumped when X11 clients set the selection, otherwise
some Wayland clients (e.g. GTK) will overwrite it when they gain focus.
2019-01-21 19:23:40 +01:00
emersion 9f0720c03a
primary-selection: introduce wlr_primary_selection_source
This is a common interface that can be used for all primary selection
protocols, as discussed in [1]. A new function wlr_seat_set_primary_selection
is added to set the primary selection for all protocols.

The seat now owns again the source, and resets the selection to NULL when
destroyed.

[1]: https://github.com/swaywm/wlroots/issues/1367#issuecomment-442403454
2018-11-29 19:40:28 +01:00
emersion f001f98cef
gtk-primary-selection: refactor everything, untie from seat
This commits completely refactors wlr_gtk_primary_selection. The goal is to
remove gtk-primary-selection state from the seat and better handle inert
resources where it makes sense.

wlr_seat_client.primary_selection_devices has been removed and replaced by
wlr_gtk_primary_selection_device. This allows us to make offers inert when the
current selection is replaced.

wlr_seat_set_primary_selection has been removed because it relied on wlr_seat
instead of wlr_gtk_primary_selection_device_manager. A new function,
wlr_gtk_primary_selection_device_manager_set_selection (candidate for the
longest function name in wlroots) has been added. It doesn't take a serial
anymore as serial checking only makes sense for set_selection requests coming
from Wayland clients (serial checking is now done in the Wayland interface
implementation).

Since wlr_gtk_primary_selection_device_manager is now required to set the
selection, a new function wlr_xwayland_set_gtk_primary_selection_device_manager
(candidate number two for longest function name) has been added.

Devices are now made inert when the seat goes away.

Future work includes removing the last primary selection bits from the seat,
mainly wlr_seat.primary_selection_source and wlr_seat.events.primary_selection,
replacing those with new fields in wlr_gtk_primary_selection_device. Or maybe
we could keep those in the seat and replace them with a re-usable interface
(for future zwp_primary_selection_v1 support). We need to think how we'll sync
these three protocols (GTK, X11 and wayland-protocols).

See https://github.com/swaywm/wlroots/issues/1388
2018-11-27 18:57:26 +01:00
emersion 811a4d997b
Rename wlr_primary_selection to wlr_gtk_primary_selection 2018-11-23 11:58:56 +01:00
emersion 2d0c5ec78e
Use _POSIX_C_SOURCE, use shm_open 2018-11-06 08:29:23 +01:00
emersion 7cbef15206
util: add wlr_ prefix to log symbols 2018-07-09 22:49:54 +01:00
emersion 71ca45e2c0
Make sure we don't use others' prefixes 2018-04-25 23:24:58 +01:00
emersion 591ea27cf9
xwayland: refactor selection code 2018-04-03 12:56:54 -04:00