Handle wkwebview web content process termination - #1619
Conversation
Package Changes Through cce2d80There are 1 changes which include wry with patch Planned Package VersionsThe following package releases are the planned based on the context of changes in this pull request.
Add another change file through the GitHub UI by following this link. Read about change files or the docs at github.com/jbolda/covector |
|
Thanks for the PR! What's your opinion on ionic-team/capacitor#6680 / ionic-team/capacitor#5488 ? This does seem to be a bit more controversial than you'd expect at first glance. |
|
It seems that it might be best to allow developers to handle the process termination event themselves so they can tailor the response to their own apps. Perhaps the WryNavigationDelegate could have an on_web_content_process_terminate_handler similar to the on_page_load_handler. |
|
sounds reasonable, good idea |
|
Great, I'll work on it later. |
|
Out of curiosity: |
|
Reloading the webview usually works. However, it reloads the current url instead of the root url, so apps that cannot reload the current url will have problems. Also, some people report problems with event handlers or plugins not working properly after reloading. |
|
@FabianLars I've added the handler. |
|
On further testing, reloading the webview in webViewWebContentProcessDidTerminate doesn't seem to solve the issue of the white screen. So this PR is no longer necessary. Another potential solution is to toggle the document body's display css property though javascript when the app will enter the foreground. |
…ep on macOS macOS aggressively suspends/terminates WKWebView's WebContent process during long screen-lock/sleep. Until tauri-runtime-wry 2.11.0, there was no default handler for this, so on resume the Tauri window remained alive but the webview rendered blank with no JS context — only an app restart recovered it. tauri-runtime-wry 2.11.x ships a default macOS/iOS handler that calls webview.reload() on web content process termination (via the new wry webViewWebContentProcessDidTerminate hook). We inherit this automatically by bumping the runtime. Bumps (via cargo update -p tauri --precise 2.11.1 in desktop/src-tauri): - tauri 2.10.3 -> 2.11.1 - tauri-runtime 2.10.1 -> 2.11.1 - tauri-runtime-wry 2.10.1 -> 2.11.1 - wry 0.54.4 -> 0.55.1 - tao 0.34.8 -> 0.35.2 - tauri-build 2.5.6 -> 2.6.1 - tauri-utils 2.8.3 -> 2.9.1 - @tauri-apps/api ~2.10 -> ~2.11 - @tauri-apps/cli ~2.10 -> ~2.11 Verified: - cargo check / clippy --no-deps / fmt --check on desktop/src-tauri: clean - pnpm typecheck / lint / build on desktop/: clean Refs: tauri-apps/tauri#10662, tauri-apps/tauri#14523, tauri-apps/wry#1619 Signed-off-by: Tyler Longwell <109685178+tlongwell-block@users.noreply.github.com>
…ep on macOS macOS aggressively suspends/terminates WKWebView's WebContent process during long screen-lock/sleep. Until tauri-runtime-wry 2.11.0, there was no default handler for this, so on resume the Tauri window remained alive but the webview rendered blank with no JS context — only an app restart recovered it. tauri-runtime-wry 2.11.x ships a default macOS/iOS handler that calls webview.reload() on web content process termination (via the new wry webViewWebContentProcessDidTerminate hook). We inherit this automatically by bumping the runtime. Bumps (via cargo update -p tauri --precise 2.11.1 in desktop/src-tauri): - tauri 2.10.3 -> 2.11.1 - tauri-runtime 2.10.1 -> 2.11.1 - tauri-runtime-wry 2.10.1 -> 2.11.1 - wry 0.54.4 -> 0.55.1 - tao 0.34.8 -> 0.35.2 - tauri-build 2.5.6 -> 2.6.1 - tauri-utils 2.8.3 -> 2.9.1 - @tauri-apps/api ~2.10 -> ~2.11 - @tauri-apps/cli ~2.10 -> ~2.11 CI install stability: - add pnpm fetch retry/timeout settings for transient Artifactory socket timeouts Verified: - cargo check / clippy --no-deps / fmt --check on desktop/src-tauri: clean - pnpm typecheck / lint / build on desktop/: clean Refs: tauri-apps/tauri#10662, tauri-apps/tauri#14523, tauri-apps/wry#1619 Signed-off-by: Tyler Longwell <109685178+tlongwell-block@users.noreply.github.com>
…ep on macOS macOS aggressively suspends/terminates WKWebView's WebContent process during long screen-lock/sleep. Until tauri-runtime-wry 2.11.0, there was no default handler for this, so on resume the Tauri window remained alive but the webview rendered blank with no JS context — only an app restart recovered it. tauri-runtime-wry 2.11.x ships a default macOS/iOS handler that calls webview.reload() on web content process termination (via the new wry webViewWebContentProcessDidTerminate hook). We inherit this automatically by bumping the runtime. Bumps (via cargo update -p tauri --precise 2.11.1 in desktop/src-tauri): - tauri 2.10.3 -> 2.11.1 - tauri-runtime 2.10.1 -> 2.11.1 - tauri-runtime-wry 2.10.1 -> 2.11.1 - wry 0.54.4 -> 0.55.1 - tao 0.34.8 -> 0.35.2 - tauri-build 2.5.6 -> 2.6.1 - tauri-utils 2.8.3 -> 2.9.1 - @tauri-apps/api ~2.10 -> ~2.11 - @tauri-apps/cli ~2.10 -> ~2.11 Verified: - cargo check / clippy --no-deps / fmt --check on desktop/src-tauri: clean - pnpm typecheck / lint / build on desktop/: clean Refs: tauri-apps/tauri#10662, tauri-apps/tauri#14523, tauri-apps/wry#1619 Signed-off-by: Tyler Longwell <109685178+tlongwell-block@users.noreply.github.com>
3 participants
For WKWebView, the webview's content process can get terminated, especially when the app is backgrounded. This results in a blank screen when you resume the app. To fix this, the webview can be reloaded in the webViewWebContentProcessDidTerminate method in WKNavigationDelegate.