fix: preserve Markdown formatting in long messages

[Uzaifm127]

Explanation of Change

ExpensiMark.replace() was optimized to avoid running the autolink, bold, and strikethrough regexes over the complete text on every change. The scanner first finds small possible URL and Markdown candidates, then the existing ExpensiMark regexes validate and replace only those candidates.

This keeps the existing parsing behavior while reducing the work required for long composer messages.

react-native-live-markdown now allows parseExpensiMark function callers to provide the maximum length passed to parseExpensiMark.

App uses CONST.MAX_MARKUP_LENGTH, which is 10,000 characters. This PR passes that value to all the locations in the App that use parseExpensiMark for composer Markdown parsing and selected-text formatting, instead of using the library default of 4,000.

Fixed Issues

$ #95210
PROPOSAL: #95210 (comment)

Tests

Note

The complete composer text, including the Markdown added during testing, must contain more than 4,000 and fewer than 10,000 characters.

Test 1 (All platforms)

Note

Android native has a separate known typing-delay issue with long text, which will be handled in a follow-up. Do not fail this PR because of that delay. For Android native, verify that Markdown remains preserved after 4,000 characters. On the other platforms, also verify that typing remains responsive.

1. Go to staging.new.expensify.com or open Expensify App
2. Login with any account
3. Go to any chat
4. Paste any long text (4000+ characters) containing markdown (bold, italic, strikethrough and autolink).
5. Try to write something after pasting.
6. Verify that the typing experience is smooth and it doesn't lag or freezes while typing.
7. Verify that the markdown is preserved when we type after pasting 4000+ characters text in the composer.

Test 2 (Web)

1. Open https://staging.new.expensify.com/
2. Go to any chat.
3. Paste the long text more than 4000 characters in the composer containing bold and italic (the long text must include bold and italic markdown formatting).
4. Select only bold, without selecting the stars (*).
5. Press Cmd+B on macOS or Ctrl+B on Windows
6. Verify that the surrounding stars are removed and the text becomes plain.
7. Select italic, without underscores.
8. Press Cmd+I or Ctrl+I.
9. Verify that the underscores are removed and the text become plain.
10. Select the plain text again and repeat the shortcuts.
11. Verify that the plain text becomes bold on pressing cmd/ctrl + b and becomes italic on pressing cmd/ctrl + i.

Test 3 (All platforms)

1. Open any chat.
2. Paste plain text containing more than 4,000 characters, while keeping the complete composer text under 10,000 characters.
3. On a new line, paste `😄` without selecting any existing text.
4. Verify that the emoji inside the backticks is converted to `:smile:`.
5. On another new line, paste :smile: and `:wave:` without selecting any existing text.
6. Verify that :smile: outside the backticks becomes 😄.
7. Verify that :wave: inside the backticks remains unchanged.

Test 4 (All platforms)

Note

There are no suggestions in the composer in iOS native app either we type in the code range or outside the code range and this issue also exist in existing main so this Test 4 can't reliably be performed on iOS native. This existing issue only reproducible after composer has 4000 characters.

1. Open any chat.
2. Paste plain text containing more than 4,000 characters, while keeping the complete composer text under 10,000 characters.
3. On a new line, type two backticks.
4. Place the cursor between the backticks and type :smi, for example: `:smi`.
5. Verify that emoji suggestions do not appear because the cursor is inside a complete code range.
6. Type :smi outside the backticks.
7. Verify that emoji suggestions appear outside the code range.

• Verify that no errors appear in the JS console

Offline tests

Same as Test

QA Steps

Note

Tests 1, 2, 3 and 4 are the same as the corresponding tests in the Tests section above.

Test 1: Malformed HTML and HTML-boundary parsing

1. Open the App on Web.

2. Open the Devtool by right clicking on the App and select a inspect or press F12.

3. In Chrome DevTools, select the Network tab.

4. Go to Workspaces > workspace > Members > Invite member.

5. Enter an email address that is not already a workspace member.

6. Continue to the invitation message step.

7. Replace the invitation message with:

   before.com <unfinished after.com
   

8. Clear the Network panel in devtool.

9. Click Invite.

10. Open the AddMembersToWorkspace API request.

11. Inspect the welcomeNote in the payload of API.

12. Verify that both before.com and after.com are converted into links.

13. Repeat the same test with the following cases:

• Case: *bold* >

  expected: *bold* >

• Case: ~strike~ >

  expected: ~strike~ >

• Case: <unfinished example.com 😄

  expected: <unfinished <a href="https://example.com" target="_blank" rel="noreferrer noopener">example.com</a> <emoji>😄</emoji>

Test 2: Long invalid .comx URL candidate

