[$175] Compose Box - Maximum comment length error when a link is pasted in the composer

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: v9.4.95-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #100421
Email or phone of affected tester (no customers): agexptest+pr280926@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11/ Chrome, Samsung S23FE/ Android 16, iPhone 13 Mini/ iOS 26.5
App Component: Chat Report View

Action Performed:

1. Navigate to https://staging.new.expensify.com/
2. Go to any 1:1 chat
3. Open Chrome DevTools and select the Console tab
4. Run: copy('a'.repeat(8496) + '.com')
5. Paste the string in the composer

Expected Result:

The maximum comment length error message is not displayed.

Actual Result:

The maximum comment length error message is displayed, but the writing is still allowed.
The pasted message is 8,500 characters long.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7272030_1790636680146.composer_error_message.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7272030

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022104830733949161960
• Upwork Job ID: 2104830733949161960
• Last Price Increase: 2026-09-29

Issue Owner

Current Issue Owner: @linhvovan29546

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/1dfad893b0feb7d2629ca1f27f01fe7c0b49d24b419b4994a903b58eecf58042

[MelvinBot]

Proposal

What is the root cause of that problem?

The length check counts the message's HTML, not the characters you see. ExpensiMark turns the pasted string into a link, so the text appears twice in the HTML (<a href="https://aaa…com" …>aaa…com</a>). The 8,500 visible characters become 17,065 HTML characters, which is over the 15,000 limit.

• getCommentLength measures the parsed HTML on purpose, so the App matches how the backend counts AddComment length.
• The real bug is in expensify-common. URL_WEBSITE_REGEX accepts hostname labels of any length ([-a-z0-9]*). DNS allows at most 63 characters per label, so aaa…(8,496)….com is not a real domain and should never become a link.

Typing still works because the input's hard cap counts raw characters (MAX_COMMENT_LENGTH + 1). The HTML check only blocks sending.

This is not a regression from fix: preserve Markdown formatting in long messages. expensify-common 2.0.204, the version before that PR, gives the same 17,065-character output.

What changes do you think we should make in order to solve the problem?

Change expensify-common, then bump it in App:

1. In URL_WEBSITE_REGEX, limit each hostname label to 63 characters ([-a-z0-9]{0,61} in place of [-a-z0-9]*).
2. Add a lookbehind so a match can't start in the middle of a label ((?<![-a-z0-9.])). Without it, the regex links just the last 63 characters of the string.
3. Apply the same 63-character rule in the new candidate scanner (isValidHostnameLabel / findHostnameStart in ExpensiMark.ts) so both paths agree.
4. Add unit tests: a 63-character label links, a 64-character label does not, and common URLs still link.

With these changes, the pasted string stays plain text and counts as 8,500 characters, so no error appears.

What alternative solutions did you explore? (Optional)

• Count raw characters in App. This breaks parity with the backend. The HTML count was added on purpose to stop AddComment from failing.
• Override the autolink rule in App's Parser.ts. This is a workaround, and the composer's live Markdown highlighting would still show the link.

Investigation details

The researcher ran the real getCommentLength in a Jest test on App 68ad1ed:

Input	getCommentLength
'a'.repeat(8496) + '.com'	17,065 (over 15,000)
'a'.repeat(8500)	8,500
Same output from expensify-common 2.0.204 and 2.0.207	Yes

• The link adds 65 characters plus a second copy of the URL: HTML length = 2 × length + 65. Any bare "domain" of 7,468 or more characters triggers the error.
• Text over MAX_MARKUP_LENGTH (10,000) is not parsed (ReportUtils.ts:6933). So the same string at 10,001 or more characters does not show the error.
• The composer blocks sending when the limit is exceeded (useDebouncedCommentMaxLengthValidation.ts:38).
• We tested the 63-character cap plus lookbehind by overriding the regex in Jest. The 8,500-character string was not linked. google.com, https://www.expensify.com/path?x=1, sub.domain.example.co.uk, test@expensify.com, and _expensify.com_ still behaved as before.
• A live web reproduction didn't finish because the test session's page went blank. The Jest run above calls the same code the composer uses.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/102500) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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

