Commit Graph

355 Commits

Author SHA1 Message Date
Manuel Stoeckl 79be26ff1f xwayland/xwm: make atom_map const 2021-02-05 10:04:20 +01:00
Tudor Brindus 3d46d3f7a1 xwayland/selection: allow simultaneous Wayland-to-X11 transfers
There seems to be no reason why we can't service multiple Wayland-to-X11
transfers concurrently, so long as they are to different windows (or
possibly, same windows but different target properties?)

This commit removes the queuing logic, but retains the request
de-duplication from #2428.
2021-02-04 17:16:43 +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 3417fc0cca xwayland/selection: don't leak Wayland fd if ConvertSelection fails
If our ConvertSelection failed, we would previously leak the pending
Wayland client fd.

Refs swaywm/sway#5946.
2021-01-31 10:24:53 +01:00
Tudor Brindus e0dfc14983 xwayland/selection: don't request another selection while one is pending
This will hopefully be fixed in the future by having separate windows
for each X11-to-Wayland transfer, but until then, let's avoid a
compositor crash.
2021-01-31 10:24:47 +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 dea94f2bad xwayland/selection: simplify incremental transfer control flow
Previously, if the Wayland client died before an incremental transfer
was complete, the logs would be spammed by "write error to target fd" as
wlroots entered some control flow wherein it'd continually try
scheduling further writes to the already-dead pipe.

This commit contains no behavioral changes, but introduces explicit
handling for draining the X11 selection in case of Wayland client death.
2021-01-29 10:18:03 +01:00
Tudor Brindus 10a2d57055 xwayland/selection: explicitly bail if first write to Wayland fd fails
If `xwm_data_source_write` failed, it's failed permanently. In fact, a
failing `xwm_data_source_write` sets `transfer->property_reply` to
null as part of its error handling.

Instead of relying on an indirect check (whether
`transfer->property_reply` is still non-null), explicitly use the return
value from `xwm_data_source_write`.
2021-01-29 10:18:03 +01:00
Tudor Brindus 40b2e7669a xwayland/selection: make `xwm_data_source_write` return 0 on failure
The `fd` is marked `O_NONBLOCK`, so `write` will never spuriously return
`EINTR`. Therefore, `write` failing is permanent, and we can return 0 to
make the return value meaningful.
2021-01-29 10:18:03 +01:00
Simon Ser f8a66072e7 xwayland: fix extraneous NET_WM_STATE log messages
wlroots would log "Unhandled NET_WM_STATE property change" log
messages for atoms we know about. Simplify the code structure
and remove these extra messages.
2021-01-28 12:03:50 +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
Tudor Brindus 0db191d3bf xwayland/selection: prevent fd leak on unsupported MIME type
Since we never end up calling xcb_convert_selection, the file descriptor
ends up getting leaked (i.e., not cleaned up within
xwm_data_source_write).
2021-01-25 09:46:20 +01:00
Tudor Brindus abb56152ff xwayland: use wlr_log_errno instead of %m
Previously, any error would be masked by an internal isatty call:

  24:31:48.174 [DEBUG] [wlr] [xwayland/selection/incoming.c:386] XCB_SELECTION_NOTIFY (selection=277, property=278, target=256)
  24:31:48.174 [ERROR] [wlr] [xwayland/selection/incoming.c:30] write error to target fd: Inappropriate ioctl for device
2021-01-25 09:22:04 +01:00
BrassyPanache d6649a8a4b Expose ICCCM input status
In certain situations windows can have their input field set to false
but still expect to receive input focus by passively listening to key
presses via a parent window. The ICCCM specification outlines how focus
should be given to clients.

Further reading: https://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7

Relates to #2604
2021-01-20 10:38:58 +01:00
Chris Chamberlain 6af748171a Free xwayland cursor in wlr_xwayland_destroy
One of many memory leaks detected by an asan build
2021-01-17 12:28:55 +01:00
Simon Ser 7036dceb0e xwayland: remove protocol debug messages
Developers can use x11trace or similar to analyze the protocol messages.
2021-01-10 11:29:36 +01:00
Isaac Freund 6c08fe9796 xwayland: avoid crash on repeated server_finish_display() call
This function may end up being called more than once if the Xwayland
binary does not exist on the system.
2020-12-19 10:39:31 +01:00
Simon Ser e57a52e7f7
Remove inline keyword
The compiler is smarter at figuring out whether a function should be
inlined or not.
2020-12-15 13:49:42 +01:00
Dominik Honnef 431ec52b9c xwayland: use pipe instead of SIGUSR1 to signal readiness
Closes: https://github.com/swaywm/wlroots/issues/2154
2020-12-07 12:24:56 +01:00
Simon Ser 50b5f8558e
xwayland: add -core to flags
Xwayland has its own special handling for signals like SIGSEGV/SIGABRT.
Instead of leaving the job to the OS, it tries to walk up the call stack
(badly, because a lot of information is missing), print the stack trace
to stdout, then exit(1). This is very annoying because it prevents
Xwayland crashes from being easily debugged.

