[Due for payment 2026-05-11] [$250] Split expense - Split details page shows description in HTML tags

[jponikarchuk]

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.3.55-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: https://test-management.browserstack.com/projects/2219752/test-runs/TR-17112/folder/13176944/41237730/1316999876?sort=-identifier
Email or phone of affected tester (no customers): sdjonisjosjniosjdos@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Open 1:1 DM with any user.
3. Click + > Split expense > Manual.
4. Enter amount > Next.
5. Click Description.
6. Enter google.com and save it.
7. Click Split.
8. Open the split preview.

Expected Result:

Split details page will not show description in HTML tags.

Actual Result:

Split details page shows description in HTML tags.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022042282125410823843
• Upwork Job ID: 2042282125410823843
• Last Price Increase: 2026-04-23
• Automatic offers:
• wildan-m | Contributor | 111223874

[MelvinBot]

Proposal

What is the root cause of that problem?

When a split expense is created with a URL in the description (e.g. google.com), getParsedComment() converts it to HTML (<a href="https://google.com">google.com</a>) and stores it in transaction.comment.comment.

When the split details page renders, MoneyRequestConfirmationListFooter.tsx:814 passes shouldParseTitle to MenuItemWithTopDescription. This causes MenuItem.tsx to call Parser.replace() again on the already-HTML string, which HTML-escapes the <a> tags — so the user sees raw <a href="...">google.com</a> text instead of a rendered link.

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

In MoneyRequestConfirmationListFooter.tsx around line 814, replace shouldParseTitle with shouldRenderAsHTML on the read-only description MenuItemWithTopDescription. This is consistent with how MoneyRequestView.tsx (line 965) already correctly renders the same transaction description using shouldRenderAsHTML.

What alternative solutions did you explore? (Optional)

An alternative would be to strip HTML from the stored comment before passing it to shouldParseTitle, but that would lose formatting. Using shouldRenderAsHTML is the correct approach since the comment is already stored as HTML — this matches the pattern used elsewhere in the codebase.

Related issues

• Expense - In self DM, description with url is shown as text in preview #82301 — Similar issue with description URLs shown as text in self-DM expense preview (may share the same double-parsing root cause)

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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

[twilight2294]

Proposal

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

When a split expense has a URL in its description, the split details page displays raw HTML tags instead of rendering the link properly.

What is the root cause of that problem?

In SplitBillDetailsPage, the comment is wrapped in Parser.htmlToMarkdown() before being passed as iouComment:

iouComment={Parser.htmlToMarkdown(splitComment ?? '')}