[bonnhatnguyen]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When pasting an 8,500-character string formatted like a pseudo-domain (e.g. 'a'.repeat(8496) + '.com') into the composer, the "Maximum comment length exceeded" error message is prematurely displayed even though the raw text is well within the 10,000 character limit.

What is the root cause of that problem?

1. In src/libs/ReportUtils.ts:10798-10802, getCommentLength computes comment length on the parsed HTML output via ExpensiMark (rather than raw plaintext characters) to ensure parity with the backend auth validator for AddComment:

   function getCommentLength(textComment: string, parsingDetails?: ParsingDetails): number {
       return getParsedComment(textComment, parsingDetails)
           .replaceAll(/[^ -~]/g, '\u????')
           .trim().length;
   }

2. When the user pastes 'a'.repeat(8496) + '.com', ExpensiMark in expensify-common applies URL_WEBSITE_REGEX ([-a-z0-9]*\.[a-z]{2,}).
3. Under RFC 1035 and DNS specifications, a valid domain label cannot exceed 63 characters. However, the current regex in expensify-common allows unlimited characters in the label ([-a-z0-9]*).
4. Because the 8,496-character string is incorrectly recognized as a URL, ExpensiMark autolinks it, duplicating the string in both href and inner text:
   <a href="https://aaaa...com" target="_blank" rel="noreferrer noopener">aaaa...com</a>
5. This balloons the 8,500 visible characters into 17,065 HTML characters, which exceeds the backend and client limit (15,000 HTML characters / CONST.MAX_COMMENT_LENGTH), triggering useDebouncedCommentMaxLengthValidation.ts:38-41 to flag a maximum length violation.

What changes do you think we should make in order to solve the problem?

1. Enforce RFC 1035 63-Character Label Limit in expensify-common (and ExpensiMark.ts):
   • Update URL_WEBSITE_REGEX in expensify-common/lib/Url.js (and src/libs/ExpensiMark.ts) to restrict domain label length to a maximum of 63 characters:
     Replace [-a-z0-9]* with [-a-z0-9]{1,63} and include boundary checks:

     const URL_WEBSITE_REGEX = /(?<![-a-z0-9.])(?:[a-z0-9](?:[-a-z0-9]{0,61}[a-z0-9])?\.)+[a-z]{2,}/gi;

   • In ExpensiMark.ts, enforce label.length <= 63 in hostname label validation (isValidHostnameLabel).
2. Result:
   • Any string with an unsegmented label exceeding 63 characters (such as a.repeat(8496) + '.com') will not be treated as a website link.
   • It remains plain text of 8,500 characters, well within the limit, preventing the false "maximum comment length exceeded" error.
3. Add Unit Tests in tests/unit/ExpensiMarkTest.ts:
   • Verify that domain labels <= 63 characters are correctly autolinked.
   • Verify that domain labels > 63 characters remain plain text and do not inflate HTML length.

What alternative solutions did you explore? (Optional)

• Calculating comment length purely on raw text in the client: Explored and rejected because if a message containing legitimate Markdown/links exceeds the backend 15,000 HTML limit, the server would reject the AddComment command with an error. Enforcing the RFC 63-character hostname standard in ExpensiMark fixes the root autolinking defect while maintaining full client-backend length parity.

Contributor details
Your Expensify account email: bonnhatnguyen0@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~0139ed4098bdc50182

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[Uzaifm127]

@JS00001

Can me and @linhvovan29546 work on this issue? Because

This issue was found during QA for our PR: #100421, and I already faced this issue locally while solving the long .comx and heavy dotted URL case for ExpensiMark follow up PR: Expensify/expensify-common#945. Since it isn't a regression introduced by our PR, solving this issue also includes updating the candidate scanning logic introduced by our ExpensiMark performance PR: Expensify/expensify-common#937

Since we already have the full context and idea for these parser changes, happy to be assigned. Thank you!

[JS00001]

Works for me