1. Open the App.
2. Open any chat.
3. Paste the text containing 8000 to 9000 characters into the composer. Make sure that the text must be like: aaaaaaaaaaa...... upto 8000 characters then .comx, for example: aaaaaaaa....8000.comx

Note

Follow the following steps to copy the correct text to test:
1. Open Chrome DevTools and select the Console tab.
2. Run: copy('a'.repeat(8496) + '.comx')

4. Type several characters quickly at the end of the text.

5. Verify that:

   • The complete text remains plain text.
   • .comx is not converted into a link.
   • Typing remains smooth and responsive.

6. Repeat the test with: copy('a'.repeat(8496) + '.com') but make sure to add a space after .com at the end of the text.

7. Verify that the valid .com text becomes a link and that typing remains responsive after adding a space at the end.

Test 3: Dot-heavy invalid URL candidate

1. Open the App.
2. Open any chat.
3. Paste the text containing 8000 to 9000 characters into the composer and the text must be a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.... up to 8000 characters.

Note

Follow the following steps to copy the correct text to test:
1. Open Chrome DevTools and select the Console tab.
2. Run: copy('a.'.repeat(4499) + 'a')

4. Paste the text into the composer.

5. Type several characters quickly at the end.

6. Verify that:

   • The complete text remains plain text.
   • No part of the text becomes a link.
   • Typing remains responsive.

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Test 1

Android-native.mov

Test 3

Test-3-Android-native.mp4

Test 4

Test-4-Android-native.mov

Android: mWeb Chrome

Test 1:

android.mweb.mp4

Test 3:

Test-3-Android-mweb.mp4

Test 4:

Test-4-Android-mweb.mov

iOS: Native

Test 1:

ios-native.mp4

Test 3:

Test-3-iOS-native.mov

iOS: mWeb Safari

Test 1:

ios-safari.mp4

Test 3:

Test-3-iOS-mweb.mp4

Test 4:

Test-4-iOS-mweb.mov

MacOS: Chrome / Safari

Test 1:

macOS.web.mp4

Test 2:

Test-2-macOS.mp4

Test 3 (Part 1):

Test-3-macOS-part-1.mp4

Test 3 (Part 2):

Test-3-macOS-part-2.mp4

Test 4:

Test-4-macOS.mp4

[github-actions]

⚠️ This PR is possibly changing native code and/or updating libraries, it may cause problems with HybridApp. Please check if any patch updates are required in the HybridApp repo and run an AdHoc build to verify that HybridApp will not break. Ask Contributor Plus for help if you are not sure how to handle this. ⚠️

[codecov]

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines	Coverage Δ
src/libs/EmojiUtils.tsx	86.13% <100.00%> (ø)
src/libs/FormatSelectionUtils.ts	100.00% <100.00%> (ø)
src/libs/ParsingUtils.ts	89.74% <100.00%> (+7.69%)	⬆️
... and 15 files with indirect coverage changes

[Uzaifm127]

@linhvovan29546

There are couple of things I wanna mention:

1. There are 5 code locations which use parseExpensiMark in the App, though we only needed to pass the MAX_MARKUP_LENGTH limit only to src/libs/ParsingUtils.ts location to solve the issue which is mentioned in the OP but since we optimized the ExpensiMark parser so I believed we also needed to pass the new limit to these locations too:

   • src/libs/EmojiUtils.tsx (Part - 1)
   • src/libs/EmojiUtils.tsx (Part - 2)
   • src/libs/EmojiUtils.tsx (Part - 3)
   • src/libs/FormatSelectionUtils.ts

   I've also included the Tests in the PR description and attached videos to cover all of these. These other code locations are the other existing issues due to the limit which we are also solving automatically in this PR.

2. Do we need to update the Podfile.lock for this PR? I believe YES.

3. Do we need to update the Mobile-Expensify and need a PR in hybrid app for this PR?

4. While preparing and reviewing the changes of this PR, I also tested the ExpensiMark once again and I found that we missed two minor cases:

   • Autolinking stops after an unfinished HTML tag
     Here are the steps for repro:

     1. Run the App on Web
     2. Open Chrome DevTools > Network
     3. Open Workspaces
     4. Select a workspace
     5. Open Members
     6. Select Invite member
     7. Enter an email that is not already a workspace member
     8. Continue to Confirm details
     9. Replace the invitation message with before.com <unfinished after.com
     10. Clear the Network panel
     11. Click Invite
     12. Find the AddMembersToWorkspace request
     13. Open payload and check for welcomeNote

     Notice that after.com is not converted into an anchor but it was converted in the previous version of ExpensiMark parser.

     Repro video:

     Previous ExpensiMark version:

     autolink-case-old-expensimark.mov

     New optimized ExpensiMark version:

     autolink-case-new-expensimark.mp4

   • Bold and strikethrough formatting lose the surrounding HTML context
     Here are the steps for repro:
     Repeat the same step as Autolinking stops after an unfinished HTML tag, but replace the invitation message with *bold* > or ~strike~ >

     Repro video:

     Previous ExpensiMark version:

     bold-strikethrough-old-expensimark.mov

     New optimized ExpensiMark version:

     bold-strikethrough-case-new-expensimark.mp4

     Since these are the cases which have been found before the final PR, so we need to cover these cases too so that these won't be considered as regressions from the PRs we merged.

     Should we cover these cases in a follow up (Along with the Android typing delay issue which I pointed out here: ANDROID TYPING DELAY ISSUE, since we will be covering that Android native case in a follow up)

     OR

     Should we cover these cases right now before merging this PR?

