[Bug][Linux/Desktop] Renderer (WebKitWebProcess) crashes surface as silent dead window: install a web-process-terminated handler to log + recover

[iroiro147]

Summary

When the WebKitWebProcess (the WebKitGTK renderer) dies, the Buzz window goes dead but looks like a freeze: the main buzz-desktop process and WebKitNetworkProcess stay alive with no renderer to draw, so the user sees a hung window with no crash dialog, no log line, and no recovery path.

WebKitGTK exposes a web-process-terminated signal on WebKitWebView precisely for this. Buzz currently installs no handler for it (verified: zero references to web_process_terminated / web-process-terminated / WebProcessTerminationReason anywhere in desktop/src-tauri).

Evidence

Surfaced by the thorough diagnosis in #4358 (WebKitWebProcess segfault inside PipeWire's libpipewire-module-metadata.so). That crash has an upstream root cause, but it exposed a separable, Buzz-owned gap: any renderer crash — from PipeWire, an OOM, a WebKit bug, or anything else — currently presents as an unrecoverable silent freeze rather than a detectable, loggable, recoverable event.

Location

The seam already exists. desktop/src-tauri/src/linux_media.rs:63 (enable_media_capture) reaches the underlying webkit2gtk::WebView via webview.with_webview(|platform_webview| platform_webview.inner()) and already installs a connect_permission_request handler in that same closure. It is wired from desktop/src-tauri/src/lib.rs in on_webview_ready (the webview.label() == "main" branch) and is Linux-gated with a no-op stub on macOS/Windows (linux_media.rs:108).

Handling web-process-terminated is a sibling hook in the same place — same WebView, same closure shape, same platform gating.

API surface (verified)

webkit2gtk 2.0.2 (pinned in desktop/src-tauri/Cargo.toml:46 with the v2_22 feature) provides, on WebViewExt:

fn connect_web_process_terminated<F: Fn(&Self, WebProcessTerminationReason) + 'static>(
    &self, f: F) -> SignalHandlerId

WebProcessTerminationReason distinguishes Crashed / ExceededMemoryLimit / TerminatedByApi, so the handler can log why the renderer died — useful signal for exactly the class of bug #4358 reports.

Proposed fix

In linux_media.rs (a sibling install_web_process_terminated_handler called from the same on_webview_ready site in lib.rs), attach a connect_web_process_terminated handler that at minimum:

1. Logs the termination reason (so a silent freeze becomes a diagnosable log line).
2. Recovers the renderer instead of leaving the window dead.

For step 2 there's one design decision worth a maintainer's call:

• Option A (auto-reload): immediately reload the webview on termination. Minimum code, restores the UI with no user action. Risk: a renderer that crashes deterministically on load (e.g. Linux desktop: WebKitWebProcess segfaults in PipeWire's module-metadata on startup (device enumeration, no huddle join needed) #4358's startup-enumeration crash) would crash-loop unless capped — so auto-reload should be rate-limited (at most N reloads within a time window, then fall through to Option B's manual state).
• Option B (surface a restart affordance): show a "renderer crashed — click to restart" state in the webview instead of a frozen window, and reload only on user action. No crash-loop risk, slightly worse UX for a one-off transient crash.

Suggested default: Option B, or Option A with a small retry cap + backoff that falls through to B. Reload target is reachable via get_webview_window("main"), consistent with existing window accessors in lib.rs.

Either way, the detect-and-log half is non-controversial and independently shippable.

Scope note

This issue is deliberately narrow: handle web-process-terminated so a renderer crash is logged and recoverable. It is not about fixing the #4358 PipeWire segfault itself, which is upstream in PipeWire's client modules and should be pursued against PipeWire. It pairs with #4358 as an example, but the fix benefits every possible renderer-crash cause.

[iroiro147]

Follow-up: I have a ready implementation of Option A (capped auto-reload) on iroiro147/buzz@fix/4359-webprocess-recovery. It is stacked directly on the detect/log commit in #4360 and adds:

• should_auto_reload_renderer(recent_crashes, attempt) — pure decision fn allowing up to 3 reloads inside a 120s sliding window.
• The web-process-terminated handler now calls webview.reload() within budget and falls back to a log line suggesting an app restart once the cap trips.
• Two unit tests (below-cap allowed / cap blocks; out-of-window crashes ignored). Host: 5/5 green on the linux_media module.

Deliberately holding it as a branch rather than opening it as a second PR while #4360 waits on the first-time-contributor CI approval gate — I did not want to queue a duplicate against my own open PR. Happy to open it as a stacked PR (or collapse it into #4360 as a follow-up commit) if you prefer that shape, or to switch to Option B (manual affordance) if auto-reload is the wrong UX here. Design call still stands with you.