teksilo-webview — an embeddable [WebView] widget for Teksilo.

A web view is the one widget that cannot render into Teksilo's wgpu surface: every realistic engine (WKWebView, WebView2, WebKitGTK, Servo) owns its own rendering and lives as a native subview on top of the wgpu pass. This crate accepts that reality and mirrors the established platform-backend pattern — a swappable [WebViewBackend] creates an engine-specific [WebViewHandle], and a per-app [WebViewRegistry] (installed in app-state) routes JS→Rust / lifecycle events back to the widget.

# use teksilo_core::signal::Signal;
use teksilo_webview::WebView;

# let title_signal: Signal<String> = Signal::new(String::new());
# let loading_signal: Signal<bool> = Signal::new(false);
let _wv = WebView::new()
    .url("https://example.com")
    .title_signal(title_signal.clone())
    .loading_signal(loading_signal.clone())
    .on_message(|msg, _ctx| println!("JS said: {msg}"));

The Switcher / dormancy caveat

Because the engine surface lives outside the wgpu pass, "not painted" does NOT mean "hidden" for a WebView. When a Switcher / TabWidget / visible_when gate parks the widget dormant, the framework simply stops painting it — but the native subview keeps floating over the output. WebView closes this gap by bridging the framework's per-node activation signal (BuildContext::activation_signal) to the engine's set_visible: tab-away → set_visible(false), tab-back → set_visible (true). This is the one place a widget must explicitly mirror framework visibility onto an OS resource, and it is wired automatically here.

Who owns the pointer over the page

A native subview is above the wgpu pass for input as well as for pixels: the OS routes a press over its rectangle to the engine, and Teksilo is not told. [WebViewInput] is the declaration of which side owns that rectangle, and it decides four things at once — see the enum's docs.