Description
GutenbergView never overrides WebViewClient.onRenderProcessGone. When Android's WebView renderer process dies, the default behaviour is to kill the process hosting the WebView — so a renderer crash inside the editor takes the whole app down rather than just the editor.
iOS handles the equivalent case: controllerWebContentProcessDidTerminate resets readiness and reloads the web view, so the editor recovers in place.
$ grep -rn "onRenderProcessGone\|RenderProcessGoneDetail" android/Gutenberg/src/main/java/org/wordpress/gutenberg/
(no matches)
This is separate from the editor's JavaScript ErrorBoundary crash, which is handled in #638, #640 and #642. Those cover a React error that unmounts the editor while the renderer stays alive. This issue is the renderer process itself dying — out-of-memory being the most common cause on lower-end devices.
Step-by-step reproduction instructions
- Open the editor in the demo app or WordPress-Android.
- Terminate the renderer process for the editor's WebView. Either:
adb shell am kill <renderer process> — the sandboxed renderer appears as a child process of the app, or
- navigate the WebView to
chrome://crash from chrome://inspect.
- Observe the app process dies rather than the editor recovering.
Expected: the editor recovers, or at minimum reports an unusable editor to the host without terminating the app.
Suggested fix
Override onRenderProcessGone on the WebViewClient, return true to signal the crash was handled, and reuse the recovery path added in #642:
override fun onRenderProcessGone(view: WebView?, detail: RenderProcessGoneDetail?): Boolean {
isEditorLoaded = false
reloadEditor()
return true
}
Returning true is what prevents Android from killing the process. Note the WebView whose renderer died cannot be reused for rendering in all cases, so this may require recreating the WebView rather than reloading it — worth verifying against detail.didCrash() to distinguish a genuine crash from the system reclaiming memory.
Content recovery comes for free through LatestContentProvider, the same path reloadEditor() already uses.
Environment info
- GutenbergKit
trunk
- Android — all versions;
onRenderProcessGone is available from API 26 and the module's minSdk is above that.
🤖 Generated with Claude Code
https://claude.ai/code/session_01VuxMbKtUsaUF8nUVgKdxwK
Description
GutenbergViewnever overridesWebViewClient.onRenderProcessGone. When Android's WebView renderer process dies, the default behaviour is to kill the process hosting theWebView— so a renderer crash inside the editor takes the whole app down rather than just the editor.iOS handles the equivalent case:
controllerWebContentProcessDidTerminateresets readiness and reloads the web view, so the editor recovers in place.This is separate from the editor's JavaScript
ErrorBoundarycrash, which is handled in #638, #640 and #642. Those cover a React error that unmounts the editor while the renderer stays alive. This issue is the renderer process itself dying — out-of-memory being the most common cause on lower-end devices.Step-by-step reproduction instructions
adb shell am kill <renderer process>— the sandboxed renderer appears as a child process of the app, orchrome://crashfromchrome://inspect.Expected: the editor recovers, or at minimum reports an unusable editor to the host without terminating the app.
Suggested fix
Override
onRenderProcessGoneon theWebViewClient, returntrueto signal the crash was handled, and reuse the recovery path added in #642:Returning
trueis what prevents Android from killing the process. Note theWebViewwhose renderer died cannot be reused for rendering in all cases, so this may require recreating theWebViewrather than reloading it — worth verifying againstdetail.didCrash()to distinguish a genuine crash from the system reclaiming memory.Content recovery comes for free through
LatestContentProvider, the same pathreloadEditor()already uses.Environment info
trunkonRenderProcessGoneis available from API 26 and the module'sminSdkis above that.🤖 Generated with Claude Code
https://claude.ai/code/session_01VuxMbKtUsaUF8nUVgKdxwK