Expense - Description hint is not shown below Description field when it is a user mention

[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: 9.4.84-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: #101072
Email or phone of affected tester (no customers): jsdoijnodsdisojo@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Create a Control workspace.
• Enable Rules.

1. Go to staging.new.expensify.com
2. Go to workspace settings > Categories.
3. Open Advertising category.
4. Click Description.
5. Enter a user mention (eg, @sjoijsndosdnjoinj@gmail.com).
6. Save it.
7. Open FAB > Create expense > Manual.
8. Select Advertising category.

Expected Result:

User mention description hint will be shown below Description field.

Actual Result:

User mention description hint is not shown below Description field.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7262930_1789707939068.4.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @Ollyws

[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/fb1e3712a15e18475dcd277aa8befed6d79e0f55cb562bfca856da6271577b1b

[MelvinBot]

Proposal

What is the root cause of that problem?

The hint is parsed by ExpensiMark twice, and the mention rule is not idempotent, so the second parse nests the tag inside itself — and the mention renderer refuses to render a nested tag.

1. Saving the hint converts markdown → HTML once. DynamicCategoryDescriptionHintPage.tsx:74 calls getParsedComment, so @someone@gmail.com is stored in commentHint as <mention-user>@someone@gmail.com</mention-user>.

2. Displaying the hint passes that raw HTML to the input. DescriptionField.tsx:126-127 sets hint={descriptionHint} with shouldRenderHintAsHTML. The standalone description step does the same at DynamicIOURequestStepDescription.tsx:240-241.

3. The bug: FormHelpMessage.tsx:101 runs Parser.replace(message, {shouldEscapeText: false}) — the full markdown → HTML ruleset — on a string that is already HTML. ExpensiMark's userMentions rule re-fires on the email inside the existing tag, because its negative lookahead excludes </a>, </pre> and </code> but not </mention-user>. Result: <mention-user><mention-user>@someone@gmail.com</mention-user></mention-user>.

4. The outer tag now has an element child instead of a text child, so it becomes a TPhrasing node with no data. MentionUserRenderer.tsx:68-76 has no accountid and no data, falls through every branch, and hits return null. Nothing renders — you get empty space where the hint should be.

Plain-text hints work because Parser.replace is a no-op on them. Nothing throws, so there is no console error to notice.

The sibling shortMentions rule does guard against this (its lookahead lists </mention-user>|</mention-here>), which confirms the omission in userMentions is an oversight, not intentional.

Evidence for the non-idempotent regex

userMentions regex in expensify-common:

PRE_MENTION_TEXT_PART (@EMAIL_PART|@PHONE_PART) (?!((?:(?!<a).)+)?<\/a>|[^<]*(<\/pre>|<\/code>))

Running that exact pattern against real input with PCRE:

Input	Matches?
<mention-user>@someone@gmail.com</mention-user>	1 match — rule re-fires
<pre>@someone@gmail.com</pre>	0 matches — lookahead correctly blocks

Compare shortMentions, which explicitly guards the case:

... (?!((?:(?!<a).)+)?<\/a>|[^<]*(<\/pre>|<\/code>|<\/mention-user>|<\/mention-here>))

I verified the regex behavior directly, and traced the render path by reading the source. I was not able to execute the parser or drive the browser in this environment, so the nesting → TPhrasing → return null chain is from source reading rather than a runtime trace. The reporter's video already confirms the user-visible symptom.

Scope: this is not new, and it affects more than the confirmation screen

• Both hint call sites are broken, because they share FormHelpMessage. The confirmation screen (DescriptionField.tsx:56-58) and the standalone description step (DynamicIOURequestStepDescription.tsx:189) both read raw commentHint and pass it straight through with no transform. That matches the report saying this reproduces in production, since the standalone step predates Show the category description hint on the expense creation description field.
• A hint that is only a mention renders blank. A mixed hint like Ask @someone@gmail.com for details loses just the mention and keeps the surrounding words.
• CategorySettingsPage.tsx:337-346 shows the same hint correctly, because MenuItem distinguishes "already HTML" from "markdown" at MenuItem.tsx:677 and skips the re-parse. FormHelpMessage does not make that distinction.
• Likely the same bug with room mentions. FormHelpMessage passes no disabledRules, so reportMentions is enabled on the second parse even though getParsedComment disabled it on the first. I did not trace MentionReportRenderer, so treat this as unconfirmed.

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

Fix it once in the shared component: make FormHelpMessage stop re-parsing content that is already HTML.

In FormHelpMessage.tsx:96-108, skip the Parser.replace call when the message is already HTML — guard it with Parser.isHTML(message), mirroring what MenuItem already does at MenuItem.tsx:677, and wrap the value in <muted-text-label> (or <alert-text>) as it does today. Every other caller of shouldRenderMessageAsHTML passes markdown or translation strings, so they keep working unchanged.

Add a regression test with commentHint: '<mention-user>@someone@gmail.com</mention-user>'. The existing test at DescriptionField.test.tsx:35 only uses the plain-text hint 'Client name', and it mocks out TextInput, so it never exercises FormHelpMessage at all. The test needs to render the real input to catch this.

What alternative solutions did you explore? (Optional)

• Convert at both call sites: pass Parser.htmlToMarkdown(descriptionHint) as the hint in DescriptionField.tsx and DynamicIOURequestStepDescription.tsx, so the single parse in FormHelpMessage sees markdown as it expects. This works and matches how DescriptionField.tsx:62 already normalizes the description value, but it has to be applied twice and leaves the double-parse trap in place for the next caller.
• Fix userMentions upstream in expensify-common by adding </mention-user> (and </mention-here>) to its negative lookahead, matching shortMentions. This is the most correct fix and worth doing regardless, but it needs an upstream release plus a version bump, and it does not stop FormHelpMessage from double-parsing other rules.

Related issues

Both came out of QA on the same PR and touch the same hint feature, but neither is a duplicate of this one:

• [CFI] Description hint is not displayed in the description field. — open. The original "hint never shows during creation" bug that Show the category description hint on the expense creation description field fixed for plain text.
• Expense - Description hint is displayed for expenses created on Self DM. — open. Separate scoping bug: the hint shows where it should not, rather than failing to render.

---

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

---

view run · no recording available

[melvin-bot]

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

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[IuliiaHerets]

Issue still reproduced on Web, Android and iOS, build v9.4.84-1

dd059ce9-287a-4858-9489-fc9241c9d0a7.mp4

mobizen_20260918_132047.mp4

2026-09-18.13-14-15.mp4

[mountiny]

That makes sense, but we will follow up in v2