The issue occurred when `wlr_xwayland_shell_v1` was destroyed before
`wlr_xwayland`. This happened because `wlr_xwayland` didn't remove the
listener for the shell's destroy event in `handle_shell_destroy`.
None active window might be interpreted from an X point of view as a
transient focus state, and is used by multiple X window managers when
a temporary focus change is in progress, or simply when grabbing the
keyboard.
From Wine side, we translate any active window change to the Win32
application, and handling None active window as an actual window
deactivation and focus loss creates spurious events and an undesired
feedback loop, as apps might react to it.
We still want to be able to detect actual focus loss under an XWayland
session, and having XWayland window manager focus an actual X window
instead will make the distinction possible.
The spec says [1]:
> If set, the Window Manager should use this in preference to WM_NAME.
However we overwrite WM_NAME with NULL when _NET_WM_NAME is unset.
Fix this by storing both WM_NAME and _NET_WM_NAME, so that we
handle properly all combinations of events (e.g. a client setting
both and later clearing one).
[1]: https://specifications.freedesktop.org/wm-spec/1.3/ar01s05.html#id-1.6.2
This reverts commit 954dba3968.
Motivations:
- This only resets some state, but other global state such as other
signal handlers, process limits (e.g. NOFILE) or system-specific
settings are left as-is. The chunk of state which does get reset
is opinionated.
- Compositors have other ways to do this, e.g. with pthread_atfork()
or with empty signal handler callbacks.
Certain signal-related properties, such as the signal mask and handlers
that are set to ignore, are not reset by exec and therefore affect the
new process image.
In case of Xwayland, a compositor setting SIGCHLD to SIG_IGN causes
keyboard compilation to fail as it expects waitpid to work by default.
Reset the signal mask and the two signals that sway is known to set.
As struct wlr_drag is destroyed on drop and in the process resets
the focus, a xwayland dnd listener would also reset xwm->drag_focus.
This prevents the xcb replies from being processed and also prevents
the transfer if a compositor would not additionally request new focus
in its wlr_drag destroy handler (which is something usually only done
when in a focus-follows-mouse setting).
This patch creates a new xwm->drop_focus pointer which is a copy of
xwm->drag_focus at drop time. The xcb reply handler and transfer
logic now use the new xwm->drop_focus for their authorization checks.
The wlr_drag takes care of resetting the focused wlr_surface when
it's destroyed, however we store the wlr_xwayland_surface, which
may be destroyed before.
Instead of calling xcb_flush() directly, wait until the FD is
writable.
Ideally we'd have a non-blocking variant instead of xcb_flush(),
but libxcb doesn't have this. Also libxcb blocks when its internal
buffer is full, but not much we can do here.
The infrastructure to read _NET_WM_WINDOW_TYPE already exists in wlroots
(it's used for example in wlr_xwayland_or_surface_wants_focus()). But
the window type isn't easily accessible to the compositor because the
atoms to compare against are private to xwm.c.
labwc has recently gone to a fair amount of effort (including opening a
whole new xcb connection) just to get the needed window type atoms:
a04b394e59
It seems much cleaner to add the remaining few (3) atoms to wlroots and
implement a shared function which can be used by any wlroots compositor.
v2: naming updates
Previously it was supplying a pointer to private struct wlr_xwm
which was useless for compositors. The wlr_xwayland pointer in
contrast does have a generic data field and thus can be used by
compositors to attach their own pointer.
Additionally change the return value from int to bool.
This is especially useful if the compositor wants to support X11
panels to control windows. Without the signal a compositor does
have to hook into the user_event_handler callback but that would
not change the _NET_SUPPORTED root window property.
In labwc, we have had trouble with XWayland windows using the Globally
Active input model (see wlr_xwayland_icccm_input_model()). Under
traditional X11, these windows do not expect to be given focus directly
by the window manager; rather, the WM sends them a WM_TAKE_FOCUS message
prompting the client to take focus voluntarily.
Currently, these clients are difficult to support with wlroots, because
wlr_xwayland_surface_activate() assumes the client window will always
accept the keyboard focus after being sent WM_TAKE_FOCUS. Some Globally
Active client windows (e.g. panels/toolbars) don't want to be focused.
It's useless at best to focus them, and might even make them misbehave.
Others do need keyboard focus to be functional -- and there doesn't seem
to be any reliable way to know this in advance.
Adding wlr_xwayland_surface_offer_focus() allows the compositor to send
WM_TAKE_FOCUS to a client window supporting it and then see whether the
client accepts or ignores the offer. If it accepts, the surface will emit
the focus_in signal notifying the compositor that it has received focus.
This is entirely opt-in. A compositor that doesn't want to use the new
function can continue to call wlr_xwayland_surface_activate() directly
just as before.
Currently _NET_WM_STATE is updated in xwm_focus_window() but
_NET_ACTIVE_WINDOW is updated in xwm_surface_activate(). In some cases
(for example, client-initiated focus changes) the two properties can get
out of sync.
Factor out a new function which updates both properties in sync.
Adjust the logic in xwm_handle_focus_in() to call either
xwm_focus_window() or xwm_set_focused_window(), or neither, as
appropriate.
This has been introduced way back in
be297d9d14 but is never used anywhere.
If compositors want to save the old dimensions before reacting to a
fullscreen or maximize event they can just grab the sizes within their
event handlers instead.
For XWayland surfaces that start maximized, it's best to send an initial
Configure event to set the size of the surface before mapping it. This
reduces visual glitches since the application sees the correct maximized
size when performing its initial layout and drawing.
wlroots surfaces emit their first "map" event after the XWayland window
has already been mapped and the first frame has been drawn & committed.
This is too late to send the initial Configure event.
So, add a new "map_request" event which is emitted immediately before
telling XWayland to map the window. Compositors can connect to this
event to send the initial Configure event to an XWayland app based on
its requested maximized (or fullscreen) state.
Compositors should not place anything visually on the screen at this
point but rather wait until the "map" event as before.
scan-build is a little confused, thinking xwm->xres value could change
during the execution of xwayland_surface_create so client_id_cookie
could end up used uninitialized.
The struct is just an unsigned int, so no harm in initializing it to get
it off the list.
Stop trying to maintain a per-file _POSIX_C_SOURCE. Instead,
require POSIX.1-2008 globally. A lot of core source files depend
on that already.
Some care must be taken on a few select files where we need a bit
more than POSIX. Some files need XSI extensions (_XOPEN_SOURCE) and
some files need BSD extensions (_DEFAULT_SOURCE). In both cases,
these feature test macros imply _POSIX_C_SOURCE. Make sure to not
define both these macros and _POSIX_C_SOURCE explicitly to avoid
POSIX requirement conflicts (e.g. _POSIX_C_SOURCE says POSIX.1-2001
but _XOPEN_SOURCE says POSIX.1-2008).
Additionally, there is one special case in render/vulkan/vulkan.c.
That file needs major()/minor(), and these are system-specific.
On FreeBSD, _POSIX_C_SOURCE hides system-specific symbols so we need
to make sure it's not defined for this file. On Linux, we can
explicitly include <sys/sysmacros.h> and ensure that apart from
symbols defined there the file only uses POSIX toys.
A motivating example of such problem - Zoom's popups that open on button presses.
Before this fix the popup would flicker and immediately disappear - because the PID is not yet
available for the verification (as the surface has not been associated yet), wlroots would refuse to
focus the popup and instead focus the previous window. This leads QT to interpret this as a sign to
close the popup.
This change moves the PID aqcuisition to an earlier phase - just where the window is created.
Instead, move the wlr_xwayland_surface_set_withdrawn() and
wlr_xwayland_surface_restack() calls to the MapNotify handler with an
override_redirect check, as they are done too early. This mirrors the logic in
the UnmapNotify handler and fixes a bug where wlr_xwayland_surface_restack()
would be called on an o-r window after the following sequence of requests:
- CreateWindow with override_redirect=True
- ChangeWindowAttributes with override_redirect=False
- MapWindow
Fixes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3770
