Before this patch, labwc would happily kill itself when the user
called the `Kill` action when any xwayland view had focus.
The reason this happened was that wlroots creates the xwayland
wayland client via socketpair() and thus a lookup of the pid
of the socket connection would return the pid of labwc itself.
This patch fixes that by implementing different pid lookup
mechanisms based on the view implementation backend.
Fixes: #1739
This allows to ignore X11 client side configure requests
like positioning and resizing and can be used to fight
some X11 applications that persist to have their windows
spawn at specific places and sizes.
Fixes: #1446
...for example `Fall Guys`. It is believed to be caused by setting
override-redirect on an xwayland-surface with a child window, thus
breaking the way root-toplevels are obtained.
```
(threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0)
at pthread_kill.c:44
at pthread_kill.c:78
(fmt=0x7739d9f9bb68 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x5a76573f9222 "root", file=file@entry=0x5a76573f9606 "../labwc/src/view.c", line=line@entry=2013, function=function@entry=0x5a7657400320 <__PRETTY_FUNCTION__.14> "view_move_to_front") at assert.c:94
(assertion=assertion@entry=0x5a76573f9222 "root", file=file@entry=0x5a76573f9606 "../labwc/src/view.c", line=line@entry=2013, function=function@entry=0x5a7657400320 <__PRETTY_FUNCTION__.14> "view_move_to_front") at assert.c:103
at ../labwc/src/view.c:2013
at ../labwc/src/view-impl-common.c:30
at ../labwc/src/xwayland.c:677
at ../wayland-1.22.0/src/wayland-server.c:2241
(signal=signal@entry=0x5a7659025160, data=data@entry=0x5a7659024e90)
at ../wayland-1.22.0/src/wayland-server.c:2241
at ../subprojects/wlroots/types/wlr_compositor.c:493
(cif=cif@entry=0x7ffc74d32530, fn=<optimized out>, rvalue=<optimized out>, avalue=<optimized out>, closure=closure@entry=0x0) at ../src/x86/ffi64.c:673
(cif=cif@entry=0x7ffc74d32530, fn=<optimized out>, rvalue=rvalue@entry=0x0, avalue=avalue@entry=0x7ffc74d32600) at ../src/x86/ffi64.c:710
(closure=closure@entry=0x5a7658f5adc0, target=<optimized out>,
target@entry=0x5a7659025240, opcode=opcode@entry=6, data=<optimized out>,
data@entry=0x5a7658609820, flags=2) at ../wayland-1.22.0/src/connection.c:1025
(fd=<optimized out>, mask=<optimized out>, data=<optimized out>)
at ../wayland-1.22.0/src/wayland-server.c:438
(loop=0x5a7657816e60, timeout=timeout@entry=-1)
at ../wayland-1.22.0/src/event-loop.c:1027
at ../wayland-1.22.0/src/wayland-server.c:1493
at ../labwc/src/main.c:179
```
Reported-by: @kode54
These views (notifications, floating toolbars, etc.) should not be
shown in taskbars/docks/etc. (which are the stated use-case of the
wlr-foreign-toplevel protocol).
Move/resize requests from xwayland views and xdg toplevels should be
ignored when the view is not pressed.
This is relevant for touchpad taps with <tapAndDrag> disabled.
When the user taps the client surface (e.g. chromium and mpv) with the
setting above, libinput sends button press & release signals so quickly
that the compositor receives move/resize request from the client AFTER
the button release signal is processed, so `interactive_finish()` is
never called.
For unknown reasons, XWayland surfaces that are completely offscreen
seem not to generate commit events. In rare cases, this can prevent an
offscreen window from moving onscreen (since we wait for a commit event
that never occurs). As a workaround, move offscreen surfaces
immediately.
This fixes an issue that I can reproduce by having qmpanel displayed on
a (larger) external monitor, then undocking the laptop so that qmpanel
requests a simultaneous move+resize to the (smaller) laptop display.
Account for space taken up by XWayland panels (as indicated by the
_NET_WM_STRUT_PARTIAL property) in the usable_area calculation.
This makes it possible to use labwc in a "transitional" setup, where it
replaces the X11 window manager and compositor, but most other parts of
a existing X11 desktop environment can still be used via XWayland.
(Some remaining drawbacks of such a setup would be the lack of desktop
icons, and native Wayland clients not showing up in X11-based taskbars.)
XWayland clients use the _NET_WORKAREA root window property to determine
how much of the screen is not covered by panels/docks. The property is
used for example by Qt to determine areas of the screen that popup menus
should not overlap (see QScreen::availableVirtualGeometry).
Depends on wlroots MR:
https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4406
v2: prevent calling wlr_xwayland_set_workareas() too early
v3: fix segfault at exit (server->xwayland == NULL)
Need to handle new unified mapping, where mapping is attached to the
wlr_surface objects instead of their parents. Also, most of them require
a new associate event for xsurface objects, their surface member will be
NULL before this event is received.
Refactored by jlindgren:
- add struct mappable
- unify map/unmap logic
...as it needs to be set before honouring xwayland_surface->fullscreen
because that calls desktop_update_top_layer_visiblity() which relies on
view->surface being set in view_is_focusable() since 13d0b14.
Fix bug introduced by PR #1237 which fails to hide the xfce4-panel (or
any other layer-shell client in the top layer) whilst gaming in
fullscreen. The bug can be observed with the following games:
- Alan Wake 2 (wine)
- Starfield (steam+proton)
- Cyberpunk (steam+proton)
- Quake 1 Remaster (steam-native)
Fixes: #661 (the last bit of it)
Reported-by: @ScarecrowDM
Helped-by: @Consolatis
Reproduce issue by:
1. Run an XWayland client
2. ToggleDecorations twice to hide deco
3. Minimize/unminimize from panel
4. Observe that deco is back
Reported-by: @Consolatis
Until we expose the workspaces to xwayland we need a way to
ensure that xwayland views on the current workspace are always
stacked above xwayland views on other workspaces.
If we fail to do so, issues arise in scenarios where we change
the mouse focus but do not change the (xwayland) stacking order.
Reproducer:
- If followMouse is enabled, raiseOnFocus must be disabled
- Open at least two xwayland windows which allow scrolling
(some X11 terminal with 'man man' for example)
- Switch to another workspace, open another xwayland window
which allows scrolling and maximize it
- Switch back to the previous workspace with the two windows
- Move the mouse to the xwayland window that does *not* have
focus
- Start scrolling
- All scroll events should end up on the maximized window on
the other workspace
This patch fixes the issue by simply raising all windows from
the current workspace again in their original stacking order
when switching workspaces.
Reported-by: Domo via IRC (thanks!)
The top_left_edge_boundary_check() function in xwayland.c ensures that
views trying to position themselves at 0,0 don't end up with a titlebar
offscreen. However, it doesn't take into account the usable area and
thus these views can still end up overlapping a top panel.
Also, there is no good reason for top_left_edge_boundary_check() to be
xwayland-specific. This logic should really be part of
view_adjust_for_layout_change().
To fix all this, add a new view_adjust_floating_geometry() function,
which replaces the existing similar (and duplicated) logic in
view_apply_natural_geometry() and view_adjust_for_layout_change().
view_adjust_for_layout_change() is already being called from xwayland's
set_initial_position(), so top_left_edge_boundary_check() is now
redundant and can just be deleted.
Lightly tested with waybar and feh --geometry 640x480+0+0. The feh
window is now correctly positioned below waybar, even if started before
waybar (in that case, the feh window is moved when waybar starts).
This is a useful (if lesser-known) feature of at least a few popular X11
window managers, for example Openbox and XFWM4. Typically right-click on
the maximize button toggles horizontal maximize, while middle-click
toggles vertical maximize.
Support in labwc uses the same configuration syntax as Openbox, where the
Maximize/ToggleMaximize actions have an optional "direction" argument:
horizontal, vertical, or both (default). The default mouse bindings match
the XFWM4 defaults (not sure what Openbox has by default).
Most of the external protocols still assume "maximized" is a Boolean,
which is no longer true internally. For the sake of the outside world,
a view is only "maximized" if maximized in both directions.
Internally, I've taken the following approach:
- SSD code decorates the view as "maximized" (i.e. hiding borders) only
if maximized in both directions.
- Layout code (interactive move/resize, tiling, etc.) generally treats
the view as "maximized" (with the restrictions that entails) if
maximized in either direction. For example, moving a vertically-
maximized view first restores the natural geometry (this differs from
Openbox, which instead allows the view to move only horizontally.)
v2: use enum view_axis for view->maximized
v3:
- update docs
- allow resizing if partly maximized
- add TODOs & corrections noted by Consolatis
Currently xwayland views are restacked on top of the XWayland server
stacking order when activated (i.e. focused). This is wrong because
focus/raise are independent concepts (though often occurring together).
The stacking order should be updated when the view is raised/lowered,
not when the view is focused.
Work is in progress elsewhere (draft PR) that will result in views more
often being raised without being focused. Without this fix, those views
don't get restacked properly, resulting in clicks "passing through" to
views underneath.
The logic was the same for xdg-shell and xwayland views, so move it from
the view->impl layer out to the view_move_to_front/back() functions.
view->impl->move_to_front/back() still exist for now, in case we want to
add xdg/xwayland-specific logic in future, but they now move only one
view and not sub-views.
This makes the code a bit more readable IMHO (and forces us to be
consistent with event handler function names).
Adjust scripts/checkpatch.pl to not complain.
For views that are initially maximized or fullscreen and have no
explicitly specified position, we need to center the stored natural
geometry, or the view may end up partially offscreen once unmaximized/
unfullscreened.
X11 clients may request to be initially fullscreen or maximized by
setting hints in the _NET_WM_STATE property. For some reason, we are
currently only honoring fullscreen requests but not maximize.
The fixes issues with GTK apps (notably Firefox, but others as well)
not starting maximized.
There is a remaining issue that the window position may not be set
correctly after unmaximizing. This will be fixed in a follow-up commit.
When a parent view has multiple sub-views (dialogs) visible, focusing
one sub-view ought to raise it above the others. This doesn't currently
happen -- focusing a sub-view raises the whole group of views together,
but has no effect on the relative stacking order between them.
This seems like a simple oversight in xdg/xwayland_view_move_to_front()
that's pretty easy to fix.
Add FIXMEs to deduplicate this logic in future.
Tested with HomeBank: the Import dialog pops up an additional Open File
dialog, which before this change appears behind the Import dialog (and
clicking on it does not raise it to the front). After this change, the
Open File dialog appears in front as expected.
Assume that Globally Active xwayland views do want focus if they want
window decorations (according to _MOTIF_WM_HINTS). This is a stop-gap
fix to ensure that various applications (mainly Java-based ones such as
IntelliJ IDEA) get focus normally and appear in the window switcher. It
would be better to match based on _NET_WM_WINDOW_TYPE instead, but that
property isn't currently available through wlroots API.
Fixes (partially): 7e72bf975f
("view/xwayland: avoid focusing views that don't want focus")
This allows identifying XWayland views using the ICCCM "Globally Active"
input model. Later commits will improve handling of these views.
No functional change in this commit.
The unmap() handlers should only call desktop_focus_topmost_view() if
the unmapped view was the focused view. Unmapping a view that was not
focused should not change the focus.
I expect this rarely had any effect in practice; it would only matter in
a focus-follows-mouse config where some view other than the one on top
was focused. But it still seems better to fix.
Rather than repeating the logic in two places, create a small
view_impl_unmap() helper. Perhaps more common "unmap" logic could be
moved there in future.
xsurface->data is presumed to be a (struct view *) if set, so it must be
left NULL for an unmanaged surface. Otherwise view_from_wlr_surface()
may return a (struct xwayland_unmanaged *) where a (struct view *) was
expected, leading to a crash.
valgrind backtrace:
Invalid read of size 1
at 0x48F8FFC: wlr_scene_node_set_enabled (wlr_scene.c:903)
by 0x124C9F: ssd_set_active (ssd.c:323)
by 0x124C9F: ssd_set_active (ssd.c:318)
by 0x124C9F: view_set_activated (view.c:215)
by 0x118851: focus_change_notify (seat.c:353)
by 0x487E01D: wl_signal_emit_mutable (wayland-server.c:2241)
by 0x48FC8F2: wlr_seat_keyboard_enter (wlr_seat_keyboard.c:298)
by 0x119E60: seat_focus.lto_priv.0 (seat.c:473)
by 0x1248FD: seat_focus_surface (seat.c:491)
by 0x1248FD: unmanaged_handle_map (xwayland-unmanaged.c:51)
by 0x487E01D: wl_signal_emit_mutable (wayland-server.c:2241)
by 0x487E01D: wl_signal_emit_mutable (wayland-server.c:2241)
by 0x490FC91: surface_commit_state (wlr_compositor.c:499)
by 0x56A24F5: ffi_call_unix64 (unix64.S:104)
by 0x569EF5D: ffi_call_int.lto_priv.0 (ffi64.c:673)
Address 0xa0e15ff30788b68 is not stack'd, malloc'd or (recently) free'd
Fixes: 4028a9482f
("seat: use focus_change event to update focused/active view")
XWayland views can self-declare that they don't want keyboard focus via
the ICCCM WM_HINTS property. Most of the logic is already in place to
avoid giving focus to such views (e.g. taskbars).
Add a couple of missing pieces to make this work:
- Hook up view_isfocusable() to look at WM_HINTS for XWayland views
- Adjust desktop_focus_topmost_mapped_view() to skip unfocusable views
Make desktop_focus_view() always switch to the workspace containing the
view being focused. It doesn't make much sense for an invisible view to
have the keyboard focus.
Also add an optional "raise" parameter to desktop_focus_view(). This
allows the common pattern of desktop_focus_view() + view_move_to_front()
to be reduced to a single function call.
Our current approach to handling the focused/active view is a bit
confusing. In particular, it's hard to be sure when server->focused_view
is or isn't in sync with the real wlroots keyboard focus.
Try to clean things up a bit. In particular:
- Add comments to server->focused_view and desktop_focused_view() to
clarify that they should match, but it's not guaranteed.
- desktop_focused_view() now prints a warning if it detects that
server->focused_view is out of sync. We should keep an eye out for
this warning, and if we see it, try to figure out why it happened.
- For consistency, use only "focus/defocus" as the verbs in function
names rather than "activate". This is a bit arbitrary, but the idea is
that focus is the primary action while the active/inactive state is a
side effect.
- view_focus/defocus() replace view_set_activated() and now update both
focus and active/inactive state, to try to keep them in sync.
- Add comments at view_focus/defocus() to warn against calling them
directly (we should generally call the desktop.c functions).
- desktop_focus_view(NULL) is now forbidden and is no longer handled as
a special case to clear the focus. This was (at least to me) a
surprising behavior and caused trouble when working on another change.
- To maintain existing behavior, desktop_focus_topmost_mapped_view() now
explicitly clears the focus if there are no mapped views.
There should be no behavioral change here.
For views with a non-pixel size increment (e.g. X11 terminals), it's
helpful to subtract the base size of the window (typically including
menu bar, scrollbars, etc.) before computing the number of size
increments (e.g. cells/characters). This way, the displayed size will
exactly match the terminal grid (e.g. 80x25 or whatever).
wlr_box isn't really the best fit for size hints, so let's define a
struct view_size_hints and a nice view_get_size_hints() function,
wrapping view->impl->get_size_hints().
This also seems like a great opportunity to make view_adjust_size()
window-system-agnostic and eliminate xwayland_apply_size_hints().
When a view is destroyed (including override_redirect in the xwayland
case), the view_destroy() handler is called which checks for a currently
open A-Tab window switcher and causes an update there to remove the
destroying view from the list. Before view_destroy() is called, both
xwayland and xdg handlers reset the xdg_surface / xwayland_surface.
The window switcher update then creates a list of all windows which do
not have the 'skipWindowSwitcher' window rule property set. If there is
at least one 'matchOnce' window rule configured, this also tries to get
string properties of the destroying view which already had their
xdg_surface / xwayland_surface reset and thus run into an assert.
This patch fixes that so that the string_prop() handlers always return
an empty string in those cases rather than running into the assert.
For a more in-depth analyses and alternative solutions see the linked
issue.
Fixes#1082
