[v0.9.3 regression] Recording overlay invisible on KDE Wayland (KWin) — GTK layer-shell broken after tauri fork → upstream switch

[uladziislau]

Bug Description

After upgrading from v0.9.2 → v0.9.3 on Fedora 44 KDE Plasma (Wayland, KWin), the recording overlay is no longer visible. Transcription itself works fine — only the overlay window disappears.

This is a regression introduced in v0.9.3. Downgrading back to v0.9.2 restores the overlay immediately (verified).

Root Cause (investigated)

• v0.9.2 shipped via a cjpais/tauri fork (branch handy-2.10.2) with custom tauri-runtime, tauri-runtime-wry, and tauri-utils that carried Wayland-specific patches for GTK layer-shell integration.
• v0.9.3 (PR bump tauri version and Mac dock fixes #1675) replaced the fork with upstream tauri 2.11.5 + a pinned tao (commit 07f3742b1, only to fix Wayland CSD).
• The overlay is created successfully and show_overlay_state() runs to completion (logs confirm set_size / pos_calc / set_pos / show). GTK layer-shell initializes. But the KWin compositor never renders the layer surface — the window is logically shown but not painted on screen.

Evidence

With RUST_LOG=debug /usr/bin/handy:

[handy_app_lib::overlay][DEBUG] Recording overlay window created successfully (hidden)
[handy_app_lib::overlay][DEBUG] GTK layer shell initialized for overlay window
[handy_app_lib::overlay][DEBUG] overlay 'recording': set_size=... pos_calc=... set_pos=... show=...

Settings confirm overlay_style: Live, overlay_position: bottom, start_hidden: true.

Workaround that proves the cause

Running with the env var that skips GTK layer-shell makes the overlay appear:

HANDY_NO_GTK_LAYER_SHELL=true /usr/bin/handy

→ Overlay becomes visible (as a regular window), but centered, because on Wayland the compositor blocks client-side window positioning. This confirms the layer-shell surface is the piece that broke between the fork and upstream tauri 2.11.5.

Reproduction

1. Install Handy-0.9.3-1.x86_64.rpm on Fedora 44 KDE Plasma, Wayland session.
2. Set overlay_style: Live (default), overlay_position: bottom.
3. Start a recording (e.g. push-to-talk).
4. Expected: overlay shows at the bottom of the screen.
5. Actual: no overlay is visible; transcription still works.
6. Set HANDY_NO_GTK_LAYER_SHELL=true and repeat → overlay appears (centered).

System Information

• App Version: 0.9.3 (regression vs 0.9.2)
• Operating System: Fedora 44 KDE Plasma 6
• Session: Wayland (KWin)
• Architecture: x86_64 (rpm package)

Additional notes

• The cjpais/tauri fork appears to have no 2.11.x branch, so a clean revert via Cargo.toml is not currently possible without porting the Wayland layer-shell patches to upstream tauri 2.11.
• On v0.9.2 the overlay works correctly (positioning + visibility), with only minor/occasional UI lag — that version is the last known-good for KDE Wayland overlay.

[uladziislau]

From our analysis, the overlay works on v0.9.2 because the cjpais/tauri fork (handy-2.10.2) carried Wayland-specific GTK layer-shell patches in tauri-runtime and tauri-runtime-wry. v0.9.3 dropped the fork for upstream tauri 2.11.5, and those patches never made it upstream.

We see two viable paths:

A) Port the layer-shell patches from the fork to upstream tauri 2.11.x — proper fix, benefits all tauri apps on Wayland. The patches exist in the handy-2.10.2 branch but need adaptation for 2.11.x.

B) Drop GTK layer-shell on Linux, use KWin D-Bus for positioning — lighter fix, contained in Handy code. Skip layer-shell init (already supported via HANDY_NO_GTK_LAYER_SHELL) and use KDE D-Bus API to keep the window on top and positioned. KDE-specific but much simpler.

We can help with either path, but would like to hear your thoughts on direction first. Happy to contribute a PR once we agree on approach.

[cjpais]

Thanks for pointing this out, I figured there might be a regression as a result of this. We will try to fix this properly, @xilec I will try to review your PR when I can, thank you!

[arimxyer]

Independent reproduction on KDE Plasma 6 / KWin (Wayland), single 5120x2160 output, on a 0.9.4-based build (a personal fork, so not proposing a competing PR — #1700 looks like the right fix to land). Adding one mechanism detail that I didn't see named in this thread or in #1700, in case it's useful to whoever reviews.

The layer surface is being committed at 0x0.

A zwlr_layer_shell_v1 surface anchored to a single edge takes its size from the GTK window's size request. gtk_window.resize() — which is what Tauri's set_size bottoms out in — is silently ignored for a layer surface. Since show_overlay_state_on_main() only ever calls set_size, the surface has no area, so it renders correctly into nothing. That matches the symptom exactly: every log line succeeds, layer-shell initializes, and nothing is painted.

gtk-layer-shell 0.8.2 exposes no set_size at all (only set_anchor / set_layer / set_margin / set_exclusive_zone / set_keyboard_mode / set_namespace / set_monitor), so the size genuinely has to come from GTK.

Evidence, via KWin's own scripting API (workspace.windowList() during a recording):

	KWin sees	on screen
layer-shell on, as shipped	nothing — no surface in the list	invisible
HANDY_NO_GTK_LAYER_SHELL=1	class=handy caption=Recording geo=2360,997 400x200	visible, centred
layer-shell on + size request	class=handy caption= geo=2360,2000 400x120	visible, bottom-anchored

The zero-sized surface never maps, which is why it's absent from the window list entirely in the first row. In the third row the empty caption= is the tell that it's still a genuine layer surface rather than a fallback toplevel, and the geometry is what the anchor produces: 2160 − 120 − 40 = 2000 for a 40px bottom margin, horizontally centred by the compositor.

What made it render here, in overlay.rs:

• gtk_window.set_size_request(w, h) on every show, since the overlay swaps between the compact pill and the larger stream card;
• set_layer_shell_margin() on the anchored edge, replacing the y-offset calculate_overlay_position() applies on the regular-window path — a Wayland client can't position itself, so anchor + margin is the only lever;
• skipping set_position entirely while layer-shell is active.

Not suggesting this over #1700's approach — that one is verified on niri and is clearly the broader fix. Just flagging the sizing path in case it explains why the surface is invisible rather than merely mispositioned, and because it's a small delta if a narrower fix is ever wanted for the 2.11.x line.

[jmartsch]

I can confirm the overlay does not show (or just briefly appears and disappears) over most applications like Edge browser (Flatpak), Dolphin, Zed Editor. But it shows for example in Ferdium which is an Electron wrapper for Chromium.
I am using Fedora 44 with KDE Wayland

[cjpais]

Should be fixed as a result of #1700 merge, comes out in 0.9.6