Handle WebView render process crash gracefully

[franco-zalamena-iterable]

Summary

• Add onRenderProcessGone handler to IterableWebViewClient to prevent app crashes when the Chromium renderer process dies
• Add the same handler to the anonymous WebViewClient in IterableInboxMessageFragment for inbox message WebViews
• Both handlers log the crash event, clean up the WebView via destroy(), and return true to absorb the crash

Test plan

• Verify WebView in-app messages display and function normally
• Verify inbox message WebViews display and function normally
• Verify Chromium renderer crash does not crash the host app (Android O+)
• Verify behavior on pre-Android O devices (falls through to default behavior)

🤖 Generated with Claude Code

[franco-zalamena-iterable]

PR Analysis

Problem: When the Chromium renderer process crashes (e.g., due to infinite loops or memory exhaustion), WebViews in the Iterable SDK do not handle the onRenderProcessGone callback. Since the default behavior is to terminate the host app, this causes the integrating app to crash.

Ideal fix plan:

• Override onRenderProcessGone in every WebViewClient used by the SDK, returning true to absorb the crash
• Clean up the dead WebView (call destroy(), null out references) to avoid stale state
• Gracefully dismiss the UI component hosting the WebView (dialog fragment for in-app messages, activity/fragment for inbox)
• Notify the in-app manager so it can resume its queue (a crashed in-app should not block subsequent messages)
• Log the event for diagnosability
• Add unit tests for the new callback

What the PR did:

• Added onRenderProcessGone override to IterableWebViewClient (used by in-app messages via IterableWebView)
• Added onRenderProcessGone override to the anonymous WebViewClient in IterableInboxMessageFragment (used by inbox message views)
• Both handlers: log the event, call view.destroy(), and return true
• IterableWebViewClient handler does NOT dismiss the hosting dialog/fragment
• IterableInboxMessageFragment handler calls getActivity().finish() to close the inbox view

Assessment:

• Root cause identified: yes -- the absence of onRenderProcessGone is correctly identified
• Fix correctness: partially correct -- returning true prevents the crash, which is the core fix. However:
  1. IterableWebViewClient does not dismiss the in-app UI. After the WebView is destroyed, the IterableInAppFragmentHTMLNotification dialog will remain visible but with a dead/blank WebView. The handler should dismiss the dialog (e.g., via dismissAllowingStateLoss()) and notify IterableInAppManager so the in-app queue is unblocked.
  2. view is never null inside onRenderProcessGone. The if (view != null) guard is dead code -- Android guarantees the view parameter is non-null in this callback.
  3. The Build.VERSION check is redundant. onRenderProcessGone is only called on API 26+ (Android O). The version guard inside the method body adds nothing. The @RequiresApi(Build.VERSION_CODES.O) annotation (or just relying on the fact that the callback is never invoked pre-O) would be cleaner.
  4. IterableInboxMessageFragment uses android.util.Log directly instead of IterableLogger, which is inconsistent with the rest of the SDK's logging approach and bypasses any log-level configuration the SDK provides.
  5. No nulling of the webView field reference after destroy() in either location. Code elsewhere (e.g., IterableInAppFragmentHTMLNotification.runResizeScript(), orientation listener) may still try to use the now-destroyed WebView, risking secondary crashes.
• Missed:
  • No integration with the in-app manager to unblock the message queue after a crash
  • No cleanup of the IterableInAppFragmentHTMLNotification dialog when the render process dies via IterableWebViewClient
  • The webView field reference is not nulled after destruction, leaving stale references
• Wrong assessment: none -- the direction is correct, just incomplete
• Tests: needed but missing -- onRenderProcessGone behavior should have at least a unit test verifying the return value and that destroy() is called on the WebView