WebView fails to load after reboot if WiFi is slow to connect

[kimsey0]

I'm running ImmichFrame Android on a cheap Frameo device. After a device reboot, the app displays a black screen when Use WebView? is enabled. The screen remains black indefinitely.

Root Cause

After investigating with diagnostic logging, I found that:

1. The app launches before WiFi has connected
2. WebView attempts to load the URL with no network available
3. WebView "finishes" loading without triggering onReceivedError - it silently fails
4. The existing retry logic in onReceivedError never fires, so no retry occurs
5. Result: permanent black screen

When I disable Use WebView?, the app shows toast messages like "Retrying to fetch server settings... Attempt X of 36" and eventually succeeds once WiFi connects. This confirms the issue is specific to WebView's silent failure behavior.

Background

I understand the previous waitForNetwork check was removed in response to #21, where a VPN user found that Android's NET_CAPABILITY_INTERNET check returned false even when their VPN tunnel was working and could reach the ImmichFrame server.

Proposed Solution

Instead of relying on Android's network validation (which fails for VPN users) or WebView's error callbacks (which don't fire reliably), check actual server reachability before loading the WebView:

fun isServerReachable(url: String): Boolean {
    return try {
        val client = OkHttpClient.Builder()
            .connectTimeout(5, TimeUnit.SECONDS)
            .readTimeout(5, TimeUnit.SECONDS)
            .build()
        val request = Request.Builder().url(url).head().build()
        client.newCall(request).execute().use { response ->
            response.isSuccessful || response.code in 300..499
        }
    } catch (e: Exception) {
        false
    }
}

Then retry with toast feedback until the server is reachable.

Why this works for both cases:

• Slow WiFi at boot: Server unreachable → retry until WiFi connects
• VPN users: Once VPN tunnel is up, server is reachable even if Android reports "no internet"

This tests what actually matters: "can I reach my ImmichFrame server?"

I have a working implementation and can submit a PR if this approach is acceptable.

[3rob3]

I like your approach. As you have noticed I've tried various ways to tackle this in the past, each with it's own trade-off. I will review PR fully later today.

[JW-CH]

@coderabbitai review

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Fetch details of issue #33
gh issue view 33 --repo immichFrame/ImmichFrame_Android --json title,body,number,state,labels,author,comments,url

# Check for linked PRs to this issue
gh pr list --repo immichFrame/ImmichFrame_Android --search "33 in:body OR 33 in:title" --json number,title,url,state,author

# Also search for PRs that might reference this issue
gh pr list --repo immichFrame/ImmichFrame_Android --state all --limit 10 --json number,title,url,state,author,body | jq '.[] | select(.body | contains("#33") or contains("issue/33"))'

Length of output: 10037

---

🏁 Script executed:

#!/bin/bash
# Fetch PR #34 details and the diff
gh pr view 34 --repo immichFrame/ImmichFrame_Android --json title,body,files,additions,deletions,changedFiles,url,state,author

# Get the diff for the PR
gh pr diff 34 --repo immichFrame/ImmichFrame_Android

Length of output: 6862

---

@JW-CH, I've reviewed issue #33 and PR #34. Here's my analysis:

Overview

PR #34 implements a server reachability check before loading WebView, addressing the black screen issue that occurs when the app launches before WiFi connects after a device reboot.

Implementation Analysis

✅ Strengths

1. Root Cause Resolution: The solution directly addresses the WebView silent failure problem by proactively checking server reachability instead of relying on WebView's unreliable error callbacks.

2. VPN Compatibility: Using direct HTTP HEAD requests avoids Android's NET_CAPABILITY_INTERNET check, which was problematic for VPN users (issue Feature Request: Allow to skip connectivity check #21).

3. Proper Concurrency: Network I/O is correctly performed on Dispatchers.IO, avoiding main thread blocking.

4. Consistent User Experience: Retry behavior (36 attempts × 5 seconds) matches the non-WebView mode, providing familiar feedback.

5. Graceful Degradation: After exhausting retries, the WebView loads anyway as a fallback, allowing manual intervention.

6. HTTP Status Code Handling: Treating 3xx/4xx responses as "reachable" is appropriate since these indicate the server is responding.

🔍 Minor Observations

1. Code Duplication: The loadWebViewWithRetry() function is duplicated in MainActivity and ScreenSaverService. Consider extracting to a shared helper class for maintainability:

// In Helpers.kt
fun loadWebViewWithRetry(
    context: Context,
    webView: WebView,
    handler: Handler,
    url: String,
    attempt: Int = 1,
    maxAttempts: Int = 36
) { /* implementation */ }

2. Memory Leak Prevention: The existing handler.removeCallbacksAndMessages(null) in onDestroy() properly prevents leaks from delayed callbacks.

3. Timeout Tuning: The 5-second connect/read timeout is aggressive but reasonable given the 5-second retry interval. This could be made configurable if users report issues.

Verdict

This is a well-designed solution that elegantly solves the boot-time connectivity issue while maintaining compatibility with VPN scenarios. The implementation is sound, and the approach is superior to previous attempts using Android's network state APIs.

Recommendation: Approve with optional refactoring to reduce code duplication.