Skip to content

macOS: raise WebContentProcessTerminated when the web content process dies - #59

Open
markzielinski wants to merge 1 commit into
AvaloniaUI:mainfrom
markzielinski:feature/web-content-process-terminated-event
Open

macOS: raise WebContentProcessTerminated when the web content process dies#59
markzielinski wants to merge 1 commit into
AvaloniaUI:mainfrom
markzielinski:feature/web-content-process-terminated-event

Conversation

@markzielinski

Copy link
Copy Markdown
Contributor

What does the pull request do?

Adds a WebContentProcessTerminated event to NativeWebView and NativeWebDialog, raised on macOS and
iOS 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 WKNavigationDelegate
webViewWebContentProcessDidTerminate: callback, which the managed delegate does not implement — so an
application hosting content in NativeWebView has no way to observe the loss. The practical workaround
is an out-of-band liveness probe: we ship a production application on NativeWebView and currently run
a page-side heartbeat purely to detect this condition.

What is the updated/expected behavior with this PR?

The managed WKNavigationDelegate implements webViewWebContentProcessDidTerminate: and the macOS/iOS
adapter surfaces it through a new internal IWebViewAdapterWithProcessTermination capability, exposed as
a public WebContentProcessTerminated event on NativeWebView and NativeWebDialog. A typical handler
calls Refresh() or navigates again. Platforms whose adapters do not implement the capability are
unaffected; 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 content
process (kill -9 the "WebKit WebContent" process belonging to the application, or trigger
window.internals-free equivalents such as loading a page that exhausts renderer memory). Before this
change 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 ManagedWKNavigationDelegate class alongside the
current navigation callbacks (v@:@ signature, one unmanaged callback). The adapter forwards it through
the same capability-interface pattern used by IWebViewAdapterWithFocus and friends: the controls
subscribe at adapter creation and unsubscribe at destruction, and the event never fires on platforms
without the capability. WebView2's ProcessFailed could 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 terminated
content process previously required a heartbeat probe to detect.

…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.
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