android: reliable offline startup (#854) - #1693
Open
Suncadgeek wants to merge 2 commits into
Open
Conversation
When the app is launched without connectivity and no cached copy is available, show a friendly offline page instead of the raw Chromium error page, and reload automatically when the connection returns (network callbacks on the native side, online event and periodic retry from the page itself). The page is served from the app origin with loadDataWithBaseURL and an in-page reload is issued once after recovery: a page that commits in a fresh renderer process on the offline path can otherwise end up never painted (observed with the Vanadium WebView; reproducible on unmodified master). Also register a ServiceWorkerClient mirroring the 127.0.0.1 native API interception, since requests going through a service worker bypass the WebViewClient.
The web app cannot rely on the online event to refresh after a network loss: behind an always-on VPN the browser never observes the network going away. The native side does know, so soft-refresh the timeline when a validated network returns after a loss.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is the native half of #854. Today, launching the app without a working connection shows the raw Chromium error page (or hangs on a blank screen when requests stall instead of failing, which is what happens behind an always-on VPN), and the user has no way out but to retry manually.
With this change:
When the main frame fails to load and no cached copy is available, a friendly offline page is shown (same style as the welcome page) with a retry button, and the app reloads automatically as soon as connectivity returns. Reloads are driven both by the network callbacks on the native side (including a check for the VALIDATED capability, since onAvailable can fire before the network is actually usable) and by a periodic retry from the page itself.
A ServiceWorkerClient is registered mirroring the 127.0.0.1 interception of the WebViewClient. Requests going through a service worker bypass the WebViewClient, so without this the local photo APIs break as soon as the service worker controls the page.
The timeline is soft-refreshed when a validated network returns after a loss. The web app cannot rely on the online event for this: behind an always-on VPN the browser never observes the network going away.
A one-shot in-page reload is issued after an offline recovery. We observed pages that commit in a fresh renderer process on this path ending up never painted (Vanadium WebView on GrapheneOS, reproducible on unmodified master); an in-page reload in the same process reliably repaints.
checkCredentialsAndVersion now documents that parsing the body before the 401 check is what protects stored credentials from being wiped by captive portals.
Tested on a Pixel 7 (Android 16, GrapheneOS): airplane-mode cold start with and without caches, automatic recovery when connectivity returns, login flow, video playback and local photos unaffected. Works best together with the web-side changes in the companion PR, but is independently useful.