macOS: raise WebContentProcessTerminated when the web content process dies - #59
Open
markzielinski wants to merge 1 commit into
Open
Conversation
…ted event When the web content process backing a WKWebView terminates - after a crash or after the operating system reclaims its memory - the native view stays alive but renders nothing, and WebKit performs no recovery on its own. The only signal is the WKNavigationDelegate webViewWebContentProcessDidTerminate: callback, which the managed delegate did not implement, so embedders had no way to observe the loss and reload. The managed WKNavigationDelegate now implements that callback and the macOS adapter surfaces it through a new IWebViewAdapterWithProcessTermination capability, exposed as a WebContentProcessTerminated event on NativeWebView and NativeWebDialog. The event follows the existing capability-interface pattern, so platforms without an equivalent signal are unaffected; WebView2's ProcessFailed can back the same event on Windows later.
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
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.
What does the pull request do?
Adds a
WebContentProcessTerminatedevent toNativeWebViewandNativeWebDialog, raised on macOS andiOS when the WKWebView's web content process terminates — after a renderer crash or after the operating
system reclaims its memory. This gives embedders the signal they need to recover (reload or re-navigate)
instead of leaving the user with a permanently blank view.
What is the current behavior?
When the web content process dies, WKWebView keeps the native view alive but renders nothing, and WebKit
performs no recovery on its own. The only signal is the
WKNavigationDelegatewebViewWebContentProcessDidTerminate:callback, which the managed delegate does not implement — so anapplication hosting content in
NativeWebViewhas no way to observe the loss. The practical workaroundis an out-of-band liveness probe: we ship a production application on
NativeWebViewand currently runa page-side heartbeat purely to detect this condition.
What is the updated/expected behavior with this PR?
The managed
WKNavigationDelegateimplementswebViewWebContentProcessDidTerminate:and the macOS/iOSadapter surfaces it through a new internal
IWebViewAdapterWithProcessTerminationcapability, exposed asa public
WebContentProcessTerminatedevent onNativeWebViewandNativeWebDialog. A typical handlercalls
Refresh()or navigates again. Platforms whose adapters do not implement the capability areunaffected; the event is documented as WebKit-only for now.
To test on macOS: host any page in
NativeWebView, subscribe to the event, and kill the web contentprocess (
kill -9the "WebKit WebContent" process belonging to the application, or triggerwindow.internals-free equivalents such as loading a page that exhausts renderer memory). Before thischange the view silently blanks; after it, the event fires and the handler can reload.
How was the solution implemented (if it's not obvious)?
The delegate method is registered on the existing
ManagedWKNavigationDelegateclass alongside thecurrent navigation callbacks (
v@:@signature, one unmanaged callback). The adapter forwards it throughthe same capability-interface pattern used by
IWebViewAdapterWithFocusand friends: the controlssubscribe at adapter creation and unsubscribe at destruction, and the event never fires on platforms
without the capability. WebView2's
ProcessFailedcould back the same event on Windows in a follow-up.Breaking changes
None. New public event; no existing behavior changes.
Fixed issues
None filed; found while hosting a long-running application in
NativeWebView, where a terminatedcontent process previously required a heartbeat probe to detect.