[$250] Chat - the mention for short email isn't recognized

[lanitochka17]

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: undefined
Reproducible in staging?: Yes
Reproducible in production?: https://github.com/Expensify/Expensify/issues/557782
If this was caught during regression testing, add the test name, ID and link from BrowserStack: undefined
Email or phone of affected tester (no customers): undefined
Issue reported by: Applause Internal Team
Bug source: undefined
Device used: undefined
App Component: undefined

Action Performed:

1. Open the WS chat chat
2. Send a short mention with a single character followed by dot (for example, @j.doe)

Expected Result:

the mention is recognized

Actual Result:

the mention isn't recognized

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7194499_1782748877348.1781581665683_short_mention.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022077846901647779339
• Upwork Job ID: 2077846901647779339
• Last Price Increase: 2026-08-13

[MelvinBot]

Issue Analysis

Root Cause: This is a client-side (App) bug in the composer's mention-suggestion detection. When the typed prefix was a short mention ending in a dot (e.g. @j. on the way to typing @j.doe), the raw dotted prefix j. was passed straight into the suggestion substring filter (SuggestionMention.tsx displayText.toLowerCase().includes(searchValue…)). A user whose login is j.doe@company.com has display text like John Doe j.doe@company.com, and since that never contains the trailing-dot fragment j., zero candidates matched and no suggestion appeared — the mention "wasn't recognized". The trigger regex is not the culprit (HAS_AT_MOST_TWO_AT_SIGNS only counts @ signs and never rejects a dot).

This appears to already be fixed on main. The current code strips a trailing dot into a normalizedPrefix before filtering (while keeping the dotted prefix for the UI highlight) at SuggestionMention.tsx:506-508, with matching insertion handling at lines 258-265. The exact reported scenario is covered by a passing unit test — SuggestionMentionTest.tsx:203-222 types @a. against login a.smith@example.com and asserts the suggestion resolves to @a.smith@example.com.

Recommended next step: Re-verify on the latest staging build. This bug report lists Version Number: undefined, so it was very likely captured on a build predating the trailing-dot fix. If it still reproduces on a build that includes the code above, please reopen with the exact build/version and note whether the mentioned person is actually a known contact of the tester (unknown users are intentionally not suggested).

Investigation details

Data flow (typing @j.doe):

