fix: don't toggle fullscreen/maximize on client request (GTK windows exploding)#70
Merged
Merged
Conversation
…inter caps
Two bugs, the first explaining the "wbconf/GTK windows explode and lose their
titlebar when dragged" report.
1) Client fullscreen/maximize requests were TOGGLED instead of applied.
xdg_toplevel_request_fullscreen did `set_fullscreen(!current)` and
request_maximize did `set_maximized(!full)`. wlroots raises these events for
BOTH set and unset, with the wanted value in requested.{fullscreen,maximized}.
GTK proactively sends unset_fullscreen while managing its window state, so a
GTK window being dragged emitted `request_fullscreen` with requested=false on
a non-fullscreen window — which the toggle turned INTO fullscreen. The window
blew up to fill the screen and GTK hid its titlebar (fullscreen). Reproduced
deterministically (see below).
Honour requested.fullscreen / requested.maximized instead of toggling, and
make set_toplevel_fullscreen a no-op when the state is unchanged + skip
redundant maximize requests, so a redundant unset can't corrupt geometry by
restoring an unset restore-rect. The keybinding actions (ToggleMaximize /
Fullscreen) still toggle, as intended.
2) Virtual pointers never advertised seat pointer capability. The
virtual-pointer protocol attaches its device via handle_new_pointer directly,
bypassing new_input_notify — the only place that called
wlr_seat_set_capabilities. So with only a virtual pointer (e.g. the headless
backend the tests use), the seat advertised no pointer and NO client ever
received pointer events (compositor-handled input like SSD buttons still
worked, which masked it). Factor the capability update into a helper and call
it from the virtual-pointer and virtual-keyboard paths too. This also makes
client input scriptable from the command line via the virtual-pointer
protocol, which is how bug #1 was finally reproduced.
Verified: built a toolkit-free xdg client and a zwlr_virtual_pointer drag tool;
before the fix, dragging a GTK header bar logged `fullscreen-on 1280x720`; after,
the window stays put. Full suite 27 green (g++/ASan, incl. the maximize/
fullscreen window_state integration test); clang + release clean.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Properly diagnosed and reproduced the "GTK windows (wbconf, awf-gtk4) explode/expand and lose their titlebar when dragged" bug — apologies it took several wrong turns to get to the actual root cause.
Root cause
xdg_toplevel_request_fullscreentoggled fullscreen based on current state:set_toplevel_fullscreen(toplevel, !toplevel->xdg_toplevel->current.fullscreen);wlroots raises
request_fullscreenfor both set and unset, with the wanted value inrequested.fullscreen. GTK proactively sendsunset_fullscreenwhile managing its window state — so a GTK window being dragged emittedrequest_fullscreenwithrequested=falseon a non-fullscreen window, and the toggle turned it into fullscreen. The window blows up to fill the screen and GTK hides its titlebar (fullscreen has no decorations) — exactly the "explode + lose titlebar" symptom.request_maximizehad the identical toggle bug.Fix: honour
requested.fullscreen/requested.maximizedinstead of toggling; makeset_toplevel_fullscreena no-op when unchanged and skip redundant maximize requests (so a redundant unset can't corrupt geometry by restoring an unset restore-rect). The keybinding actions (ToggleMaximize / Fullscreen) still toggle, as intended.Second bug (found while building a reproduction)
Virtual pointers never advertised seat pointer capability: the virtual-pointer protocol attaches its device via
handle_new_pointerdirectly, bypassingnew_input_notify— the only caller ofwlr_seat_set_capabilities. So with only a virtual pointer (the headless backend the tests use), no client ever received pointer events (compositor-handled input like SSD buttons still worked, which masked it). Factored the capability update into a helper and call it from the virtual-pointer/keyboard paths. This also makes client input scriptable from the command line (answering the earlier "drive a seat from cmdline" question).How it was reproduced (deterministically)
zwlr_virtual_pointer_v1press/move/release CLI drove a real GTK header-bar drag. Before the fix:wb-geom fullscreen-on 1280x720. After: the window stays put (onlymappedlogged).Testing
window_stateintegration test (keybinding toggles still work); clang + release clean.Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com