[$250] iOS - App crashes when pasting large text to the composer and backgrounding the app

[IuliiaHerets]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.0.50-5
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Y
Issue was found when executing this PR: #50487
Issue reported by: Applause Internal Team

Action Performed:

1. Navigate to https://www.lipsum.com/
2. Generate text with 10 000 words
3. Copy the generated text and the title and quotes under in at the top of the page
4. Open the app
5. Log in with a Gmail account
6. Open any 1:1 DM
7. Long tap inside the composer
8. Tap on "Paste"
9. Background the app
10. Foreground the app
11. Try to interact with the app
12. Repeat steps 9-11 until it crashes

Expected Result:

If the pasted text is longer than 10,000 characters, we should trim the text to 10,000 characters.

We can use a similar pattern to how we indicate the character limit in the Workspace name input field (but it would say Character limit reached (10,000/10,000) instead, or something similar)

Actual Result:

When pasting large text to the composer and backgrounding the app a few times, we attempt to paste the full text string, and the app crashes.

Workaround:

Unknown

Platforms:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6638032_1729189609126.Pmqw0322.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021859632203774875578
• Upwork Job ID: 1859632203774875578
• Last Price Increase: 2024-12-05
• Automatic offers:
• wildan-m | Contributor | 105221106

[melvin-bot]

Triggered auto assignment to @sakluger (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[IuliiaHerets]

@sakluger FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[sakluger]

Is this a separate bug from #48888? Or is it a regression from that issue's PR?

If we don't allow users to send messages over 10k characters, why would we allow them to paste over 10k characters in the composer? Why don't we just cut off everything over 10k?

[sakluger]

cc @anmurali @jasperhuangg @Pujan92 curious for your thoughts on the expected behavior here since you all were involved in #48888.

[melvin-bot]

@sakluger Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[sakluger]

I posted to Slack (https://expensify.slack.com/archives/C05LX9D6E07/p1729615084337139) asking for feedback on the expected behavior.

[Pujan92]

@sakluger I can't reproduce the crash. Also, this isn't a regression from the other issue.

Simulator.Screen.Recording.-.iPhone.15.Pro.-.2024-10-22.at.22.33.43.mp4

[sakluger]

This feels like a major edge case, especially given that @Pujan92 can't reproduce at all.

I'm going to close the issue for now. @IuliiaHerets - if you're still able to reproduce it, feel free to reopen. At that point, if we can consistently reproduce, then we'll likely change the behavior to auto-clip the text to 10k max characters.

[lanitochka17]

Issue is still reproducible on the latest build 9.0.63-3

Crash.long.text.mp4

[sakluger]

@lanitochka17 thanks for sharing the new video. Just to confirm, did you use the exact same reproduction steps, or did you modify the steps in any way?

[sakluger]

I updated the expected behavior in the OP to indicate that we should trim to 10,000 characters if the user tries pasting more than that.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~021859632203774875578

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @allroundexperts (External)

[wildan-m]

@sakluger show validation at 9999 might make user think they've reached the 10.000, but 1 char left. We might need a separate message, or maybe consult with the design team?

[melvin-bot]

@sakluger, @allroundexperts Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot]

@sakluger, @allroundexperts 6 days overdue. This is scarier than being forced to listen to Vogon poetry!

[sakluger]

@wildan-m I meant that the validation would check for > 9999 characters, not >= 9999 characters. So 9999 wouldn't trigger it, but 10,000 would.

@allroundexperts what do you think is best?

[allroundexperts]

I'd agree. Let's show the message when 10,000 characters are reached.

[wildan-m]

@sakluger @allroundexperts do we need to change the validation text?

While the current validation text might lead the user to believe that their message exceeds 10,000 characters, causing them to delete a character in order to avoid the validation message.

[sakluger]

Sure, let's change the validation text to:

Maximum character limit reached (10,000/10,000)

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[wildan-m]

Proposal Updated

• Add branch link
• Add adjustment for 10.000/10.000 validation message format based on this comment

[melvin-bot]

@sakluger, @allroundexperts Whoops! This issue is 2 days overdue. Let's get this updated quick!

[allroundexperts]

@wildan-m's proposal looks good to me.

🎀 👀 🎀 C+ reviewed

[melvin-bot]

Triggered auto assignment to @techievivek, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[melvin-bot]

📣 @wildan-m 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job
Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Keep in mind: Code of Conduct | Contributing 📖

[wildan-m]

@allroundexperts @techievivek, can we wait until this PR is merged on #52941? It also modifies the validation and may cause conflicts.

[sakluger]

@wildan-m just to confirm, you'd like to wait until that PR is merged before creating a new PR for this one? If so, I can change this issue to weekly while we wait.

[wildan-m]

Merged. working on the PR for this issue...

[melvin-bot]

@sakluger, @wildan-m, @allroundexperts, @techievivek Whoops! This issue is 2 days overdue. Let's get this updated quick!

[sakluger]

Not overdue - PR coming soon!

[wildan-m]

@sakluger @techievivek @allroundexperts what is the expectation if the composer already have text? we should trim combined text, right? not only the text from clipboard.

I couldn't find a solution without blinking in native, will this blinking acceptable?

Kapture.2024-12-12.at.16.19.40.mp4

Another thing to consider is -- we would trim the text value before markdown parsing right?
I'm asking this because each character / pattern will have character length that different with what actually visible.

For instance new line will have 6 character
Emoji can have more than two character
site url can have meta character more than 20 character, because it will be wrapped by anchor tag <a href ....

If we trim parsed value, then the performance might still slow because we'll need to parse it before we trim, also we can't predict if the trimmed text broke the parsed tag or not

i.e.

https://www.google.com

might be parsed as

<a href ="https://www.google.com" />

what if the trimmed result stop at <a href = ? I think that would create unexpected result.

If we agree with my suggestion (to trim text before parsed), then the length will not exactly 10.000 it can be more than it especially if the pasted text contain special pattern (emoji, new line, link, etc)

[sakluger]

what is the expectation if the composer already have text? we should trim combined text, right? not only the text from clipboard.

Yes, we should check the combined total and trim to 10k total characters.

I couldn't find a solution without blinking in native, will this blinking acceptable?

I didn't really notice the blinking, I think it's fine. @techievivek what do you think?

Another thing to consider is -- we would trim the text value before markdown parsing right?

I'll defer to @techievivek and @allroundexperts for this question.