Prevents TransactionTooLargeException error in WebViewActivity

[antonis]

Fixes #9685

Description

This PR targets the third common TransactionTooLargeException crash occurring when the WebView state is too big (the other two were cover by #19747 and #20046).
In this case the crash stack trace is like the following indicating a huge WEBVIEW_CHROMIUM_STATE:

android.os.TransactionTooLargeException: data parcel size 555708 bytes
    at android.os.BinderProxy.transactNative(BinderProxy.java)
    at android.os.BinderProxy.transact(BinderProxy.java:662)
    at android.app.IActivityClientController$Stub$Proxy.activityStopped(IActivityClientController.java:1507)
    at android.app.ActivityClient.activityStopped(ActivityClient.java:100)
    at android.app.servertransaction.PendingTransactionActions$StopInfo.run(PendingTransactionActions.java:135)
    at android.os.Handler.handleCallback(Handler.java:958)
    at android.os.Handler.dispatchMessage(Handler.java:99)
    at android.os.Looper.loopOnce(Looper.java:230)
    at android.os.Looper.loop(Looper.java:319)
    at android.app.ActivityThread.main(ActivityThread.java:8913)
    at java.lang.reflect.Method.invoke(Method.java)
    at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:608)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1103)
java.lang.RuntimeException: android.os.TransactionTooLargeException: data parcel size 555708 bytes
Bundle stats:
  android:viewHierarchyState [size=3228]
    android:views [size=3124]
  androidx.lifecycle.BundlableSavedStateRegistry.key [size=1056]
  WEBVIEW_CHROMIUM_STATE [size=550620]
PersistableBundle stats:
  [null]
    at android.app.servertransaction.PendingTransactionActions$StopInfo.run(PendingTransactionActions.java:146)
    at android.os.Handler.handleCallback(Handler.java:958)
    at android.os.Handler.dispatchMessage(Handler.java:99)
    at android.os.Looper.loopOnce(Looper.java:230)
    at android.os.Looper.loop(Looper.java:319)
    at android.app.ActivityThread.main(ActivityThread.java:8913)
    at java.lang.reflect.Method.invoke(Method.java)
    at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:608)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1103)

Two approaches have been tested (see #9685 (comment)) and the hacky alternative was considered safer since it is applied only when the app is about to crash. Due to the wide usage of this part of the code affecting the SSLCertsViewActivity, the WPWebViewActivity which is used across the app and also extended by:DomainRegistrationCheckoutWebViewActivity, DomainManagementDetailsActivity, ThemeWebActivity, SupportWebViewActivity and JetpackConnectionWebViewActivity a more radical change might have unpredicted impact.
A new track event was also added to analyse the cases when the crash occurs, so that we can iterate with a more targeted fix if this is feasible.

The fix involves removing the WEBVIEW_CHROMIUM_STATE from the saved Bundle when it exceeds a certain threshold (300KB). When the state is removed the url is reloaded on restore.

Note that the behaviour of the saveState method has changed since this part of the code was introduced 9 years ago and the method no longer stores the display data for the WebView but just the browsing history. The same approach is also used in Chromium.

---

To Test:

• Verify that the behaviour did not change for usual webview loading. You can use the site preview in the My site screen for this.
• Since reproducing the crash is not easy set the threshold to a small value (e.g. with this patch webview.patch) and:

1. Open a WebView (the site preview in the My site screen)
2. Rotate the device
3. Verify that the page reloads
4. Verify that an event webview_too_large_payload_error, Properties: {"url":...} is tracked

---

Regression Notes

1. Potential unintended areas of impact

   • Almost all WebViews

2. What I did to test those areas of impact (or what existing automated tests I relied on)

   • Manual testing

3. What automated tests I added (or what prevented me from doing so)

   • None due to the structure of the code

---

PR Submission Checklist:

• I have completed the Regression Notes.
• I have considered adding accessibility improvements for my changes.
• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

---

Testing Checklist:

• WordPress.com sites and self-hosted Jetpack sites.
• Portrait and landscape orientations.
• Light and dark modes.
• Fonts: Larger, smaller and bold text.
• High contrast.
• Talkback.
• Languages with large words or with letters/accents not frequently used in English.
• Right-to-left languages. (Even if translation isn’t complete, formatting should still respect the right-to-left layout)
• Large and small screen sizes. (Tablet and smaller phones)
• Multi-tasking: Split screen and Pop-up view. (Android 10 or higher)

[wpmobilebot]

📲 You can test the changes from this Pull Request in WordPress by scanning the QR code below to install the corresponding build.

	App Name	WordPress
	Flavor	Jalapeno
	Build Type	Debug
	Version	pr20139-3a947fd
	Commit	3a947fd
	Direct Download	wordpress-prototype-build-pr20139-3a947fd.apk

Note: Google Login is not supported on these builds.

[wpmobilebot]

📲 You can test the changes from this Pull Request in Jetpack by scanning the QR code below to install the corresponding build.

	App Name	Jetpack
	Flavor	Jalapeno
	Build Type	Debug
	Version	pr20139-3a947fd
	Commit	3a947fd
	Direct Download	jetpack-prototype-build-pr20139-3a947fd.apk

Note: Google Login is not supported on these builds.

[dangermattic]

	1 Warning
⚠️	This PR is assigned to the milestone 24.2 ❄️. The due date for this milestone has already passed. Please make sure to get it merged by then or assign it to a milestone with a later deadline.

Generated by 🚫 Danger

[peril-wordpress-mobile]

	Warnings
⚠️	This PR is assigned to a milestone which is closing in less than 4 days Please, make sure to get it merged by then or assign it to a later expiring milestone

Generated by 🚫 dangerJS

[mkevins]

Thank you for this fix. I was not able to reproduce the original crash, but I was able to confirm the fix is tracked by applying your suggested patch. Tested on a Pixel 3a (physical device). The code changes are reasonable, especially considering the same technique is used in the Chromium source.

Nice work Antonis!