fix: prevent TransactionTooLargeException when attaching a file while replying to a message with a large HTML quote

[mvanhorn]

Contribution Summary

Linked Issue/Ticket: Fixes #9425

Description

In QuotedMessagePresenter.onSaveInstanceState the offending line is outState.putSerializable(STATE_KEY_HTML_QUOTE, quotedHtmlContent). Guard this put by the character length of the quoted content (quotedHtmlContent.getQuotedContent()): only persist the HTML quote into the saved-state Bundle when it is below a safe threshold well under the Binder limit (e.g. a ~256 KB / ~262144-char cap defined as a constant), and skip the put when it is larger. This eliminates the oversized parcel and therefore the crash. To keep the size check unit-testable without standing up the full presenter (whose constructor pulls DI singletons and a MessageCompose/view), extract the decision into a small pure helper (e.g. a package-visible static shouldPersistQuotedHtml(InsertableHtmlContent, int maxChars) / size computation) that onSaveInstanceState calls. onRestoreInstanceState already null-checks quotedHtmlContent, so when the quote was skipped the composer degrades gracefully rather than crashing: the user's typed text (saved separately by the EditText) is preserved, and only the rarely-hit "process killed while the picker is open, then recreated" path loses the re-displayable quote - an acceptable trade versus a guaranteed crash on every attach. MessageCompose.java is the caller of onSaveInstanceState but requires no change, so it is intentionally excluded from the scope list.

Screen Shots

N/A - no UI change; the fix guards saved-state serialization of the quoted-HTML in QuotedMessagePresenter.

AI Disclosure

Select one of the following (mandatory)

• This contribution does not include any changes created or assisted by AI.
• This contribution includes changes assisted by AI.
• This contribution includes changes created by AI.

Contribution Checklist

• I have read and affirm that my contribution adheres to Mozilla's Community Participation Guidelines
• This contribution is in Kotlin where possible
• This contribution does not use merge commits
• This contribution adheres to the existing codestyle (spotless)
• This contribution does not break existing unit tests
• This contribution includes tests for any new functionality, and maintains tests for any updated functionality
• This contribution adheres to our Engineering process (RFC/Technical Design/ADR)
• This PR has a descriptive title and body that accurately outlines all changes made, and references the issue it fixes (Fixes Error when attaching file or image when we reply #9425).

[github-actions]

Missing report label. Set exactly one of: report: include, report: exclude OR report: highlight.

[killpt]

Hi @mvanhorn,

Any news when this issue will be solved?

Thanks,

[wmontwe]

@mvanhorn Thanks for finding the source of the issue and proposing a quick fix. This prevents the crash, but does so by silently omitting oversized quoted HTML from the saved state. After activity recreation, this could alter the composed message or cause part of its state to be lost.
Large composer content shouldn’t be stored in savedInstanceState. The bundle should contain only small restoration metadata, such as a draft identifier. The composer’s working state should instead be persisted as a draft and restored from there.
I think this requires a broader rework of composer-state persistence rather than an arbitrary size cutoff.

[mvanhorn]

You were right that the size cutoff was the wrong shape. Trading a crash for silent content loss is not a fix, and an arbitrary threshold would have been a permanent source of "my reply lost the quoted part" reports. Pushed 8ebaeff taking the approach you described instead.

• savedInstanceState now carries only a draft reference, STATE_KEY_RESTORE_FROM_DRAFT, rather than composer content.
• When the activity is recreated with that reference present, the composer restores its working state from the draft.
• In that path the composer view hierarchy has saving disabled via setSaveFromParentEnabled(false), so the view layer cannot write the content back into the bundle behind our backs. That was the part I would have missed: removing our own explicit put is not enough while the EditTexts are still saving themselves.
• The size-threshold tests are replaced by one asserting the saved state carries only quote restoration metadata.

On verification, so you know exactly what has and has not been checked: :legacy:ui:legacy:compileDebugJavaWithJavac builds and QuotedMessagePresenterTest passes locally. That is the limit of it. I have not exercised real activity recreation, low-memory process death, or the interaction with an existing draft on a device, and those are precisely where this could still be wrong. Given this sits on the draft-persistence path, I would rather you look at the approach before trusting it than have me claim more confidence than I have.

Two things I am unsure about and would value your view on: whether restoring from draft should also cover the case where no draft has been saved yet at recreation time, and whether disabling parent save on the whole composer container is too broad a hammer compared with targeting the specific views.