Good morning and Happy Google I/O day to everyone! I have a question about the <Accompanist WebView>...

# compose

[Joseph Hawkes-Cates]

Good morning and Happy Google I/O day to everyone! I have a question about the Accompanist WebView. I think this may be an issue, but wanted to check before I logged it. Details in 🧵

[Joseph Hawkes-Cates]

We have a WebView in one of our screens and we’re running into a scenario where we navigate to another screen while keeping our WebView screen on the backstack and then we come back to our WebView screen. This causes the WebView to enter a brand new Composition when we come back and be essentially recreated. This is all fine and good, but we’re seeing an issue with the WebViewState when this happens.

[Joseph Hawkes-Cates]

The structure of our code is like this:

var webView: WebView? by remember { mutableStateOf(null) }
val webViewState = rememberWebViewStateWithHTMLData(
   data = internalHtml,
   baseUrl = webViewUrl
)

 WebView(
     state = webViewState,
     captureBackPresses = false,
     onCreated = {
                webView = it
                it.clearCache(true)
                it.clearHistory()
                it.settings.javaScriptEnabled = true
                it.addJavascriptInterface(webHandler, webHandler.interfaceName)
                Timber.d("Created WebView")
     },
     client = webViewClient,
     chromeClient = remember { MyWebChromeClient() },
)

if(!webViewState.isLoading) {
   applyJavascript(webView)
}

[Joseph Hawkes-Cates]

The issue we’re seeing in this scenario is that we update the internalHTML mutableState after the initial recomposition which results in a new instance of WebViewState. This instance is not being set on the AccompanistWebViewClient, though, because the AndroidView factory lambda inside the WebView composable is not being called again after that update.

[Joseph Hawkes-Cates]

This results in the webViewState that the AccompanistWebView is updating and the WebViewState that we’re referencing being different which makes isLoading get stuck as true indefinitely.

[Joseph Hawkes-Cates]

The state is set here for the AccompanistWebViewClient, but that isn’t called again after the initial composition.

[Joseph Hawkes-Cates]

We have worked around this by checking the state on the webViewClient directly, but that is tricky because that state field is a lateinit field so we have to do this to use it safely:

val isLoading = webView?.webViewClient?.let {
        webViewClient.state.isLoading
    } ?: true

[Joseph Hawkes-Cates]

This works because the webViewClient isn’t set on the WebView instance until after the state is set on line 96 that I linked to above, but it’s very dependent on the internal impl of the WebView composable which isn’t great

[Joseph Hawkes-Cates]

I think the proposal would be to update the state instance on the AccompanistWebViewClient and the chrome client when the state is changed.

[Joseph Hawkes-Cates]

I actually found a better workaround for this. Instead of using the provided rememberWebViewStateWithHTMLData, I can do this:

val webViewData = remember(webViewHtml, webViewUrl) {
        WebContent.Data(internalHtml, webViewUrl)
    }
    // Only create this state instance once since the WebView Composable does not fully update for new instances
    val webViewState = remember { WebViewState(webViewData) }
    // When the webViewData changes, set it on the webViewState. Content is a mutableState field so updating it will trigger the appropriate recompositons.
    LaunchedEffect(webViewData) {
        webViewState.content = webViewData
    }

this is more verbose than my first workaround, but it is not dependent on the order of when things are set within the internal WebView creation code.

[Joseph Hawkes-Cates]

So my question is am I missing anything in my usage here or is this worth logging an issue for?

[Ben Trengrove [G]]

Definitely sounds like an issue, please file

[Joseph Hawkes-Cates]

Issue logged, FYI

[Ben Trengrove [G]]

Thank you!