The Frozen Tauri Window Was a Dead WebKit Renderer
Walz's native window remained visible after its WebKit renderer aborted, which made a dead child process look like a frozen Tauri application.
Walz looked frozen because its native window stayed on screen, but the process that rendered the web content had already aborted. The surviving Tauri shell preserved the last frame, so the visible symptom pointed at the wrong process.
This diagnosis came from one Arch Linux host running WebKitGTK 2.52.5. The evidence supports the package fix on that host, not a claim that every frozen Tauri window has the same cause.
The process tree explained the stale frame
A Tauri application on Linux is not one rendering process. The native application creates the window and hosts WebKitGTK, which can run web content in a separate renderer. If that renderer dies while the host remains alive, the compositor can continue displaying the last submitted buffer.
That is visually similar to a blocked event loop: the window exists, repainting stops, and clicks do nothing useful. Checking only the top-level Walz process made it look healthy. Inspecting its child processes and the journal showed that the WebKit renderer had terminated with SIGABRT.
WebKitGTK's debugging guide is useful here because it treats the web process as a separate crash target. The relevant log belongs to that process even when the application window survives.
The journal pointed into GStreamer setup
The abort was accompanied by an assertion around audio sink setup. On the affected system, GStreamer's autoaudiosink element was unavailable because the Good Plugins package was missing. The 1 documentation identifies it as part of that plugin module and explains that it selects an audio sink automatically.
Walz's Arch package gained gst-plugins-good as a runtime dependency and incremented pkgrel. The package build and static checks passed.
The evidence showed that the dependency was missing and that the package now declares it. It did not prove that the installed application was repaired. The package still had to be installed, the old processes stopped, and the original behavior reproduced against the new runtime.
Find the component that stopped progressing
When a GUI freezes but remains visible, split the symptom into three questions:
- Is the host process alive? A surviving window manager connection explains why the surface remains.
- Is the renderer alive? Check child processes, exit status, core dumps, and component-specific logs.
- Is the installed runtime the one you built? A corrected package file does not alter already running processes.
The stale frame was not misleading evidence. It accurately showed that the compositor still had a buffer. It simply said nothing about whether the process responsible for the next buffer still existed.