WebViewController

Common controllers for WebView.

The public controller surface is intentionally small:

• WebViewController.url records the most recent top-level URL the WebView attempted to load and is a good fit for address bars, including when that navigation fails.

• WebViewController.loadingState exposes the current native readiness and page-loading lifecycle as LoadingState.

• WebViewController.navigator exposes imperative navigation operations.

rememberWebViewController is implemented per platform:

• Desktop/JVM: core/src/jvmMain/kotlin/top/kagg886/wvbridge/controller.jvm.kt creates SwingPanelController(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/controller.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/controller.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.