Skip to content

fix(gtk): apply non-resizable window state before first configure - #1370

Open
yuezk wants to merge 1 commit into
tauri-apps:devfrom
yuezk:fix/gtk-initial-fixed-size
Open

yuezk wants to merge 1 commit into
tauri-apps:devfrom
yuezk:fix/gtk-initial-fixed-size

Conversation

@yuezk

@yuezk yuezk commented Oct 9, 2026

Copy link
Copy Markdown
Contributor

On tiling Wayland compositors, a window created with resizable(false) can open larger than its requested inner size. Tao initially leaves the native GTK window resizable and applies the requested flag only after the first configure event. Hyprland can assign a tiled allocation in the meantime, which GTK then retains when the window becomes non-resizable.

This change applies the requested resizable state before mapping ordinary windows. Initially maximized windows retain the existing first-configure sequence, including maximizing before applying the resizable flag, to preserve the Wayland buffer-size handling.

Adds a patch changeset and a display-dependent regression test that checks the native GTK resizable flag before mapping and verifies the requested logical size after mapping. No public API changes.

Reproduction

Create an initially hidden, undecorated window with no explicit min/max constraints, then show it on Hyprland:

let window = WindowBuilder::new()
    .with_visible(false)
    .with_decorations(false)
    .with_inner_size(LogicalSize::new(280, 404))
    .with_resizable(false)
    .build(&event_loop)?;
window.set_visible(true);

Before the fix, our application intermittently received a larger tiled allocation instead of 280×404. Applying the native non-resizable state before mapping kept the requested size and allowed the compositor to float the window.

Verification

  • cargo fmt --all -- --check: passed.

  • cargo test --locked on macOS: passed (4 tests and 3 doctests; 1 doctest ignored). The GTK regression is platform-gated and did not run on macOS.

  • Earlier application-level verification on an Omarchy/Hyprland VM confirmed the same initialization change restored the main window to 280×404 and the update window to 500×420.

  • The standalone GTK test has not yet been executed: the VM was unavailable over SSH during PR preparation. Run it in a live tiling Wayland session with:

    GDK_BACKEND=wayland cargo test --test gtk_initial_fixed_size -- --ignored --test-threads=1

Initially maximized/fullscreen windows, X11, other Wayland compositors, and BSD runtime behavior have not been independently exercised for this PR. The separate BSD resize-hit-testing patch from our application fork is excluded.

@yuezk
yuezk requested a review from a team as a code owner October 9, 2026 03:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant