The original commit introduced a bug by transposing the order of
some of the fields in xcb_size_hints_t. Since XCB ICCCM support is
required now, we can just eliminate the duplicate structs.
With minor changes:
- Remove #ifdef HAS_XCB_ICCCM guards
- Fix #includes
- Fix references to local size_hints struct
This reverts commit 12b9b1a4bd.
A launchee notifies with a "remove"¹ message when done starting up.
Catch these and forward to the compositor. This allows the compositor to
end the startup sequence that might have been started by another
protocol like xdg-activation.
We don't handle other messages since we expect the launcher to use a
wayland protocol like xdg-activation.
While `_NET_STARTUP_ID` helps to associate toplevels with startup-ids
this signals the end of the startup sequence.
1) https://specifications.freedesktop.org/startup-notification-spec/startup-notification-latest.txt
Currently, upon activating a surface, wlroots restacks it on top of all
others.
This may not necessarily be correct from the calling compositor's point
of view, where having focus may not imply being top-of-stack (e.g.,
focusing a window under an always-on-top window).
In Sway's case, this means that focused tiling windows will always be on
top of floating windows, at least in the order communicated to X11 apps.
This breaks drag-and-drop from a focused tiling X11 window to a floating
X11 window which partially obscures the former.
This is a breaking change; to retain the previous behavior, users that
were calling
wlr_xwayland_surface_activate(xsurface, true);
should now be calling
wlr_xwayland_surface_activate(xsurface, true);
wlr_xwayland_surface_restack(xsurface, NULL, XCB_STACK_MODE_ABOVE);
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.
`_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.
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.
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.
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
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.