Xwayland has a flag "-core" that aborts instead of exiting. This allows
the OS to generate a coredump. It's far from perfect but better than
nothing, I guess.
2020-12-02 11:49:57 +01:00
Ilia Bozhinov d2329ac07a xwm: add wlr_xwayland_surface_restack() 2020-11-30 11:29:28 +01:00
Simon Ser be1e7647c3 xwayland: log unhandled NET_WM_STATE property changes 2020-11-03 18:36:30 +02:00
Simon Ser 1fdaaf697a
xwayland: minor code style fixes 2020-11-03 15:31:23 +01:00
Tudor Brindus 5217456b50 xwayland: fix minor typo in debug log
This accidentally slipped through 1b0e4c7.
2020-10-20 09:09:49 +02:00
Ilia Bozhinov 99f3c643bf xwayland: add set_geometry event
This is necessary to react to changes in position of override-redirect
views.
2020-10-14 21:49:51 +02:00
Tudor Brindus afeb941ca0 xwayland: notify requestor when we fail to respond to their request
We already mostly did this, but there were a couple of branches
(`calloc` failures) where we'd bail without letting the other side know.

Refs swaywm/sway#4007. Likely not going to be a real improvement there
(if `calloc` fails you're already pretty screwed), but it does address a
theoretical possibility.
2020-10-13 09:02:20 +02:00
Tudor Brindus 7bb9d48dd1 xwayland: remove stale transfers from the same requestor
It seems that if we ever try to reply to a selection request after
another has been sent by the same requestor (we reply in FIFO order),
the requestor never reads from it, and we end up stalling forever on a
transfer that will never complete.

It appears that `XCB_SELECTION_REQUEST` has some sort of singleton
semantics, and new requests for the same selection are meant to replace
outstanding older ones. I couldn't find a reference for this, but
empirically this does seem to be the case.

Real (contrived) case where we don't currently do this, and things break:

* run fcitx
* run Slack
* wl-copy < <(base64 /opt/firefox/libxul.so)  # or some other large file
* focus Slack (no need to paste)

fcitx will send in an `XCB_SELECTION_REQUEST`, and we'll start
processing it. Immediately after, Slack sends its own. fcitx hangs for a
long, long time. In the meantime, Slack retries and sends another
selection request. We now have two pending requests from Slack.

Eventually fcitx gives up (or it can be `pkill`'d), and we start
processing the first request Slack gave us (FIFO). Slack (Electron?)
isn't listening on the other end anymore, and this transfer never
completes. The X11 clipboard becomes unusable until Slack is killed.

After this patch, the clipboard is immediately usable again after fcitx
bails. Also added a bunch of debug-level logging that makes diagnosing
this sort of issue easier.

Refs swaywm/sway#4007.
2020-10-12 10:53:42 +02:00
Tudor Brindus 1b0e4c7e6e xwayland: introduce WLR_XWAYLAND for specifying which Xwayland to use
When debugging Xwayland-related issues, a common first step in debugging
has been to ask the reporter to move their real Xwayland to
/usr/bin/Xwayland.bin, and create a shell script starting Xwayland with
extra arguments under the original /usr/bin/Xwayland location.

Introducing a `WLR_XWAYLAND` environment variable makes this less
invasive, by allowing the user to swap out Xwayland without resorting to
global system changes (or source patches).
2020-10-11 09:00:52 +02:00
Tudor Brindus feb0e1c74d xwayland: fix use-after-free in selection handling
Fixes #2425.

wlroots can only handle one outgoing transfer at a time, so it keeps a
list of pending selections. The head of the list is the currently-active
selection, and when that transfer completes and is destroyed, the next
one is started.

The trouble is when you have a transfer to some app that is misbehaving.
fcitx is one such application. With really large transfers, fcitx will
hang and never wake up again. So, you can end up with a transfer list
that looks like this:

| T1: started | T2: pending | T3: pending | T4: pending |

The file descriptor for transfer T1 is registered in libwayland's epoll
loop. The rest are waiting in wlroots' list.

As a user, you want your clipboard back, so you `pkill fcitx`. Now
Xwayland sends `XCB_DESTROY_NOTIFY` to let us know to give up. We clean
up T4 first.

Due to a bug in wlroots code, we register the (fd, transfer data
pointer) pair for T1 with libwayland *again*, despite it already being
registered. We do this 2 more times as we remove T3 and T2.

Finally, we remove T1 and `free` all the memory associated with it,
before `close`-ing its transfer file descriptor.

However, we still have 3 copies of T1's file descriptor left in the
epoll loop, since we erroneously added them as part of removing T2/3/4.
When we `close` the file descriptor as part of T1's teardown, we
actually cause the epoll loop to wake up the next time around, saying
"this file descriptor has activity!" (it was closed, so `read`-ing would
normally return 0 to let us know of EOF).

But instead of returning 0, it returns -1 with `EBADF`, because the file
descriptor has already been closed. And finally, as part of error-handling
this, we access the transfer pointer, which was `free`'d. And we crash.
2020-10-11 08:59:08 +02:00
Tudor Brindus ab80ad902e xwayland: using %m in `wlr_log` is broken, use `wlr_log_errno` instead
This one was awful to track down, but calls to `wlr_log` with %m have
the errno masked by the `isatty` call in `log_stderr`. Switch them to
`wlr_log_errno` instead.

Cue quality "how can read(2) POSSIBLY be returning ENOTTY?" moments.
2020-10-11 06:36:23 +02:00
Rouven Czerwinski 5012121d33 xwm: add loop detection for read_surface_parent
Implement a simple loop detection while trying to retrieve the parent
for a TRANSIENT_FOR window.

Fixes swaywm/sway#4624
2020-10-08 19:32:58 +02:00
Ilia Bozhinov 3e03f786ee xwayland: disconnect display destroy listener even if xwayland didn't initialize 2020-09-04 17:55:23 +02:00
Ilia Bozhinov 74f7be7287 xwayland: do not allow apps to change focus after wlroots request 2020-07-30 13:40:36 +02:00
Scott Moreau 6d0ee53e1a xwm: Set _NET_WM_STATE_FOCUSED property for the focused surface
Certain clients require this property to be set for expected behavior.
Most notably, steam client CSD maximize button no longer worked
after unmaximizing once, unless the state was changed by another
method. The state is unset whenever another surface gains focus.
2020-07-27 14:26:30 +02:00
Antonin Décimo 1ae2d976c0 xwayland: free server in error path 2020-07-27 10:49:19 +02:00
Antonin Décimo d9bb792794 Fix incorrect format parameters 2020-07-27 10:49:19 +02:00
Simon Ser c72efcd1ce xwayland/xwm: use initializer for props in xsurface_set_wm_state
This avoids uninitialized items and makes it clear where the magic
number 2 is coming from.
2020-07-22 13:49:24 -06:00
Simon Ser 13f35139d3 xwayland/xwm: add prop count assert in xsurface_set_net_wm_state
This helps mitigate buffer overflows.
2020-07-22 13:49:24 -06:00
Simon Ser cd4827b3b6 xwayland/xwm: don't insert surface in list on error
In case wl_event_loop_add_timer errors out, don't insert the free'd
wlr_xwayland_surface in the list.

Closes: https://github.com/swaywm/wlroots/issues/1721
2020-07-22 13:48:59 -06:00
Tobias Langendorf bd387da62d xwm: add support for xwayland minimize 2020-07-21 13:20:17 +02:00
John Chadwick 58bcec9d94 xwm: end transfers when the requestor is destroyed
This improves the failure cases when incremental transfers fail to
complete successfully for one reason or another.
2020-07-03 09:42:36 +02:00
Scott Moreau b1a47245a1 xwm: Destroy xwm on hangup or error
If Xwayland is restarted, the ready handler assumes there is no xwm instance.
This means all of xwm was leaked on Xwayland restart. This caused compositors
to consume all cpu resources, where time is spent dispatching. Now we destroy
xwm if we get an event mask containing WL_EVENT_HANGUP or WL_EVENT_ERROR.
2020-06-30 21:21:25 +02:00
Scott Moreau 84d2f30faa xwayland: Don't discard ready signals
The xwayland ready signals are used to do initial setup like starting xwm.
Discarding the signals means that the handler functions will not be called
in the case that Xwayland is restarted and thus, xwm managed clients fail.

Fixes #2174."
2020-06-30 21:21:25 +02:00