Skip to content

Redraw a webview page that replaces an earlier one - #5863

Open
LucaCappelletti94 wants to merge 4 commits into
DioxusLabs:mainfrom
LucaCappelletti94:upstream/android-activity-recreation
Open

LucaCappelletti94 wants to merge 4 commits into
DioxusLabs:mainfrom
LucaCappelletti94:upstream/android-activity-recreation

Conversation

@LucaCappelletti94

@LucaCappelletti94 LucaCappelletti94 commented Sep 24, 2026 •

Copy link
Copy Markdown

A recreated Android activity gets a new webview that reloads the page, but Dioxus never refilled it. The #4422 guard blocked the second load, initialize only triggered a rebuild once, and the edit queue waited forever for an ack from the dead page.

Each page desktop serves gets an increasing id. When a page's initialize callback fires, desktop ignores it if the id belongs to a page that was already replaced or already initialized once. For an actual replacement page, it opens a fresh edits connection, writes the page's head elements, then calls VirtualDom::remount_render_target (introduced in #5886) to redraw the body. Only Android may load the index again, so desktop keeps #4422's behaviour there.

DOM-only state and pending eval queries do not survive. Tested on a Galaxy M52 (fresh install, asset-path change, dark mode, font scale).

Since this PR is "stacked" on #5862 and #5886, review only the last two commits (the webview redraw and the connection-reset tests).

Part of #5885, resolves the Android portion of the issue.

telegram-cloud-photo-size-4-5911119676983415469-y

@LucaCappelletti94
LucaCappelletti94 force-pushed the upstream/android-activity-recreation branch 3 times, most recently from 272a719 to aaccbe0 Compare October 3, 2026 11:26

This branch has not been deployed

No deployments
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.

1 participant