fix: handle WebView initialization failure gracefully (#1013)

[franco-zalamena-iterable]

Summary

Wraps IterableWebView instantiation in IterableInAppFragmentHTMLNotification.onCreateView() with a try-catch to handle AndroidRuntimeException when the WebView process is unavailable or fails to initialize. Instead of crashing, the SDK now logs the error and dismisses the in-app message gracefully.

Changes

• Broadened createWebViewSafely() to catch Exception as a final fallback (in addition to Resources.NotFoundException and RuntimeException), with an explicit comment about AndroidRuntimeException from WebViewFactory
• Added try-catch in IterableWebView.createWithHtml() to guard against exceptions during WebView configuration/setup
• Added TAG constant to IterableWebView for consistent log tagging

Test plan

• Verify in-app messages load normally on healthy devices
• Verify no crash occurs when WebView is unavailable (e.g., on emulators with disabled WebView)
• Verify error is logged when WebView fails to initialize

Made with Cursor

[franco-zalamena-iterable]

PR Analysis

Problem: AndroidRuntimeException (wrapping InvocationTargetException) is thrown during new IterableWebView(context) when the WebView provider fails to initialize, crashing the app. The stack trace shows the crash originates from WebViewFactory.getProvider() during WebView construction in onCreateView.

Ideal fix plan:

• The crash occurs in the IterableWebView constructor (called from onCreateView). The correct fix is to wrap the new IterableWebView(context) call in a try-catch that handles RuntimeException (which AndroidRuntimeException extends) and gracefully dismiss the in-app message if it fails.
• This is exactly what PR [SDK-368] Fix in-app creation causing crash due to problems with webview #999 (createWebViewSafely) already did, and it shipped in 3.6.6. The issue reporter lists SDK versions 3.6.5 and 3.6.6, but the stack trace line number (IterableInAppFragmentHTMLNotification.java:203) points to a direct new IterableWebView() call in onCreateView without the createWebViewSafely wrapper, which matches the 3.6.5 code path. On 3.6.6+, createWebViewSafely already catches RuntimeException, which covers AndroidRuntimeException.

What the PR did:

• Added an explicit RuntimeException catch before the existing generic RuntimeException catch in createWebViewSafely (the new catch is functionally identical since AndroidRuntimeException extends RuntimeException)
• Added a blanket catch (Exception e) fallback after RuntimeException
• Wrapped the entire body of IterableWebView.createWithHtml() in a try-catch for Exception

Assessment:

• Root cause identified: partially -- the crash is correctly identified as AndroidRuntimeException during WebView init, but the PR does not acknowledge that createWebViewSafely (added in PR [SDK-368] Fix in-app creation causing crash due to problems with webview #999 / 3.6.6) already catches RuntimeException, which covers this exact exception. The issue is most likely a 3.6.5 problem that is already resolved.
• Fix correctness: not wrong but redundant -- the explicit RuntimeException catch added before the existing RuntimeException catch in createWebViewSafely is a no-op because AndroidRuntimeException extends RuntimeException, so the existing catch block already handles it. The catch (Exception) fallback adds marginal defense-in-depth but is unlikely to ever trigger since all checked exceptions in the WebView construction path are already subtypes of RuntimeException.
• Missed:
  • The PR does not investigate whether this crash actually reproduces on 3.6.6+ (where createWebViewSafely already exists). The stack trace line numbers suggest the crash is from 3.6.5.
  • The try-catch in createWithHtml() silently swallows exceptions but leaves the WebView in a partially initialized state (constructed but not configured). The caller (onCreateView) then proceeds to use this half-configured WebView (e.g., adding it to the layout, setting up listeners). This could lead to follow-on issues. If createWithHtml() fails, the method should signal the failure to the caller so the in-app can be dismissed.
• Wrong assessment: The PR comments and commit message suggest AndroidRuntimeException was not previously caught, but it was -- RuntimeException is its superclass and was already caught since PR [SDK-368] Fix in-app creation causing crash due to problems with webview #999.
• Tests: needed but missing -- at minimum, a unit test verifying that createWebViewSafely returns null (and the fragment dismisses) when WebView construction throws AndroidRuntimeException would confirm the existing safety net works and prevent regressions.