Create the GTK main webview lazily

[ctate]

Why

The Linux host created the main WebKitWebView eagerly at every window create — so pure canvas apps booted WebKit web and network processes they never used, required libwebkitgtk sandbox workarounds in CI, and carried web machinery at runtime for no reason. The macOS host has been lazy for a while; this brings GTK to parity.

What

• Window create builds only GTK chrome; the main WebKitWebView materializes on first web use (load, main-frame set-frame/zoom/layer), with the zero:// scheme and bridge registration moving into materialization — registerable from either the main or a child webview, idempotent across windows
• Every main-webview dereference in the host audited into ensure (creates on demand) or peek (honestly no-ops) semantics; destroy paths handle never-created webviews
• The canvas smoke gains a permanent regression assertion: canvas apps must spawn zero WebKit processes — and the WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS workaround it existed for is deleted
• Fixes a latent bug laziness exposed: child-webview bridge responses were dropped unless the main webview existed

Verification

Containerized GTK (Ubuntu 24.04, WebKitGTK 2.52, Xvfb — the CI package set):

• Canvas smoke passes with no WebKit env vars, zero WebKit processes asserted after first frame and at end of run
• Webview example as positive control: main webview materializes into an already-shown window on demand, page renders, JS→native→JS bridge round-trips, child webviews and a second JS-opened window work with no scheme double-registration
• zig build test-webview-system-link -Dplatform=linux passes in-container; macOS-side suite, validate, and examples battery green

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
native-sdk	Ready	Preview, Comment	Jul 10, 2026 10:11pm