This converts stored HTML (e.g. <a href="https://google.com">google.com</a>) into Markdown ([google.com](https://google.com)). Downstream, shouldParseTitle in MenuItem calls Parser.replace() on this Markdown, causing a double-conversion that produces garbled HTML output.

No other money request page does this conversion. For example, IOURequestStepConfirmation passes the raw comment directly and renders correctly.

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

In SplitBillDetailsPage, remove the Parser.htmlToMarkdown() wrapper:

- iouComment={Parser.htmlToMarkdown(splitComment ?? '')}
+ iouComment={splitComment ?? ''}

This lets the existing shouldParseTitle → Parser.replace() → RenderHTML pipeline in MenuItem handle the comment correctly, matching every other money request flow.

What alternative solutions did you explore? (Optional)

MelvinBot's proposal fixes this downstream by changing shouldParseTitle to shouldRenderAsHTML in MoneyRequestConfirmationListFooter. That works around the symptom but leaves the unnecessary htmlToMarkdown() conversion in place — a conversion no other page performs. Fixing at the source in SplitBillDetailsPage is a single-line change that eliminates the root mismatch rather than compensating for it downstream, and keeps the split details page consistent with IOURequestStepConfirmation and other money request flows.

[Tony-MK]

Proposal: Standardizing Description Normalization in Money Request Flows

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

On certain confirmation screens—specifically after editing a split or viewing a saved transaction—the description field fails to render links correctly. Instead, it displays raw HTML tags like <a href="https://google.com">google.com</a> instead of a clickable link. This occurs because the UI is treating raw HTML as Markdown, causing the parser to escape the tags rather than rendering them.

What is the root cause of that problem?

The issue is a normalization gap in the data pipeline introduced during the refactoring in commit 3d0e61b.

Data State: Descriptions for saved transactions (like completed splits) are stored in Onyx as HTML.

The Regression: The refactor removed the responsibility for converting this HTML back to Markdown (Parser.htmlToMarkdown) from several parent "Step" components.

The Conflict: Currently, IOURequestStepConfirmation.tsx passes the raw comment directly to MoneyRequestConfirmationList. Inside the footer, the shouldParseTitle={true} flag is set. When the Markdown parser receives a string that is already HTML, it treats the < and > characters as literal text to be escaped, resulting in the visible raw tags (<a href...>).

While SplitBillDetailsPage.tsx was correctly updated to handle this, IOURequestStepConfirmation.tsx was overlooked, leading to inconsistent rendering.

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

We should restore normalization at the Step Confirmation level. This ensures the data contract is satisfied before it reaches the view layer, preventing the shared list component from having to guess the input format.

1. Update src/pages/iou/request/step/IOURequestStepConfirmation.tsx

Add Parser import and normalize the transaction comment:

File: src/pages/iou/request/step/IOURequestStepConfirmation.tsx

Change 1 - Add import (after line 120):

import Parser from '@libs/Parser';

Change 2 - Update iouComment prop (line 1599):

  <MoneyRequestConfirmationList
      transaction={transaction}
      selectedParticipants={participants}
      iouAmount={transaction?.amount ?? 0}
      iouAttendees={getAttendees(transaction, currentUserPersonalDetails)}
-     iouComment={transaction?.comment?.comment ?? ''}
+     iouComment={Parser.htmlToMarkdown(transaction?.comment?.comment ?? '')}
      iouCurrencyCode={transaction?.currency}
      iouIsBillable={transaction?.billable}
      ...

2. Update src/pages/Share/SubmitDetailsPage.tsx

Add Parser import and normalize the trimmed comment:

File: src/pages/Share/SubmitDetailsPage.tsx

Change 1 - Add import (after line 42):

import Parser from '@libs/Parser';

Change 2 - Update comment derivation and iouComment prop (lines 128 and 296):

- const trimmedComment = transaction?.comment?.comment?.trim() ?? '';
+ const trimmedComment = Parser.htmlToMarkdown(transaction?.comment?.comment?.trim() ?? '');

  ...

  <MoneyRequestConfirmationList
      ...
-     iouComment={trimmedComment}
+     iouComment={trimmedComment}
      ...
  />

(Note: The prop itself doesn't change since trimmedComment is already normalized above)

3. Documentation in src/components/MoneyRequestConfirmationListFooter.tsx

Update the JSDoc comment for the iouComment prop to clarify the expected format (line 106-107):

File: src/components/MoneyRequestConfirmationListFooter.tsx

-    /** The comment of the IOU */
+    /**
+     * The comment of the IOU
+     * @note Expected to be normalized Markdown, not raw HTML.
+     * HTML should be converted via Parser.htmlToMarkdown() before passing to this component.
+     * This prevents double-parsing and ensures consistent link rendering via shouldParseTitle.
+     */
     iouComment: string | undefined;

What alternative solutions did you explore? (Optional)

Centralized fix in MoneyRequestConfirmationList.tsx: While this would solve the issue globally, it risks "double-parsing" or side effects for components that are already passing clean Markdown (like fresh drafts). Fixing at the "Step" level ensures we only transform data known to be coming from the database (HTML).

Switching to shouldRenderAsHTML: We rejected this because the TextInput in the footer is explicitly typed for Markdown. If we only changed the display logic but not the input logic, the user would still see raw HTML tags the moment they tried to edit the description, creating a fragmented UX.

---

Reference Implementation

Current Correct Pattern (SplitBillDetailsPage.tsx, line 155):

iouComment={Parser.htmlToMarkdown(splitComment ?? '')}

Current Broken Pattern (IOURequestStepConfirmation.tsx, line 1599):

iouComment={transaction?.comment?.comment ?? ''}

This proposal aligns all callers with the proven working pattern used in SplitBillDetailsPage.tsx.

---

Testing Considerations

1. Split Expense Edit Flow: Verify that after editing a split expense description with links, the confirmation screen displays the links correctly (not as raw HTML).
2. Transaction Creation with Comment: Test creating new money requests with descriptions containing mentions or links.
3. Fresh Drafts vs Saved Transactions: Ensure fresh drafts (already clean Markdown) still render correctly with the additional htmlToMarkdown call (should be idempotent).
4. Description Editing: Verify users can edit descriptions on the description step and see changes reflected correctly.

[wildan-m]

Proposal

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

On the Split details page for a completed split expense whose description contains a URL (e.g. google.com), the description field shows raw HTML text like <a href="https://google.com" target="_blank" rel="noreferrer noopener">google.com</a> instead of rendering a clickable link.

What is the root cause of that problem?

The description field of a saved transaction is stored as HTML. When a user types google.com into a split description, getParsedComment() runs ExpensiMark at save time and persists <a href="https://google.com">google.com</a> into transaction.comment.comment.

MoneyRequestConfirmationList.tsx derives the description it passes to its footer from that stored field:

App/src/components/MoneyRequestConfirmationList.tsx

Lines 293 to 294 in 69a3bdc

	const iouAmount = hasValidModifiedAmount(transaction) ? Number(transaction?.modifiedAmount) : (transaction?.amount ?? 0);
	const iouComment = getDescription(transaction);

getDescription(transaction) simply returns transaction.comment.comment.toString(), so when the page is a Split details page viewing a saved transaction, iouComment is the raw HTML string.

That value is then handed to MoneyRequestConfirmationListFooter.tsx, which renders it in a MenuItemWithTopDescription with the shouldParseTitle flag:

App/src/components/MoneyRequestConfirmationListFooter.tsx

Lines 812 to 834 in 69a3bdc

	<MenuItemWithTopDescription
	shouldShowRightIcon={!isReadOnly}
	shouldParseTitle
	excludedMarkdownRules={!policy ? ['reportMentions'] : []}
	title={iouComment}
	description={translate('common.description')}
	onPress={() => {
	if (!transactionID) {
	return;
	}
	Navigation.navigate(
	ROUTES.MONEY_REQUEST_STEP_DESCRIPTION.getRoute(action, iouType, transactionID, reportID, Navigation.getActiveRoute(), reportActionID),
	);
	}}
	style={[styles.moneyRequestMenuItem]}
	titleStyle={styles.flex1}
	disabled={didConfirm}
	interactive={!isReadOnly}
	numberOfLinesTitle={2}
	rightLabel={isDescriptionRequired ? translate('common.required') : ''}
	sentryLabel={CONST.SENTRY_LABEL.REQUEST_CONFIRMATION_LIST.DESCRIPTION_FIELD}
	/>

shouldParseTitle makes MenuItem run Parser.replace(title, ...) on the value, which is ExpensiMark's markdown-to-HTML conversion:

App/src/components/MenuItem.tsx

Lines 687 to 692 in 69a3bdc

	const html = useMemo(() => {
	if (!title || !shouldParseTitle) {
	return '';
	}
	return Parser.replace(title, {shouldEscapeText, disabledRules: excludedMarkdownRules});
	}, [title, shouldParseTitle, shouldEscapeText, excludedMarkdownRules]);

When the input is already HTML, Parser.replace HTML-escapes the <a> tags as literal text (because <, >, " are not markdown), producing the visible <a href=...>google.com</a> that the user sees.

Why this is a recent regression: Before 3d0e61b00012e4f20c3e3d48f9e5160fb6b445a6 ("remove redundant props"), SplitBillDetailsPage passed the split comment down as iouComment={Parser.htmlToMarkdown(splitComment ?? '')} — it normalized the stored HTML back into markdown before handing it to the confirmation list, so shouldParseTitle could re-parse it correctly. That refactor removed the per-caller iouComment prop and replaced it with an internal derivation getDescription(transaction) that returns raw HTML. Draft-transaction callers (e.g. IOURequestStepConfirmation) were unaffected because their draft comments are still plain markdown, but the Split details page now feeds HTML into a markdown parser, which is the bug.

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

Restore the HTML-to-markdown normalization at the shared derivation point inside MoneyRequestConfirmationList.tsx, so every downstream consumer of iouComment (the read-only MenuItemWithTopDescription and the editable TextInput type="markdown" on the same screen) receives a consistent markdown string regardless of whether the underlying transaction is a draft or a saved one.

Concretely, at MoneyRequestConfirmationList.tsx#L294, wrap the result of getDescription(transaction) with Parser.htmlToMarkdown(...) (importing Parser from @libs/Parser). For plain-text draft comments, htmlToMarkdown is effectively a no-op, so the existing non-split flow keeps working; for saved transactions, <a href="https://google.com">google.com</a> becomes [google.com](https://google.com), which the existing shouldParseTitle → Parser.replace pipeline in MenuItem then renders as a clickable link.

This restores the exact normalization that SplitBillDetailsPage performed prior to the refactor, but applies it at the single shared source of truth rather than leaving each caller responsible for the conversion.

What alternative solutions did you explore? (Optional)

Flip the consumer flag from shouldParseTitle to shouldRenderAsHTML on the description MenuItemWithTopDescription. This would fix the specific rendering path in the read-only footer (matching how MoneyRequestView.tsx at line 965 renders the same field), but it has two drawbacks compared to fixing at the producer:

1. It does not cover the editable branch on the same screen at MoneyRequestConfirmationListFooter.tsx#L797-L810, where a TextInput type="markdown" is fed the same iouComment value and would still display raw HTML tags when editing a saved split whose draft is seeded from the stored transaction.
2. Draft transactions in other flows still contain plain text like google.com, and shouldRenderAsHTML does not auto-link bare URLs the way shouldParseTitle (via Parser.replace) does — so switching the flag would silently regress auto-linking for confirmation pages that show draft comments.

Fixing at the producer keeps shouldParseTitle/type="markdown" consumers working for both storage formats with a single-point change.

---

Compare: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/87519-split-details-html-tags?expand=1

[wildan-m]

Proposal updated — added compare branch with implementation.

[Ltbltbltbltb]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.