• calculateMentionSuggestion splits the composer text on whitespace/emoji only (dots don't split), so @j.doe is one token → prefix = "j.doe", prefixType = "@".
• Trailing-dot check (line 507) uses TRAILING_DOTS: /\.$/ with a prefix.length > 1 guard, so @. alone isn't special-cased.
• getUserMentionOptions(normalizedPrefix) is called at line 520; it filters known personal details by substring match on displayName + login.

Alternative explanations considered:

• Trigger regex rejecting the dot — ruled out; [^@]* matches dots, so @j.doe/@jdoe/@john.doe all pass equally.
• Tokenizer breaking on the dot — ruled out; . is not in the word split or the mention breaker.
• Mid-string dot (@j.doe) failing on latest — would only fail to suggest if no known contact's display text contains the literal typed substring, which is expected behavior, not a defect.

Scope: Purely client-side in the App repo (composer suggestion component); no backend involvement.

---

Next Steps for Contributor+ team:
This looks resolved on main — recommend QA re-verification on the latest staging build before assigning implementation work. If it still reproduces on a current build, reply with @MelvinBot <details> (exact version + whether the contact is known) to refine.

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-16 20:18:20 UTC.

Proposal

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

In a workspace chat, sending a short mention whose login local part starts with a single character followed by a dot (e.g. @j.doe) is not recognized: it stays as plain text instead of being highlighted/linked as a mention of the workspace member j.doe@<workspace-domain>.

What is the root cause of that problem?

It is not the ExpensiMark regex. In the currently shipped expensify-common@2.0.191, Parser.replace('@j.doe') already produces <mention-short>@j.doe</mention-short> (the single-character-first case fixed in #69685 / PR #70848 still works). The failure is in how the App resolves that <mention-short> tag, which is keyed off the current user's own email domain instead of the chat's membership.

There are two resolution paths and both are domain-gated:

1. Send-time conversion. getParsedMessageWithShortMentions turns <mention-short> into <mention-user> only via addDomainToShortMention, which appends userPrivateDomain and looks the result up in availableMentionLogins:
   

   App/src/libs/ParsingUtils.ts

   Lines 72 to 86 in 3e254e2

   	function addDomainToShortMention(mention: string, availableMentionLogins: string[], userPrivateDomain?: string): string | undefined {
   	if (!Str.isValidEmail(mention) && userPrivateDomain) {
   	const mentionWithEmailDomain = `${mention}@${userPrivateDomain}`;
   	if (availableMentionLogins.includes(mentionWithEmailDomain)) {
   	return mentionWithEmailDomain;
   	}
   	}
   	if (Str.isValidE164Phone(mention)) {
   	const mentionWithSmsDomain = addSMSDomainIfPhoneNumber(mention);
   	if (availableMentionLogins.includes(mentionWithSmsDomain)) {
   	return mentionWithSmsDomain;
   	}
   	}
   	return undefined;
   	}

   
   The callers set that domain to '' whenever the current user is on a public domain:
   

   App/src/libs/ReportUtils.ts

   Lines 6273 to 6285 in 3e254e2

   	if (policy?.type) {
   	isGroupPolicyReport = isGroupPolicyPolicyUtils(policy);
   	}
   	}
   	const rules = disabledRules ?? [];
   	if (text.length > CONST.MAX_MARKUP_LENGTH) {
   	return lodashEscape(text);
   	}
   	let userEmailDomain = deprecatedCurrentUserPrivateDomain;
   	if (currentUserEmailParam !== undefined) {

   
   

   App/src/libs/actions/Report/index.ts

   Lines 3265 to 3272 in 3e254e2

   	*/
   	function removeLinksFromHtml(html: string, links: string[]): string {
   	let htmlCopy = html.slice();
   	for (const link of links) {
   	// We want to match the anchor tag of the link and replace the whole anchor tag with the text of the anchor tag
   	const regex = new RegExp(`<(a)[^><]*href\\s*=\\s*(['"])(${Str.escapeForRegExp(link)})\\2(?:".*?"|'.*?'|[^'"><])*>([\\s\\S]*?)<\\/\\1>(?![^<]*(<\\/pre>|<\\/code>))`, 'g');
   	htmlCopy = htmlCopy.replace(regex, '$4');
   	}

   
   With userPrivateDomain === '', the if (!Str.isValidEmail(mention) && userPrivateDomain) branch is skipped, addDomainToShortMention returns undefined, and @j.doe is sent as raw text.

2. Live-composer highlighting and rendered-message styling both read useShortMentionsList, which returns [] for a public-domain current user and otherwise only keeps members whose domain equals the current user's private domain:
   

   App/src/hooks/useShortMentionsList.ts

   Lines 24 to 45 in 3e254e2

   	const currentUserDomain = getEmailDomain(currentUserPersonalDetails.login ?? '');
   	if (isDomainPublic(currentUserDomain)) {
   	return [];
   	}
   	return Object.values(personalDetails)
   	.map((personalDetail) => {
   	if (!personalDetail?.login) {
   	return;
   	}
   	const personalDetailDomain = getEmailDomain(personalDetail.login);
   	const isPersonalDetailPublicDomain = isDomainPublic(personalDetailDomain);
   	// If the emails are not in the same private domain, we don't want to highlight them
   	if (isPersonalDetailPublicDomain || personalDetailDomain !== currentUserDomain) {
   	return;
   	}
   	const [username] = personalDetail.login.split('@');
   	return username;
   	})

So a member on a public-domain account (a typical personal/test login, as in the video) — or on any domain different from the mentioned user — can never form a short mention like @j.doe, even when j.doe@<workspace-domain> is an actual participant of that chat. @j.doe is simply the smallest login that reproduces this, which is why it looks like the old single-character-dot bug.

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

Resolve short mentions against the participants of the current chat (membership), by local part, independent of the current user's domain.

Send path — in addDomainToShortMention (src/libs/ParsingUtils.ts), after the existing current-user-domain lookup fails, fall back to a chat participant whose login local part matches the short mention, accepting it only when it is unambiguous:

// existing: current user's private-domain match kept as-is
// new fallback: match against a chat participant's login local part
const localPartMatches = availableMentionLogins.filter((login) => login.split('@').at(0) === mention);
if (localPartMatches.length === 1) {
    return localPartMatches.at(0);
}

Since availableMentionLogins is already the resolution set passed in from ReportUtils/Report, this makes @j.doe resolve to j.doe@<workspace-domain> for public- and cross-domain users, while the single-match guard prevents picking the wrong person when a local part exists on two domains.

Highlighting/rendering path — apply the same membership-based idea to useShortMentionsList: instead of dropping every member when the current user is public-domain, and instead of keeping only members whose domain matches the current user, build the username set from the known members' logins and keep only usernames that map to a single login (so highlighting matches exactly what the send path will convert). Scoping this list to the open report's participants is the precise long-term shape; keeping it global but unambiguous is the minimal change.

This keeps the composer highlight, the sent-message rendering (ShortMentionRenderer), and the send-time HTML all consistent, and leaves the existing same-domain behavior untouched.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

• Unit test on getParsedMessageWithShortMentions: current user on a public domain, j.doe@companyX.com present in availableMentionLogins → @j.doe becomes <mention-user>@j.doe@companyX.com</mention-user> (also cover @a.b).
• Ambiguity guard: j.doe@a.com and j.doe@b.com both present → @j.doe is left unconverted (no wrong-user match).
• useShortMentionsList returns the member username for a public-domain current user when that member is known, and rendered @j.doe is styled as a mention.
• Regression: Parser.replace('@j.doe') still yields <mention-short>@j.doe</mention-short> so the ExpensiMark layer is not silently relied upon.

What alternative solutions did you explore? (Optional)

• Widening the ExpensiMark / mention regex (as some proposals suggest): unnecessary here — expensify-common@2.0.191 already emits <mention-short>@j.doe</mention-short>, so the regex is not the failing layer.
• Only special-casing public-domain users inside useShortMentionsList for workspace chats: this still misses cross-domain members (private-domain user mentioning a member on a different private domain) and the hook currently has no report context, so membership-based resolution is the more complete fix.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

The regex used to detect mentions in the composer doesn't account for email-style usernames where the local part starts with a very short segment (single character) followed by a dot, like j.doe. The mention pattern likely requires at least 2 characters before a dot or doesn't handle the <char>.<word> pattern correctly, causing @j.doe to not be recognized as a valid mention trigger.

The relevant regex is likely in src/libs/ExpensiMark.ts or a similar mention-parsing utility.

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

I'd look at the mention regex pattern that validates what comes after @. The fix is to ensure the pattern allows a single character before a dot in email-like mentions.

For example, if the current pattern for the mention local-part is something like:

- /(?<=[^a-zA-Z\d]|^)@([a-zA-Z\d]{2,}(?:\.[a-zA-Z\d]+)*)/
+ /(?<=[^a-zA-Z\d]|^)@([a-zA-Z\d]{1,}(?:\.[a-zA-Z\d]+)*)/

Or if the autocomplete trigger regex in the mentions suggestion logic (likely in src/components/Composer/ or src/libs/SuggestionUtils.ts) uses a minimum-length guard before a dot:

- const mentionRegex = /@([a-zA-Z0-9]{2,})/;
+ const mentionRegex = /@([a-zA-Z0-9]{1,})/;

This ensures single-character prefixes like j in @j.doe are still captured as part of the mention token.

What alternative solutions did you explore?

I considered adding a special-case branch for email-style mentions (containing a dot), but changing the minimum match length from {2,} to {1,} is simpler and correctly covers the root cause without complicating the regex logic.

[aswin-s]

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

On Web, when a user types a short mention consisting of a single character followed by a dot and more characters (e.g. @j.doe) in a workspace chat, the mention is not recognized/highlighted, so it is not converted into a <mention-user> tag when the message is sent. Expected: @j.doe should be recognized as a short mention for the workspace user whose login is j.doe@<workspace-domain>, matching the behavior of longer short mentions like @john.doe.

What is the root cause of that problem?

There are two failure points in the pipeline:

Failure 1 — send-time conversion (addDomainToShortMention):
src/libs/ParsingUtils.ts:72-86 — addDomainToShortMention has the guard:

if (!Str.isValidEmail(mention) && userPrivateDomain) {

When the currently-signed-in user's account is on a public email domain (e.g. gmail.com), getParsedComment in Report/index.ts sets userEmailDomain to '' (empty string) because isEmailPublicDomain returns true. This empty string is passed as userPrivateDomain to addDomainToShortMention. Since '' is falsy, the entire domain-appending branch is skipped, so @j.doe is never resolved to j.doe@<workspace-domain> even though j.doe@<workspace-domain> is present in availableMentionLogins (which is populated from allPersonalDetailLogins — full emails). The mention is silently dropped and no <mention-user> tag is emitted.

Failure 2 — live-composer highlighting (useShortMentionsList):
src/hooks/useShortMentionsList.ts:24-27 early-returns [] when currentUserDomain is a public domain. For workspace chats, the members share a private workspace domain, so this guard incorrectly prevents the composer from surfacing short-mention candidates when the signed-in reporter uses a public-domain personal account. The repro is explicitly in "WS chat", confirming this path is hit.

Both failures are independent: Failure 1 means the sent message lacks <mention-user> tags; Failure 2 means the @j.doe text is not highlighted in the composer at all while typing.

The upstream ExpensiMark shortMentions regex in node_modules/expensify-common/dist/ExpensiMark.js:429 does correctly produce <mention-short>@j.doe</mention-short> for the input — it consumes j with [\w]+, matches an empty [\w'#%+-]*, and then matches .doe with (?:\.[\w'#%+-]+)*. The bug is entirely downstream of that emission.

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

1. src/libs/ParsingUtils.ts:72-86 — fix addDomainToShortMention for public-domain callers

When userPrivateDomain is empty or absent, fall back to scanning availableMentionLogins directly for any entry whose local-part matches the short mention. This covers the case where the caller cannot supply a domain (public-domain user) but the workspace member's full email is still in the login list:

function addDomainToShortMention(mention: string, availableMentionLogins: string[], userPrivateDomain?: string): string | undefined {
    if (!Str.isValidEmail(mention)) {
        if (userPrivateDomain) {
            const mentionWithEmailDomain = `${mention}@${userPrivateDomain}`;
            if (availableMentionLogins.includes(mentionWithEmailDomain)) {
                return mentionWithEmailDomain;
            }
        }
        // Fallback: when userPrivateDomain is unavailable (public-domain caller),
        // find any login in the list whose local-part matches the mention.
        const matchedLogin = availableMentionLogins.find(
            (login) => Str.extractEmailDomain(login) !== '' && login.startsWith(`${mention}@`),
        );
        if (matchedLogin) {
            return matchedLogin;
        }
    }
    if (Str.isValidE164Phone(mention)) {
        const mentionWithSmsDomain = addSMSDomainIfPhoneNumber(mention);
        if (availableMentionLogins.includes(mentionWithSmsDomain)) {
            return mentionWithSmsDomain;
        }
    }
    return undefined;
}

This closes the send-time gap: j.doe will now match j.doe@acme.com in allPersonalDetailLogins even when the reporter's own domain is public.

2. src/hooks/useShortMentionsList.ts:24-27 — do not suppress workspace short mentions for public-domain users

The current guard returns [] whenever currentUserDomain is a public domain. Workspace chats involve members whose logins share a private workspace domain; the reporter's own domain is irrelevant to whether short mentions should be surfaced. Scope the guard to non-workspace personal chats:

// Before
if (!currentUserDomain || isEmailPublicDomain(currentUserDomain)) {
    return [];
}

// After
const isWorkspaceChat = !!report?.policyID;
if (!isWorkspaceChat && (!currentUserDomain || isEmailPublicDomain(currentUserDomain))) {
    return [];
}

This closes the composer-highlighting gap for the "WS chat" repro scenario.

3. tests/unit/ParsingUtilsTest.ts — add unit tests for single-character-prefix short mentions

Add tests (create the file if it does not already exist) covering:

• @j.doe recognized when userPrivateDomain is set
• @j.doe recognized when userPrivateDomain is '' but j.doe@acme.com is in availableMentionLogins (the public-domain fallback path)
• @a.b and @x.y.z recognized through getParsedMessageWithShortMentions
• decorateRangesWithShortMentions produces the correct mention range for @j.doe

4. Verify ExpensiMark regex output

Confirm that node_modules/expensify-common/dist/ExpensiMark.js at the installed version emits <mention-short>@j.doe</mention-short> for input @j.doe. Based on the regex analysis above this is expected to pass without a version bump, but if a regression is found in the installed version of expensify-common, coordinate a bump separately.

What alternative solutions did you explore? (Optional)

An alternative would be to always pass the workspace's policy domain instead of the current user's personal domain as userPrivateDomain. This would work for the send-time path but requires threading policy information into getParsedComment, which currently only has access to the report object — and not all reports have an unambiguous single workspace domain. The targeted fallback scan in addDomainToShortMention is narrower and requires no call-site changes.

[samranahm]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[melvin-bot]

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

[melvin-bot]

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

[github-actions]

⚠️ @samranahm Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.