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.
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.
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
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.
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.
This fixes issues with (at least) dialogs in Jetbrains IDEs becoming
unclickable if they ever lost focus (ref. swaywm/sway#5373). Prior to
this change, since `xwm->focus_surface` would be set prior to
`xwm_surface_activate` being called, the latter would short-circuit
immediately and not notify the application of the focus change.
Previously, some atoms had a leading underscore, others didn't. Be more
consistent and never use a leading underscore (symbols with a leading
underscore followed by an upper-case letter are reserved).
Without this information, compositors have no way to tell whether
or not to consider the position information valid. Most notably,
a compositor needs to know if it should pick a position for the
surface or use the position sent in the configure request.
This commit makes sure surface->mapped is true when the unmapped event is
emitted. This is necessary because listeners can only damage surfaces that are
mapped. This is similar to the fact that the destroy event is emitted before
any destruction is actually made.
Fixes https://github.com/swaywm/sway/issues/3568
Since xwm only manipulates the stack when focusing a window, newly
mapped windows should be stacked below the focused window. This prevents
the newly mapped window from stealing focus due to being on the top of
the stack.
An X11 client can leave the hints->input WM hint unspecified,
by not setting the XCB_ICCCM_WM_HINT_INPUT flag in hints->flags.
In that case, we should assume a sane default.
Make the hint default to true, so that clients which do not specify
the hint, like mupdf, still get keyboard focus.
This should fixswaywm/sway#2231
It's not used (XCB_IMAGE_FORMAT_Z_PIXMAP comes from xproto.h) and we
don't even have a pkg-config dependency on xcb-image, making the build
to fail on that inclusion on systems without the package.
153f37bdf5 (#1145) removed the
wlr_xwayland_is_unamanged function while fixing OR, because it was
belieived that it's supposed to work around the broken OR handling.
This was a misunderstanding. is_unmanaged is (while sort of a hack)
intended to work around inherent differences between "real" X sessions
and our Xwayland/wayland situation.
The main reason it exists is to support applications like rofi and dzen,
while not handing focus to other OR windows (which should *not* be
required).
Traditionally, these applications just grabbed input from X and didn't
need to be focused by any logic in the WM. Which of course doesn't work
in wayland compositors. So we have to give them focus in some way.
Giving *every* OR window focus, breaks other applications that don't
expect focus to change.
A testcase that was pointed out to me where wlr_xwayland_is_unamanged was
breaking things is https://github.com/swaywm/sway/issues/2128 (syncplay,
gitk, gitgui)
Supposedly it broke using keyboard to navigate the menus.
I can't reproduce this with this patch. The popups can be navigated as
long as the parent has focus.
The override_redirect flag can change on configure notify and
on map notify. This adds an event to know when it changes.
This removes wlr_xwayland_surface_is_unmanaged which was wrongly
using the window type to decide whether the view should be
unmanaged.
A similar patch was proposed to Weston, but has never been
merged upstream [1].
[1]: https://patchwork.freedesktop.org/patch/211161/
Happens when e.g. closing gimp.
==24039==ERROR: AddressSanitizer: heap-use-after-free on address 0x6150001a7a78 at pc 0x7f09b09f1bb2 bp 0x7ffcf0237bf0 sp 0x7ffcf0237be0
WRITE of size 8 at 0x6150001a7a78 thread T0
#0 0x7f09b09f1bb1 in wl_list_remove ../util/signal.c:55
#1 0x7f09b094cf03 in xwayland_surface_destroy ../xwayland/xwm.c:295
#2 0x7f09b0950245 in xwm_handle_destroy_notify ../xwayland/xwm.c:717
#3 0x7f09b095304a in x11_event_handler ../xwayland/xwm.c:1149
#4 0x7f09b0c68f01 in wl_event_loop_dispatch src/event-loop.c:641
#5 0x7f09b0c67601 in wl_display_run src/wayland-server.c:1260
#6 0x40a2f4 in main ../sway/main.c:433
#7 0x7f09b011018a in __libc_start_main (/lib64/libc.so.6+0x2318a)
#8 0x40b749 in _start (/opt/wayland/bin/sway+0x40b749)
0x6150001a7a78 is located 120 bytes inside of 496-byte region [0x6150001a7a00,0x6150001a7bf0)
freed by thread T0 here:
#0 0x7f09b2b58880 in __interceptor_free (/lib64/libasan.so.5+0xee880)
#1 0x7f09b094d1a1 in xwayland_surface_destroy ../xwayland/xwm.c:315
#2 0x7f09b0950245 in xwm_handle_destroy_notify ../xwayland/xwm.c:717
#3 0x7f09b095304a in x11_event_handler ../xwayland/xwm.c:1149
#4 0x7f09b0c68f01 in wl_event_loop_dispatch src/event-loop.c:641
#5 0x7f09b0c67601 in wl_display_run src/wayland-server.c:1260
#6 0x40a2f4 in main ../sway/main.c:433
#7 0x7f09b011018a in __libc_start_main (/lib64/libc.so.6+0x2318a)
#8 0x40b749 in _start (/opt/wayland/bin/sway+0x40b749)
previously allocated by thread T0 here:
#0 0x7f09b2b58e50 in calloc (/lib64/libasan.so.5+0xeee50)
#1 0x7f09b094b585 in xwayland_surface_create ../xwayland/xwm.c:119
#2 0x7f09b0950151 in xwm_handle_create_notify ../xwayland/xwm.c:706
#3 0x7f09b0953032 in x11_event_handler ../xwayland/xwm.c:1146
#4 0x7f09b0c68f01 in wl_event_loop_dispatch src/event-loop.c:641
#5 0x7f09b0c67601 in wl_display_run src/wayland-server.c:1260
#6 0x40a2f4 in main ../sway/main.c:433
#7 0x7f09b011018a in __libc_start_main (/lib64/libc.so.6+0x2318a)
#8 0x40b749 in _start (/opt/wayland/bin/sway+0x40b749)
Some comboboxes (e.g. in chrome://flags) are advertized as…
Notifications of course! Yeah, notifications, the thing that
tells you you have mail, your battery is low, or the dog has
eaten your carpet. This isn't the first time we notice Chromium's
X11 backend is pretty shit.
Anyway, added notifications and splash screens to the list of
unmanaged windows. Also removed utility windows because those
should be managed, but maybe I'm wrong and I'll revert this.
xwm.h was meant to be private, so move it to include/xwayland/xwm.h
We had an ifdef WLR_HAS_XCB_ICCCM in xwayland.h which was easy to move
to xwm, it is not safe to use the WLR_HAS_* in the public headers.
I checked a few of our current users and none rely on xwm.h being
public as expected (rootston, sway, hsroots)
Now message can look like:
[xwayland/xwm.c:991] xcb error: op ChangeProperty (no minor), code Window (no extension), value 6291465
instead of this one when the lib is not available:
[xwayland/xwm.c:999] xcb error: op 18:0, code 3, sequence 103, value 6291465
The value in case of Window is the window id, so we can tell what
function applied on which window which is a good start.
The sequence ought to be able to tell us more precisely which
invocation it was, but we never log it when calling functions
so is useless in practice and no longer logged.
gcc 6.3.0 (at least) complains about &values:
expected ‘const uint32_t * {aka const unsigned int *}’ but argument
is of type ‘uint32_t (*)[1] {aka unsigned int (*)[1]}’
Reported by thorwil on irc
This adds `wlr_xwayland_surface_is_unamanged`, to allow compositors more
fine grained control over XWayland focus.
A surface that is unmanaged should not receive focus, while other
windows that are just override redirect may want it (dmenu).
The way unamanged is determined is taken from wlc.
