Fix TransactionTooLargeException for large in-app messages

[franco-zalamena-iterable]

Summary

• Prevent large HTML content from being persisted in activity state bundles
• Avoid TransactionTooLargeException for in-app messages with large HTML

Test plan

• Test in-app messages with small HTML content
• Test in-app messages with large HTML (>250kb)
• Verify no crash on activity state save with large content
• Test screen rotation with in-app message displayed

🤖 Generated with Claude Code

[franco-zalamena-iterable]

PR Analysis

Problem: Large in-app message HTML (>250KB) is stored in the fragment arguments Bundle. When Android persists activity state via onSaveInstanceState, this bundle exceeds the Binder transaction limit (~1MB), causing TransactionTooLargeException.

Ideal fix plan:

• Stop putting HTML into the fragment arguments Bundle entirely
• Use a static or in-memory holder to pass HTML to the fragment
• Disable WebView state saving (setSaveEnabled(false)) to prevent it from persisting loaded content into the view hierarchy state
• Handle process-death recreation gracefully (HTML will be lost; dismiss the fragment)
• Clean up static references to avoid memory leaks

What the PR did:

• Replaced Bundle-based HTML passing with a static pendingHtmlString field
• Added webView.setSaveEnabled(false)
• Added null-HTML checks in onCreate and onCreateView that dismiss the fragment
• Cleans up pendingHtmlString in onDestroy
• Strips HTML from arguments in onSaveInstanceState
• Logs a warning for HTML >250KB

Assessment:

• Root cause identified: yes
• Fix correctness: correct -- the core approach (static field + no Bundle storage + WebView state disabled) addresses the root cause
• Missed:
  • The fallback args.getString(HTML_STRING, null) in onCreate is dead code -- HTML is never placed in the Bundle anymore since createInstance no longer calls args.putString(HTML_STRING, ...). This fallback will never trigger, making it misleading. Consider removing it or adding a comment that it only exists for a theoretical migration path.
  • The args.remove(HTML_STRING) in onSaveInstanceState is similarly dead code for the same reason -- nothing puts HTML into args anymore.
  • pendingHtmlString is not nulled out after being consumed in onCreate. It stays in memory until onDestroy. Consider nulling it right after assignment to htmlString in onCreate to reduce memory footprint, especially for the large-HTML case this fix targets.
  • On configuration change (e.g., screen rotation), the static field survives (same process), so the fragment will reconstruct fine. On process death, the static field is lost and the fragment correctly dismisses. This is the right behavior, but there is no unit test covering either scenario.
• Wrong assessment: none
• Tests: needed but missing -- there are no automated tests verifying: (1) HTML is not placed in the Bundle, (2) the fragment dismisses gracefully when pendingHtmlString is null (process-death case), (3) the static field is cleaned up in onDestroy. Given that this is a crash fix for a hard-to-reproduce issue, tests would provide valuable regression protection.