Skip to content

WebViews: clear loading indicator on main-frame load errors#556

Open
jim-daf wants to merge 1 commit into
Waboodoo:developfrom
jim-daf:webview-clear-loading-on-error
Open

WebViews: clear loading indicator on main-frame load errors#556
jim-daf wants to merge 1 commit into
Waboodoo:developfrom
jim-daf:webview-clear-loading-on-error

Conversation

@jim-daf
Copy link
Copy Markdown

@jim-daf jim-daf commented May 20, 2026

Closes #555.

DocumentationWebView, ResponseBrowser and SinglePageBrowser all show a loading spinner that is hidden from inside onPageFinished (directly or via the onLoaded callback). None of them override onReceivedError, so a main-frame load failure leaves the spinner spinning forever:

showLoading()/isLoading = true
   -> network/cache error
   -> onPageFinished never fires
   -> hideLoading()/onLoaded() never runs

This is most reachable for the documentation view, which is configured with blockNetworkLoads = true and cacheMode = LOAD_CACHE_ELSE_NETWORK. The WebView is told to use only the cache, so a cache miss for the bundled documentation has no network fallback and the user is stuck on the spinner.

This PR adds onReceivedError(view, request, error) to each of the three WebViewClients and calls the same "loading is done" hook each one already uses:

override fun onReceivedError(view: WebView, request: WebResourceRequest, error: WebResourceError) {
    super.onReceivedError(view, request, error)
    if (request.isForMainFrame) {
        hideLoading() // or onLoaded(), depending on file
    }
}

Notes:

  • request.isForMainFrame is the guard so sub-resource errors are still ignored. The existing onPageFinished path is unchanged for successful loads.
  • One new import per file (android.webkit.WebResourceError). No new permission, no new resource, no new dependency.
  • Total diff is 24 lines added across 3 files.

DocumentationWebView, ResponseBrowser and SinglePageBrowser all show a
loading spinner that is hidden from inside onPageFinished (directly or
via the onLoaded callback). None of them override onReceivedError, so a
main-frame load failure leaves the spinner spinning forever:

  showLoading()/isLoading=true -> network/cache error -> onPageFinished
  never fires -> hideLoading()/onLoaded() never runs.

This is reachable in practice for the documentation view, which is
configured with blockNetworkLoads=true + cacheMode=LOAD_CACHE_ELSE_NETWORK
and so requires the bundled cache to be present; a cache-miss on a fresh
install means the user is stuck on the spinner.

Add onReceivedError on each WebViewClient and call hideLoading() /
onLoaded() for main-frame errors only. Sub-resource errors are still
ignored so we do not race the spinner off on transient asset failures.
No new permission, no behaviour change for successful loads.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Loading spinner gets stuck if a WebView load fails

1 participant