[BUG] Linux/Wayland: main window webview keeps a ~150 px layout width until the window is resized (0.9.4; 0.9.1 fine on the same machine)

[sun617]

Before You Submit

Searched open and closed issues. #1696 covers the overlay half of what looks like the same v0.9.3 change; this report is about the main window, which PR #1700 explicitly does not cover ("narrowly fixes the overlay"). I did not find an existing report for this.

Bug Description

On a Wayland session, the main window opens with its webview stuck at a tiny layout width. The window itself is sized correctly — the compositor gives it 1896×2094 logical px — but the page inside lays out in a roughly 150 px column: every card and label wraps to min-content width, the accuracy/speed bars overlap the text next to them, and the whole page repeats again about 1850 px further down. The onboarding model list is unreadable and effectively unclickable.

0.9.4, first open. The window is 1896×2094, but the page occupies a ~150 px column: card titles wrap one word per line, the accuracy/speed bars sit on top of the text beside them, and the same content starts over again near the bottom of the window.

Resizing the window by any amount fixes it immediately and completely. The layout reflows correctly and stays correct for the rest of that run. Every subsequent launch reproduces it from scratch.

The same window, same process, after one resize — nothing else changed. This is what the first screenshot should have looked like.

Steps to reproduce

1. Launch Handy 0.9.4 in a Wayland session (mine: niri 26.04; the window is tiled to 1896×2094).
2. Open the main window — either launch it directly, or run with --start-hidden and open it from the tray. Both reproduce.
3. Observe the UI squeezed into a narrow column in an otherwise empty window.
4. Resize the window (any change in width). The layout snaps to correct.

What I ruled out

• Not the DMA-BUF renderer. WEBKIT_DISABLE_DMABUF_RENDERER=1 makes no difference — identical broken layout.
• Not the WebKit/GTK version. Byte-identical libraries in the working and broken runs: webkitgtk 2.52.5 (ABI 4.1), GTK 3.24.52, gtk-layer-shell 0.10.1.
• Not packaging. I ran the official Handy_0.9.1_amd64.deb and the official Handy_0.9.4_amd64.deb through an identical unpack-and-patch path on NixOS (dpkg -x + patchelf, same library closure). 0.9.1 is correct, 0.9.4 is broken. A from-source 0.9.1 build behaves the same as the 0.9.1 .deb.
• Not display scaling. Both outputs are scale 1.0, no fractional scaling.

A/B results (same machine, same session, same window size)

Build	Packaging	Main window on first open
0.9.4	official .deb, repacked	broken, every launch
0.9.4 + WEBKIT_DISABLE_DMABUF_RENDERER=1	official .deb, repacked	broken
0.9.1	official .deb, identical repack	correct
0.9.1	built from source	correct

0.9.1 from the official .deb, same repack path and same window size as the broken 0.9.4 run above — correct on first open, no resize needed. (The light vs. dark difference across these screenshots is just the appearance setting; it has no bearing on the layout.)

Suspected cause

Only the app version varies across those rows, so the change landed between 0.9.1 and 0.9.4. The obvious candidate is the v0.9.3 switch from the cjpais/tauri fork to upstream tauri 2.11.5 (commit 5a7c0ea, PR #1675). 0.9.1 still pins that fork through [patch.crates-io] on tauri-runtime, tauri-runtime-wry and tauri-utils (branch handy-2.10.2), and #1696 reports the same cutover breaking Wayland overlay rendering.

To be clear about the limits of my testing: I have not bisected 0.9.2 and 0.9.3, so the specific commit is an inference from the 0.9.1↔0.9.4 result plus #1696, not a verified bisect. I'm happy to test 0.9.2 and 0.9.3 if that would help narrow it.

System Information

App Version: 0.9.4 (0.9.1 also tested, for comparison)

Operating System: NixOS 26.11 (unstable, 26.11.20260723), kernel 6.18.39, Wayland session under niri 26.04

CPU: AMD Ryzen AI 9 HX 370 w/ Radeon 890M

GPU: AMD Radeon 890M (integrated, RADV/Vulkan)

Displays: 3840×2160@60 and 1920×1080@60, both at scale 1.0

Relevant libraries (identical in the working and broken runs): webkitgtk 2.52.5 (ABI 4.1), GTK 3.24.52, gtk-layer-shell 0.10.1

Logs

Nothing anomalous — startup is clean and there is no error, warning or Wayland protocol message corresponding to the broken layout:

[INFO] Seeded 65 catalog model(s) into the registry
[INFO] Initializing database at "~/.local/share/com.pais.handy/history.db"
[INFO] load_backend: loaded Vulkan backend from .../libggml-vulkan.so
[INFO] load_backend: loaded CPU backend from .../libggml-cpu-zen4.so
[INFO] transcribe_init_backends: 2 compute device(s) registered: Vulkan0, CPU
[INFO] transcribe-cpp initialized with 2 compute device(s): [Vulkan0 (vulkan), CPU (cpu)]
[INFO] ORT accelerator set to: auto

[xilec]

My stack — NixOS 26.05 (+ unstable), Wayland, niri with noctalia — and I've been building Handy from source on commits after the Tauri 2.11.5 switch (5a7c0ea). The main/settings window has always rendered correctly for me on first open: full-width layout, no narrow-column squeezing, no duplicate content. I never needed a resize to fix it.