[melvin-bot]

@linhvovan29546 Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[linhvovan29546]

Reviewer Checklist

• I have verified the author checklist is complete (all boxes are checked off).
• I verified the correct issue is linked in the ### Fixed Issues section above
• I verified testing steps are clear and they cover the changes made in this PR
  • I verified the steps for local testing are in the Tests section
  • I verified the steps for Staging and/or Production testing are in the QA steps section
  • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
• I checked that screenshots or videos are included for tests on all platforms
• I included screenshots or videos for tests on all platforms
• I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
• I verified tests pass on all platforms & I tested again on:
  • Android: HybridApp
  • Android: mWeb Chrome
  • iOS: HybridApp
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
• I verified proper code patterns were followed (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I verified that this PR follows the guidelines as stated in the Review Guidelines
• I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
• If a new component is created I verified that:
  • A similar component doesn't exist in the codebase
  • All props are defined accurately
  • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
  • The only data being stored in the state is data necessary for rendering and nothing else
  • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
• I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

Screen.Recording.2026-09-28.at.20.24.51.mov

Android: mWeb Chrome

Screen.Recording.2026-09-28.at.20.21.55.mov

iOS: HybridApp

Screen.Recording.2026-09-28.at.20.27.34.mov

iOS: mWeb Safari

Screen.Recording.2026-09-28.at.20.21.19.mov

MacOS: Chrome / Safari

Screen.Recording.2026-09-28.at.20.18.49.mov

[linhvovan29546]

Do we need to update the Podfile.lock for this PR? I believe YES.

I’m not sure. Since the change only updates the JS, and the Podfile.lock isn’t included in this PR.

Should we cover these cases right now before merging this PR?

Yes.

[Uzaifm127]

@linhvovan29546

I’m not sure. Since the change only updates the JS, and the Podfile.lock isn’t included in this PR.

When I built the iOS native app locally then the Podfile was updated locally, it might happen because the fingerprint was changed as the react-native-live-markdown version changes

Do we need to update the Mobile-Expensify and need a PR in hybrid app for this PR?

What about this?

ccing: @JS00001 for helping on the above

---

Should we cover these cases right now before merging this PR?

Yes

Sure, I'll raise a PR in expensify-common for the fix of the cases and then we can have a dependency upgrade for App in this PR and in react-native-live-markdown too.

[JS00001]

I DMd @roryabraham to ask, I'm not sure if mobile needs to be updated or not

[Uzaifm127]

Hi @JS00001 Did you get a response from Rory?

The fix of the missed cases mentioned here is in [WIP]

Edit: The draft PR is up

[JS00001]

@linhvovan29546 do you have access to mobile-expensify?

[linhvovan29546]

@linhvovan29546 do you have access to mobile-expensify?

Yes

[JS00001]

@linhvovan29546 can you please npm i && npm run pod-install, and if there is a diff in mobile-expensify, can you create a matching PR there?

[linhvovan29546]

@linhvovan29546 can you please npm i && npm run pod-install, and if there is a diff in mobile-expensify, can you create a matching PR there?

We have the diff, but I don’t think it’s related to the issue because the diff I see locally doesn’t involve expense-common or live markdown.

[JS00001]

Yeah I think these changes would be js only, so we may not need a mobile-e change

[Uzaifm127]

@JS00001 What about Podfile.lock changes? When I built the native iOS app locally then these podfile changes I got automatically:

---

I strongly believe to update the Podfile.lock but I'm first confirming because:

1. I saw a similar PR which bumped the react-native-live-markdown version and Vit asked to update the pod file in this comment.
2. react-native-live-markdown is also installed as the native iOS pod RNLiveMarkdown

cc: @linhvovan29546

[linhvovan29546]

@Uzaifm127 Ah, it looks like the Podfile is missing for the standalone build. Could you please include it as well?

[linhvovan29546]

@JS00001 The PR update Podfile in mobile-expensify here: https://github.com/Expensify/Mobile-Expensify/pull/14145

[Uzaifm127]

@linhvovan29546 Yes, doing...

[JS00001]

Nice, we'll need to merge this and the mobile-expensify PR together. so lmk when this is ready and I'll merge both

[Uzaifm127]

@linhvovan29546 Done with the Podfile.lock changes and updated the QA section of the PR. Thanks.

[JS00001]

merged both PRs, this and mobile-e

[github-actions]

🚧 JS00001 has triggered a test Expensify/App build. You can view the workflow run here.

[OSBotify]

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

[github-actions]

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #100421.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-20564be-93e558e-2477dfe1e59ddbb171d0c5474f5eebde3e4b4399/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-20564be-93e558e-c1b1f21978674fa9643516711575e4d267c432d6/index.html

Web 🕸️
https://100421.pr-testing.expensify.com

---

👀 View the workflow run that generated this build 👀

[OSBotify]

🚀 Deployed to staging by https://github.com/JS00001 in version: 9.4.95-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

[MelvinBot]

No help site changes are needed for this PR, so I didn't create a docs PR.

This PR fixes [$250] Chat - Live markdown in composer is removed if the text exceeds 4000 characters. It changes how the composer parses Markdown internally and raises the live-formatting limit from 4,000 to 10,000 characters. It doesn't add or rename any feature, setting, or button.

What I checked

• Changed files: All changes are in parsing and emoji code (ParsingUtils.ts, FormatSelectionUtils.ts, EmojiUtils.tsx), their tests, and a dependency bump. None of them change UI copy.
• Help site search: No article under docs/articles mentions a 4,000-character Markdown limit, composer lag, or the Cmd/Ctrl+B and Cmd/Ctrl+I formatting shortcuts.
• Closest article: Chat-Features-and-Moderation-Tools.md:31-43 lists the Markdown syntax you can use in chat. That syntax is the same after this PR, so the article is still accurate.

@Uzaifm127, no help site PR was needed, so there is nothing to review or mark Ready for review.

---

view run

[kavimuru]

@Uzaifm127 failing with original bug on native apps https://platform.applause.com/services/links/v1/external/e5a05cb29120ae74f0e09d0a0e88416749f965c2f75165c864b03fd34c6e9684
https://platform.applause.com/services/links/v1/external/ea7d1d482a356c2404c63a3070751b594875624ca5c2b2049b563d1182409243
https://platform.applause.com/services/links/v1/external/27d83bb5f452106a084afd9a76a0e0b37db5040f8025cca800a90291c910a540

[Uzaifm127]

@kavimuru I saw all three recordings.

These recordings are from Android native, and they don't reproduce the original issue where live Markdown formatting disappears after 4,000 characters.

• In the first recording, Markdown formatting remains preserved, but the separate known Android typing delay is visible. The Test 1 note explicitly says not to fail this PR because of that Android delay, as it will be handled in a follow-up.
• The second recording passes Test 3: the emoji and shortcode behavior inside and outside code ranges is correct.
• The third recording passes Test 4: suggestions do not appear inside the code range, but they appear outside it.

I didn't get how the PR is failing with original native bug?

TY!

cc: @linhvovan29546

[jponikarchuk]

Deploy Blocker #102487 was identified to be related to this PR.

[jponikarchuk]

This PR failing because of the issue #102487
This issue is reproducible in: All platforms

[IuliiaHerets]

Hi @Uzaifm127. QA team failed test 1 on Native apps with an original issue

1790639298969.14-and-test1.mp4

[Uzaifm127]

@IuliiaHerets Could you please confirm which step in Test 1 is failing? Thanks

6. Verify that the typing experience is smooth and it doesn't lag or freezes while typing.
7. Verify that the markdown is preserved when we type after pasting 4000+ characters text in the composer.

[kavimuru]

@Uzaifm127 https://applause.enterprise.slack.com/files/WC42FV8MT/F0C4U12LYQ7/14-and-test1.mp4
Copy pasted text does not preserve the markdown, user has to manually type for 40000+ characters.

[Uzaifm127]

@kavimuru I'm still not getting how the PR is failing with the original issue. I've tested on the adhoc build on a real device and I didn't get any issue:

PR-test-on-adhoc.mp4

---

I don't have access to the video you shared.

Is the QA team copying the text from another application or another application sent message?

cc: @linhvovan29546

[Julesssss]

I'm still not getting how the PR is failing with the original issue

in the meantime, checking it off as the original bug already I'm still not getting how the PR is failing with the original issue on production.

[OSBotify]

🚀 Deployed to production by https://github.com/Julesssss in version: 9.4.95-4 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	failure ❌
🍎 iOS 🍎	failure ❌