WebViewState

Common state holders for WebView.

The public state surface is intentionally small:

• WebViewState.url mirrors the current top-level document URL and is a good fit for address bars. It also works with custom URL schemes as long as the underlying native engine accepts them.

• WebViewState.state exposes the current native readiness and page-loading lifecycle as LoadingState.

• WebViewState.navigator exposes imperative navigation operations.

rememberWebViewState is implemented per platform:

• Desktop/JVM: core/src/jvmMain/kotlin/top/kagg886/wvbridge/state.jvm.kt creates SwingPanelState(WebViewBridgePanel { initialized = true }). initialized becomes true only after core/src/jvmMain/kotlin/top/kagg886/wvbridge/internal/WebViewBridgePanel.kt finishes initAndAttach() inside addNotify(), so LoadingState.NotReady switches to LoadingState.Ready only after the native desktop view is actually attached. The native backends behind that panel are WebView2 on Windows, WebKitGTK (webkit2gtk-4.1) on Linux, and WebKit on macOS.

• Android: core/src/androidMain/kotlin/top/kagg886/wvbridge/state.android.kt creates an android.webkit.WebView, enables the required WebView settings, and then flips to LoadingState.Ready in LaunchedEffect(Unit).

• iOS: core/src/iosMain/kotlin/top/kagg886/wvbridge/state.ios.kt creates a platform.WebKit.WKWebView, enables JavaScript-related preferences, and then flips to LoadingState.Ready in LaunchedEffect(Unit).

Because of that split, non-desktop platforms move from LoadingState.NotReady to LoadingState.Ready almost immediately during the first composition, while desktop platforms keep LoadingState.NotReady until the native peer is fully initialized.