Conversation
WebViewActivity saved no state at all, so when Android reclaimed the process the activity came back on the start URL with the scroll position, open view and form contents gone. Cookies survive on disk, so this was never a logout, just a reset. Save through WebViewCompat, which drops the oldest history entries to fit a byte budget instead of risking TransactionTooLargeException: the 1MB savedInstanceState limit is shared by the whole process, and web apps that are not sandboxed all live in the main one. Forward entries are dropped too, since there is no forward button. Only saves where the WebView reports SAVE_STATE. Falling back to the framework saveState would reintroduce exactly the crash the budget exists to avoid.
Going back re-ran the page load. With the back-forward cache the previous page is restored from memory, which is what makes in-app back feel instant rather than like a browser reload.
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.
WebViewActivitysaves no state, so when Android reclaims the process the activitycomes back on the start URL with the scroll position, open view and form contents
gone. Cookies live on disk, so it was never a logout — but every reclaim throws the
user back to the top of the app.
Saving
Through
WebViewCompat.saveStaterather than the frameworkWebView.saveState.The 1MB
savedInstanceStatebudget is shared by the whole process, and web appswithout sandboxing all live in the main one, so several open web apps can exceed it
together and crash with
TransactionTooLargeException. The Jetpack call takes a bytebudget and drops the oldest history entries to fit, without touching the live history,
so backward navigation stays intact. Forward entries are dropped as well, since there
is no forward button in the UI.
Only saves where the WebView reports
SAVE_STATE. Falling back to the framework callwould reintroduce exactly the crash the budget exists to prevent, so older WebViews
keep today's behaviour instead — no restore, but no new failure mode either.
The second commit turns on the back-forward cache, so going back inside a web app
restores the previous page from memory instead of re-running the load.
androidx.webkitgoes 1.13.0 → 1.17.0 for both. It needsminCompileSdk33, which islower than the 34 required by 1.13.0, so this is independent of the targetSdk work
in #231 and applies to
devas it stands.Testing
On a Pixel running Android 17 (API 37, WebView 151), killing the backgrounded process
with
am killto reproduce what the system does under memory pressure:at the top.
restored, no
TransactionTooLargeException, no crash in logcat. This is the casethe byte budget exists for.
stays hidden until it is answered, so the biometric path is unaffected.
Not verified: that the back-forward cache actually shortens back navigation. Enabling
the flag follows the documented API, but I could not measure the difference without
instrumenting WebView's network activity, so treat that commit as untested rather than
proven.
One thing I noticed while testing and did not touch:
setupWebView()runsunconditionally after the biometric branch in
onCreate, so a protected web appissues its network request before the prompt is answered. The content is not shown —
the view is hidden — so this is not a visual leak, and it predates this change. Happy
to fix it separately if you want.