Commit Graph

375 Commits

Author SHA1 Message Date
Tudor Brindus 6605d7c390 xwm: prevent X11 clients from blowing our stack by opening too many windows
Allocate window arrays for list property updates on the heap instead.
2021-05-31 10:41:29 +02:00
Tudor Brindus ae2f3ecb68 xwm: implement _NET_CLIENT_LIST_STACKING
This property is present on all modern X11 instances. The nonpresence of
it requires applications to fall back to XQueryTree-based logic to
determine stacking logic (e.g., to determine what surface should get
Xdnd events).

These code paths are effectively untested nowadays, so this makes it
more likely for wlroots to "break" applications. For instance, the
XQueryTree fallback path has been broken in Chromium for the last 10
years.

It's easy enough to maintain this property, so let's just do it.

Fixes #2889.
2021-05-31 10:41:29 +02:00
Tudor Brindus 699d724000 xwm: use correct list link when iterating over `unpaired_surfaces` 2021-05-31 10:41:29 +02:00
Thomas Weißschuh 9f211b5dd4 xwayland: actually use Xwayland from pkg-config
eec2e1d3b1 introduced logic to use the Xwayland
binary discovered via pkg-config.
While the newly introduced checks correctly used the binary from pkg-config,
the actual execution still used the previous PATH-search logic.
2021-05-12 10:55:15 +02:00
Aleksei Bavshin e48dcdf72c xwayland: remove _NET_WM_PID handler
We already get the PID from XRes and _NET_WM_PID code can overwrite it
with incorrect data.
2021-04-23 09:55:01 +02:00
Aleksei Bavshin e0f239fa28 xwayland: query window PIDs via XResQueryClientIds
`_NET_WM_PID` is unreliable: it is optional and even if set it may
contain PIDs from sandbox namespaces or remote systems.
Prefer XRes v1.2 QueryClientIds method which returns PIDs as seen by the
Xwayland server.
2021-04-23 09:55:01 +02:00
Ryan Farley d87ede0d69 xwayland/sockets: ensure proper permissions
Create a private UNIX socket directory (755), or use an existing one but
ensure proper permissions are set to prevent meddling from other users.
2021-04-16 11:53:05 +02:00
Simon Ser 1eb38e0015 Remove WLR_HAS_XCB_ERRORS
wlroots' dependency on this library doesn't change the features
exposed to compositors. It's purely a wlroots implementation detail.
Thus downstream compositors shouldn't really care about it.

Introduce an "internal_features" dictionary to store the status of
such internal dependencies.
2021-04-09 21:54:38 +02:00
Isaac Freund 78befa59f9 gtk-primary-selection: drop support
The standard primary-selection protocol is now widely supported.
2021-04-08 09:50:18 +02:00
Simon Ser a2535b80ce xwayland: use ICCCM state defines from xcb-icccm 2021-03-29 12:24:26 +02:00
Simon Ser de5347d0f2 xwayland: require xcb-icccm
This dependency is already required by many other widely used X11
programs, such as i3, Qt, and other XWMs. So it should be available
on most systems.

X11 support can be pretty broken without xcb-icccm, with focus issues
for instance. Let's just remove this --please-break-my-desktop footgun
option.
2021-03-29 12:24:26 +02:00
Simon Ser 96aa18ae44 xwayland: assume no WM_HINTS means window wants input
Some X11 clients (e.g. Chromium, sxiv) don't set WM_HINTS. The spec
says:

> Window managers are free to assume convenient values for all fields of the
> WM_HINTS property if a window is mapped without one.

Our wlr_xwayland_icccm_input_model function assumes missing WM_HINTS
means the window doesn't want input, but this is incorrect. Assume the
window wants input unless it explicitly opts-out by setting WM_HINTS.

Closes: https://github.com/swaywm/sway/issues/6107
2021-03-29 12:24:26 +02:00
Simon Ser e6f6e1ad0a xwayland: use -listenfd if available
Xwayland's -listen option was deprecated in [1] in favor of -listenfd.

[1]: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/593
2021-03-03 19:04:47 +01:00
Simon Ser eec2e1d3b1 xwayland: check executable exists on init
Instead of walking PATH like a previous proposal [1], this one
checks that the Xwayland path specified in the pkg-config file
exists.

I think this is a reasonable compromise:

- Users that don't have Xwayland installed system-wide won't get
  a bogus DISPLAY env variable set up.
- Users that have WLR_XWAYLAND set won't be affected by this check.
- Users that have Xwayland installed system-wide and a different
  Xwayland in their PATH still get their custom Xwayland.
- Users that don't have Xwayland installed system-wide but have it
  somewhere else in PATH are left out. But this is pretty niche,
  and they can just set WLR_XWAYLAND.

[1]: https://github.com/swaywm/wlroots/pull/2314
2021-03-03 18:19:12 +01:00
Simon Ser 3504bb587d xwayland: add dependency on xwayland
Check that the pkg-config file is available. This will be required
in the future to check whether xwayland supports features such as
-listenfd, -initfd or -verbose.

If there's no pkg-config file, check that the Xwayland executable
is available.

This effectively makes our relationship with xwayland closer to what
a dynamic library is: checked at build-time, but can be overridden
at run-time.
2021-03-03 18:19:12 +01:00
Simon Ser 6f873078d4 build: use dictionnary for features instead of configuration_data
This allows us to easily iterate on all features and only deal with
bools.
2021-02-15 16:32:33 +01:00
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 2827a9554c xwayland/selection: log when proxy window loses ownership 2021-02-15 13:50:14 +01:00
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
Ilia Mirkin 8ad078f46f xwayland: free render picture backing cursor
Otherwise it gets leaked never to be recovered.
2021-02-05 11:45:54 +01:00
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