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.
