xwayland_surface_associate() asserts that the surface has not yet
been associated yet. Arbitrary clients can send these messages,
don't abort when that happens.
This field is difficult to use correctly, its meaning depends on
format.
xcb docs read:
> You should use the corresponding accessor instead of this field.
Replace all uses with the safe accessor.
This fixes potential out-of-bounds array accesses when the format
field isn't what we expect.
This reverts commit 02abf1cd28.
The change doesn't make sense. It causes a use-after-free when trying
to read the pixel data of the icon. The docs clearly state to use
'xcb_ewmh_get_wm_icon_reply_wipe()' when using the function which
correctly frees the reply *after* processing the pixel data.
When pipe() fails in xwm_selection_send_data(), the function
returns without cleaning up the allocated transfer structure
and initialized wl_array. This causes a memory leak.
Add wl_array_release() and free() to clean up resources when
pipe() fails.
Signed-off-by: Wang Yu <wangyu@uniontech.com>
Ensure mime_types and mime_types_atoms remain in sync when
wl_array_add() fails. Roll back the partially added entry and
free the allocated mime type to avoid leaks and inconsistent
state.
wl_event_source_fd_update() goes through another event loop cycle, which
delays writes. This extra cycle was introduced in 6ada67da9b
("xwayland/xwm: implement somewhat asynchronous request flushing").
Try flushing the X11 WM FD immediately if we can.
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/4044
When an FD is passed to xcb_connect_to_fd(), xcb takes ownership of that
FD and is responsible for closing it, which it does when
xcb_disconnect() is called. But the xwayland handler code also keeps a
copy of the FD and closes it via safe_close() in
server_finish_process().
This double-close can cause all sorts of problems if another part of
wlroots allocates another FD between the two closes - the latter close
will close the wrong FD and things go horribly wrong (in my case leading
to use-after-free and segfaults).
Fix this by setting wm_fd[0]=-1 after calling xwm_create(), and ensuring
that xwm_create() closes the FD if startup errors occur.
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
