[$250] Report list components do not parse HTML entities (ExpenseReportListItemRowWide / ExpenseReportListItemRowNarrow / MoneyRequestReportPreviewBody)

[MelvinBot]

Problem

The report list components do not parse HTML entities, so entity-encoded characters (e.g. &, ', ") are displayed as raw text instead of being rendered as their intended characters.

Affected components:

• ExpenseReportListItemRowWide
• ExpenseReportListItemRowNarrow
• MoneyRequestReportPreviewBody

Expected behavior

Text containing HTML entities should be decoded and displayed as the intended characters (e.g. & → &).

Actual behavior

HTML entities are shown verbatim as raw text.

Notes

Discovered by jmgraa while debugging #95335 (iOS Share Extension performance). It is unrelated to that issue and is being tracked separately here per mjasikowski's request.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022075559845485706910
• Upwork Job ID: 2075559845485706910
• Last Price Increase: 2026-07-10

[MelvinBot]

Proposal

What is the root cause of that problem?

Report names are stored HTML/markdown-encoded (e.g. Bob & Co). Everywhere the app displays a report name it must first decode it with Parser.htmlToText(...) — see the established precedent at ReportUtils.ts:6916 and the task list path at SearchUIUtils.ts:2592.

The three affected components render the name raw, skipping that decode step, so entities show verbatim:

• Wide row — item.reportName passed straight to TextCell at ExpenseReportListItemRowWide.tsx:152
• Narrow row — {item.reportName ?? ''} rendered directly at ExpenseReportListItemRowNarrow.tsx:62
• Report preview — MoneyRequestReportPreviewBody renders its title via ReportPreviewHeader, which prints {reportName || action.childReportName} raw at ReportPreviewHeader.tsx:105

The value fed to the search rows is set from the raw report (...reportItem) at SearchUIUtils.ts:2925 and is never decoded (the isIOUReport branch just below only overrides it with a translated "owes/paid" string).

Reference: the correct pattern already used elsewhere

MerchantCell decodes before display at MerchantCell.tsx:37:

StringUtils.lineBreaksToSpaces(Parser.htmlToText(merchantOrDescription))

Note: even the derived/attribute report name still needs decoding — ReportUtils.ts:6916 wraps getReportName(...) in Parser.htmlToText, so ReportPreviewHeader (which reads the derived reportNameSelector) is affected too, not just the search rows.

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

Decode the report name with Parser.htmlToText before it reaches these components. Two clean options:

1. At the data layer (covers both search rows in one place): decode reportName where the expense-report group item is built in SearchUIUtils.ts (~line 2925), matching how the task path already does it at line 2592. Wide + narrow rows then render the correct value with no per-component change.
2. At the render layer: decode in each component — wrap item.reportName in the wide/narrow rows and reportName || action.childReportName in ReportPreviewHeader with Parser.htmlToText(...).

ReportPreviewHeader needs the render-layer fix regardless, since its name comes from the derived report attributes rather than the search data pipeline.

Recommended: option 1 for the two search rows + the render-layer fix for ReportPreviewHeader.

What alternative solutions did you explore? (Optional)

Using Str.htmlDecode instead of Parser.htmlToText — rejected. Parser.htmlToText is the app-wide convention for report/merchant names (it both strips markup and decodes entities); Str.htmlDecode is used for simpler cases like category names.

---

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

[samranahm]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-14 01:23:12 UTC.

Proposal

What is the root cause of that problem?

When report names or other descriptive text containing HTML entities (e.g., &, ', ") are displayed in ExpenseReportListItemRowWide, ExpenseReportListItemRowNarrow, and MoneyRequestReportPreviewBody (via its children), the raw entity codes are shown. This occurs because these components render the text directly into React Native Text components without prior decoding. The Text component does not automatically parse HTML entities, leading to their verbatim display instead of the intended characters.

For example, in ExpenseReportListItemRowNarrow, the item.reportName is rendered directly into a Text component:

App/src/components/Search/SearchList/ListItem/ExpenseReportListItemRow/ExpenseReportListItemRowNarrow.tsx

Lines 58 to 63 in af11be2

	<Text
	numberOfLines={2}
	style={[styles.lh20, styles.flex1]}
	>
	{item.reportName ?? ''}
	</Text>

Similarly, other text fields in the affected components are displayed without decoding, causing the HTML entities to appear as raw text.

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

We should reuse the existing Str.htmlDecode from expensify-common and apply it to the relevant text fields in the affected components before they are rendered.

1. Use Str.htmlDecode the same way other screens already do:

   import {Str} from 'expensify-common';
   
   Str.htmlDecode(text);

2. In ExpenseReportListItemRowNarrow.tsx, import Str and apply Str.htmlDecode to item.reportName and item.text before they are rendered in Text components or used for accessibility labels.

   App/src/components/Search/SearchList/ListItem/ExpenseReportListItemRow/ExpenseReportListItemRowNarrow.tsx

   Lines 58 to 63 in af11be2

   	<Text
   	numberOfLines={2}
   	style={[styles.lh20, styles.flex1]}
   	>
   	{item.reportName ?? ''}
   	</Text>

   <Text
       numberOfLines={2}
       style={[styles.lh20, styles.flex1]}
   >
       {Str.htmlDecode(item.reportName ?? '')}
   </Text>

   App/src/components/Search/SearchList/ListItem/ExpenseReportListItemRow/ExpenseReportListItemRowNarrow.tsx

   Line 50 in af11be2

   accessibilityLabel={item.text ?? ''}

   accessibilityLabel={Str.htmlDecode(item.text ?? '')}

3. In ExpenseReportListItemRowWide.tsx, import Str and apply Str.htmlDecode to item.reportName wherever it is displayed within the component or its child components. This ensures that any report name text is correctly decoded.

   App/src/components/Search/SearchList/ListItem/ExpenseReportListItemRow/ExpenseReportListItemRowWide.tsx

   Lines 149 to 155 in af11be2

   	[CONST.SEARCH.TABLE_COLUMNS.TITLE]: (
   	<View style={[StyleUtils.getReportTableColumnStyles(CONST.SEARCH.TABLE_COLUMNS.TITLE)]}>
   	<TextCell
   	text={item.reportName ?? ''}
   	isLargeScreenWidth
   	/>
   	</View>

   <TextCell
       text={Str.htmlDecode(item.reportName ?? '')}
       isLargeScreenWidth
   />

4. In ReportPreviewHeader.tsx (rendered by MoneyRequestReportPreviewBody.tsx), import Str and apply Str.htmlDecode to the report name before it is rendered in the header Text component.

   App/src/components/ReportActionItem/MoneyRequestReportPreview/ReportPreviewHeader.tsx

   Line 50 in af11be2

   const reportName = derivedReportName ?? iouReport?.reportName ?? '';

   App/src/components/ReportActionItem/MoneyRequestReportPreview/ReportPreviewHeader.tsx

   Lines 101 to 106 in af11be2

   	<Text
   	style={[styles.headerText]}
   	testID="MoneyRequestReportPreview-reportName"
   	>
   	{reportName || action.childReportName}
   	</Text>

   const reportName = Str.htmlDecode(derivedReportName ?? iouReport?.reportName ?? action.childReportName ?? '');
   // ...
   {reportName}

These changes will ensure that HTML entities are properly decoded and displayed as their intended characters across all affected report list components.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

Solution Verification Result

Kapture.2026-07-14.at.06.21.13.mp4

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-10 12:39:37 UTC.

Proposal

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

Expense-report names containing HTML entities (&, ', ") are shown verbatim in the Reports list rows (ExpenseReportListItemRowWide/ExpenseReportListItemRowNarrow) and in the report preview card in chat (MoneyRequestReportPreviewBody), instead of the decoded characters (&, ', ").

What is the root cause of that problem?

The backend stores and returns report names HTML-entity-encoded, and the app's convention is to decode at the display layer with Parser.htmlToText. That is why the same name renders correctly in the report header and LHN — DisplayNames decodes before rendering:

App/src/components/DisplayNames/index.tsx

Line 28 in 5b52fc0

const processedTitle = shouldParseFullTitle ? Parser.htmlToText(fullTitle) : fullTitle;

(native mirror:

App/src/components/DisplayNames/index.native.tsx

Line 20 in 5b52fc0

const processedTitle = shouldParseFullTitle ? Parser.htmlToText(fullTitle) : fullTitle;

)

The three reported components sit on two data paths that both skip this decode:

Path 1 — Search/Reports rows. getReportSections builds each expense-report row by spreading the raw snapshot report — {...reportItem} — so item.reportName keeps the encoded string:

App/src/libs/SearchUIUtils.ts

Lines 2925 to 2931 in 5b52fc0

	reportIDToTransactions[reportKey] = {
	...reportItem,
	action: getAction(allActions, primaryActionExclusions),
	allActions,
	...getRowCapabilities(allActions),
	keyForList: String(reportItem.reportID),
	groupedBy: CONST.SEARCH.DATA_TYPES.EXPENSE_REPORT,

The task path in the same file already decodes (StringUtils.lineBreaksToSpaces(Parser.htmlToText(...))) — the expense-report path just never got the same treatment:

App/src/libs/SearchUIUtils.ts

Line 2592 in 5b52fc0

const reportName = StringUtils.lineBreaksToSpaces(Parser.htmlToText(taskItem.reportName));

The encoded value then hits plain-text render sinks with no decode:

1. Wide row, TITLE column TextCell:

   App/src/components/Search/SearchList/ListItem/ExpenseReportListItemRow/ExpenseReportListItemRowWide.tsx

   Lines 149 to 156 in 5b52fc0

   	[CONST.SEARCH.TABLE_COLUMNS.TITLE]: (
   	<View style={[StyleUtils.getReportTableColumnStyles(CONST.SEARCH.TABLE_COLUMNS.TITLE)]}>
   	<TextCell
   	text={item.reportName ?? ''}
   	isLargeScreenWidth
   	/>
   	</View>
   	),

2. Narrow row title Text:

   App/src/components/Search/SearchList/ListItem/ExpenseReportListItemRow/ExpenseReportListItemRowNarrow.tsx

   Lines 58 to 63 in 5b52fc0

   	<Text
   	numberOfLines={2}
   	style={[styles.lh20, styles.flex1]}
   	>
   	{item.reportName ?? ''}
   	</Text>

3. Narrow row screen-reader label (announces & aloud):

   App/src/components/Search/SearchList/ListItem/ExpenseReportListItemRow/ExpenseReportListItemRowNarrow.tsx

   Line 34 in 5b52fc0

   const groupAccessibilityLabel = [item.reportName, amountText, formattedDate, expenseCountText].filter(Boolean).join(', ');

4. TITLE-column sorting compares encoded strings, so "A & B" sorts as "A & B":

   App/src/libs/SearchUIUtils.ts

   Lines 3951 to 3957 in 5b52fc0

   	if (sortBy === CONST.SEARCH.TABLE_COLUMNS.TITLE) {
   	return data.sort((a, b) => {
   	const aValue = a.report?.reportName ?? '';
   	const bValue = b.report?.reportName ?? '';
   	return compareValues(aValue, bValue, sortOrder, sortBy, localeCompare);
   	});

Path 2 — report preview card. MoneyRequestReportPreviewBody composes ReportPreviewHeader (

App/src/components/ReportActionItem/MoneyRequestReportPreview/MoneyRequestReportPreviewBody.tsx

Line 137 in 5b52fc0

<ReportPreviewHeader />

), which reads the derived report name — for expense reports computeReportName returns report.reportName raw (

App/src/libs/ReportNameUtils.ts

Lines 981 to 983 in 5b52fc0

	if (report?.reportName && report.type === CONST.REPORT.TYPE.EXPENSE) {
	return report?.reportName;
	}

) — and renders it in a plain Text with no decode:

App/src/components/ReportActionItem/MoneyRequestReportPreview/ReportPreviewHeader.tsx

Lines 101 to 106 in 5b52fc0

	<Text
	style={[styles.headerText]}
	testID="MoneyRequestReportPreview-reportName"
	>
	{reportName || action.childReportName}
	</Text>

The structural cause: the encoded-in-storage / decode-at-display contract is enforced by DisplayNames, but these surfaces render the name through plain Text/TextCell, so the decode step is silently skipped. This explains all three named components and why the identical name is correct in the report header.

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

1. Decode at the single convergence point for the Search rows — in getReportSections, mirror the existing task-path transform right after the spread (SearchUIUtils already imports Parser and StringUtils):

reportIDToTransactions[reportKey] = {
    ...reportItem,
    reportName: StringUtils.lineBreaksToSpaces(Parser.htmlToText(reportItem.reportName ?? '')),
    ...

One line fixes the wide row, the narrow row, the narrow row's accessibility label, and TITLE sorting at once. The IOU-report override at

App/src/libs/SearchUIUtils.ts

Lines 2961 to 2963 in 5b52fc0

	if (isIOUReport) {
	reportIDToTransactions[reportKey].reportName = getIOUReportName(translate, convertToDisplayString, data, reportIDToTransactions[reportKey]);
	}

runs after this assignment and builds a locale string with no entities, so it is unaffected.

2. Decode at render in ReportPreviewHeader (add import Parser from '@libs/Parser';), matching the DisplayNames/TaskPreview precedent:

{Parser.htmlToText(reportName || action.childReportName || '')}

This also covers the action.childReportName fallback, which is backend-provided and equally encoded.

Regression safety: the task path already applies this exact transform in the same function family, and no consumer of these values needs the encoded shape — getIOUReportName never reads reportItem.reportName, and the derived reportAttributes value itself stays untouched.

Why the obvious spot-fix fails: wrapping just the two visible <Text> sinks in the row components misses the narrow row's groupAccessibilityLabel (screen readers keep announcing &), leaves TITLE sorting comparing encoded strings, and does nothing for the preview card, which is fed by a different data path (derived reportAttributes, not the search snapshot). Equally, the other "central" candidate — decoding inside computeReportName — is unsafe: DisplayNames applies Parser.htmlToText to that same derived value at render, so decoding upstream would double-decode names that legitimately contain entity text (a report literally named A & B is stored as A & B and would corrupt to A & B); every DisplayNames consumer depends on the current encoded shape.

What alternative solutions did you explore? (Optional)

• Decode in each of the three components — works, but leaves the decode duplicated across sinks, is easy to miss on the accessibility label, and doesn't fix TITLE sorting; the data-source fix matches the in-file task precedent.
• Decode in computeReportName/derived attributes — rejected above: double-decodes for every DisplayNames consumer (report header, LHN).
• Render the name via RenderHTML — heavyweight for a one-line plain-text field and would change layout inside FlashList rows; names are plain text, only entity-decoding is needed.

[shivang-goliyan]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-10 12:54:07 UTC.

Proposal

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

When an expense report's stored title contains HTML entities (', £, ©, <, …), that title renders as raw entity text instead of the characters it represents. It happens in the Search report list (both the wide and narrow rows) and in the money request report preview header. So a report stored as John's £100 © R&D reads exactly like that on screen, instead of John's £100 © R&D.

What is the root cause of that problem?

Report titles can arrive HTML-entity-encoded, and decoding them back to plain text is a client render-time job that this repo already does everywhere else (the LHN and the chat header both decode). These three surfaces just skip that one hop. There are two separate data paths.

Where the encoding actually comes from (tested, not assumed): NewDot's own rename does not encode. I renamed a report to Bob's R&D "Q3" and then to John's £100 © R&D; both came back from the server byte-for-byte unencoded (verified against main, which has no decode, in a fresh browser with an empty Onyx). NewDot's title field also rejects < and > outright ("Invalid character"), so Risk Assessment <Internal> in the screenshot on this issue cannot have been typed into NewDot at all. The encoded names therefore come from a different writer — OldDot, the API, or the Share Extension path this was found under (#95335). That is precisely why the fix has to live on the render/derive side: the client cannot assume anything about who wrote the value, so these components must decode whatever they are handed.

For the Search rows, the name comes from getReportSections() in SearchUIUtils.ts. At line 2925 it spreads the raw Onyx report object (...reportItem) straight into the row, so item.reportName stays encoded. ExpenseReportListItemRowWide.tsx and ExpenseReportListItemRowNarrow.tsx:62 render that value as-is. The interesting part is that the same builder already decodes the sibling task rows one block up at SearchUIUtils.ts:2591 with StringUtils.lineBreaksToSpaces(Parser.htmlToText(taskItem.reportName)) — expense reports just never got the same treatment. Worth noting: IOU reports aren't affected, because line 2962 overrides their name with the synthesized getIOUReportName(...) string. Only user-typed expense-report titles hit this.

The preview header is a different path. MoneyRequestReportPreviewBody renders no title itself; it composes ReportPreviewHeader. There, reportName = derivedReportName ?? iouReport?.reportName ?? '' (line 50), where derivedReportName traces back through reportNameSelector to computeReportName, which returns report.reportName verbatim. The header then renders {reportName || action.childReportName} at line 105 — and both operands are raw, so the fallback path is broken too.

This is an original flaw, not a regression. The Search rows shipped encoded when they were first added, and no PR on any of these files has ever added the decode. So the fix is to add Parser.htmlToText, not restore anything.

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

Fix it at the two data sources rather than at each render site.

For the Search rows, decode once in getReportSections() after the ...reportItem spread, mirroring the task branch:

reportName: StringUtils.lineBreaksToSpaces(Parser.htmlToText(reportItem.reportName ?? '')),

Parser and StringUtils are already imported in that file, and the IOU override at line 2962 still runs afterward so IOU names stay correct. Doing it here (not at the render sites) also fixes the narrow row's accessibility label at ExpenseReportListItemRowNarrow.tsx:34, which builds a screen-reader string from the same raw item.reportName — a render-only patch on line 62 would leave & being read aloud to screen-reader users.

For the preview header, decode both operands at ReportPreviewHeader.tsx:105 (add import Parser from '@libs/Parser'):

{Parser.htmlToText(reportName || action.childReportName || '')}

I'd also add test coverage, since neither path has a decode assertion today. In tests/unit/Search/SearchUIUtilsTest.ts, an expense-report fixture with reportName "A & B 'C'" should assert the built section's reportName comes out as "A & B 'C'", plus a ReportPreviewHeader render test checking the title renders decoded characters.

This affects all platforms (Web, iOS, Android, mWeb, MacOS) since it's pure render logic.

Before / After results

Same account, same report, same stored title (John's £100 © R&D). The only thing
that differs between the two is the checked-out branch.
Compare branch: main...shivang-goliyan:App:shivang-goliyan/95808-decode-html-entities-report-list

Search report list (ExpenseReportListItemRowWide / …Narrow)

Before (main)	After (this fix)

Report preview card (MoneyRequestReportPreviewBody → ReportPreviewHeader)

Before (main)	After (this fix)

In the "before" preview shot, note that the LHN row for the same report is already decoded
(John's £100 © …) while the preview card beside it is not — that inconsistency is the bug in one frame.

Read back from the DOM rather than eyeballed:

before -> search row: "John's £100 © R&D"
          preview   : "John's £100 © R&D"
after  -> search row: "John's £100 © R&D"
          preview   : "John's £100 © R&D"

What alternative solutions did you explore? (Optional)

Decoding inside computeReportName / the derived REPORT_ATTRIBUTES looked tempting since it's the shared name source, but it doesn't work here: the Search rows read the raw ...reportItem spread, not the derived attribute, so they'd stay broken. It would also double-decode the existing consumers that already wrap the name in Parser.htmlToText (e.g. ReportUtils.ts:6916/6930), and risk changing LHN and sort-key behavior. Decoding at each render site works but takes three edits and still has to catch the narrow a11y label, which is easy to miss.

One adjacent thing I noticed while tracing this: the task search rows' parentReportName (SearchUIUtils.ts:2610) also isn't decoded and renders raw through TaskListItemRow. Same class of bug, not in this issue's scope, but easy to fold into the same source-level fix if we want the Search lists to decode consistently.

[melvin-bot]

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

[melvin-bot]

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

[nabi-ebrahimi]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-14 06:59:38 UTC.

Proposal

What is the root cause of that problem?

Report names arrive HTML-entity-encoded from the backend, and the app's convention is to decode them with Parser.htmlToText() at display time see ReportUtils.ts:6919

App/src/libs/ReportUtils.ts

Line 6919 in 8b5ddb4

const reportName = Parser.htmlToText(getReportName(report, reportAttributes) ?? report?.reportName ?? '');

and the task-row path at SearchUIUtils.ts:2592

App/src/libs/SearchUIUtils.ts

Line 2592 in 8b5ddb4

const reportName = StringUtils.lineBreaksToSpaces(Parser.htmlToText(taskItem.reportName));

These three components sit on two data paths where that decode step is missing.

Path 1 — Search expense-report rows. getReportSections builds each expense-report list item by spreading the raw snapshot report (...reportItem), so item.reportName stays encoded:

• SearchUIUtils.ts:2925–2931

  App/src/libs/SearchUIUtils.ts

  Lines 2925 to 2931 in 8b5ddb4

  	reportIDToTransactions[reportKey] = {
  	...reportItem,
  	action: getAction(allActions, primaryActionExclusions),
  	allActions,
  	...getRowCapabilities(allActions),
  	keyForList: String(reportItem.reportID),
  	groupedBy: CONST.SEARCH.DATA_TYPES.EXPENSE_REPORT,

  — raw spread, no decode
• ExpenseReportListItemRowWide.tsx:149–155

  App/src/components/Search/SearchList/ListItem/ExpenseReportListItemRow/ExpenseReportListItemRowWide.tsx

  Lines 149 to 155 in 8b5ddb4

  	[CONST.SEARCH.TABLE_COLUMNS.TITLE]: (
  	<View style={[StyleUtils.getReportTableColumnStyles(CONST.SEARCH.TABLE_COLUMNS.TITLE)]}>
  	<TextCell
  	text={item.reportName ?? ''}
  	isLargeScreenWidth
  	/>
  	</View>

  — passes raw item.reportName to TextCell
• ExpenseReportListItemRowNarrow.tsx:33–40

  App/src/components/Search/SearchList/ListItem/ExpenseReportListItemRow/ExpenseReportListItemRowNarrow.tsx

  Lines 33 to 40 in 8b5ddb4

  	const amountText = isScanning ? translate('iou.receiptStatusTitle') : convertToDisplayString(totalDisplaySpend, currency);
  	const groupAccessibilityLabel = [item.reportName, amountText, formattedDate, expenseCountText].filter(Boolean).join(', ');
  	return (
  	<View
  	style={[styles.flexRow, styles.alignItemsCenter, styles.gap3, styles.pt3]}
  	accessible
  	accessibilityLabel={groupAccessibilityLabel}

  — raw value in accessibility label
• ExpenseReportListItemRowNarrow.tsx:56–64

  App/src/components/Search/SearchList/ListItem/ExpenseReportListItemRow/ExpenseReportListItemRowNarrow.tsx

  Lines 56 to 64 in 8b5ddb4

  	<View style={[styles.flexColumn, styles.gap1, styles.flex1]}>
  	<View style={[styles.flexRow, styles.gap2]}>
  	<Text
  	numberOfLines={2}
  	style={[styles.lh20, styles.flex1]}
  	>
  	{item.reportName ?? ''}
  	</Text>
  	<Text style={[styles.lh20, styles.flexShrink0, styles.textAlignRight]}>{amountText}</Text>

  — raw value in visible text

The sibling task path in the same file already decodes at SearchUIUtils.ts:2592

App/src/libs/SearchUIUtils.ts

Line 2592 in 8b5ddb4

const reportName = StringUtils.lineBreaksToSpaces(Parser.htmlToText(taskItem.reportName));

— the expense-report branch simply never received the same treatment.

Path 2 — Money-request report preview. MoneyRequestReportPreviewBody composes ReportPreviewHeader, which resolves and renders the title. The header reads the derived report name (via reportNameSelector) and falls back to action.childReportName:

• ReportPreviewHeader.tsx:48–50

  App/src/components/ReportActionItem/MoneyRequestReportPreview/ReportPreviewHeader.tsx

  Lines 48 to 50 in 8b5ddb4

  	const selectReportName = useCallback((attributes: OnyxEntry<ReportAttributesDerivedValue>) => reportNameSelector(attributes, iouReportID), [iouReportID]);
  	const [derivedReportName] = useOnyx(ONYXKEYS.DERIVED.REPORT_ATTRIBUTES, {selector: selectReportName});
  	const reportName = derivedReportName ?? iouReport?.reportName ?? '';

  — derivedReportName ?? iouReport?.reportName ?? ''
• ReportPreviewHeader.tsx:95–106

  App/src/components/ReportActionItem/MoneyRequestReportPreview/ReportPreviewHeader.tsx

  Lines 95 to 106 in 8b5ddb4

  	return (
  	<View style={[styles.expenseAndReportPreviewTextContainer, styles.overflowHidden]}>
  	<View style={[styles.flexRow, styles.justifyContentBetween, styles.flexShrink1, styles.gap1]}>
  	<View style={[styles.flexColumn, styles.gap1, styles.flexShrink1]}>
  	<View style={[styles.flexRow, styles.mw100, styles.flexShrink1]}>
  	<Animated.View style={[styles.flexRow, styles.alignItemsCenter, previewMessageStyle, styles.flexShrink1]}>
  	<Text
  	style={[styles.headerText]}
  	testID="MoneyRequestReportPreview-reportName"
  	>
  	{reportName || action.childReportName}
  	</Text>

  — renders {reportName || action.childReportName} raw

Both branches are encoded. The computeReportName resolver in ReportNameUtils.ts:981–982

App/src/libs/ReportNameUtils.ts

Lines 981 to 982 in 8b5ddb4

	if (report?.reportName && report.type === CONST.REPORT.TYPE.EXPENSE) {
	return report?.reportName;

returns report.reportName raw for expense reports, while the task branch at line 1009

App/src/libs/ReportNameUtils.ts

Line 1009 in 8b5ddb4

return Parser.isHTML(taskName) ? Parser.htmlToText(taskName).trim() : taskName.trim();

already decodes.

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

Decode the report name with Parser.htmlToText() at each affected display boundary. Use the existing Parser.isHTML() guard to only decode strings that actually contain markup or entities — plain-text names pass through unchanged with zero overhead.

Change 1 — ExpenseReportListItemRowNarrow.tsx

Add a decoded formattedReportName and reuse it for both the visible title and the accessibility label:

const reportName = item.reportName ?? '';
const formattedReportName = Parser.isHTML(reportName) ? Parser.htmlToText(reportName) : reportName;

• Use formattedReportName in groupAccessibilityLabel (line 34

  App/src/components/Search/SearchList/ListItem/ExpenseReportListItemRow/ExpenseReportListItemRowNarrow.tsx

  Line 34 in 8b5ddb4

  const groupAccessibilityLabel = [item.reportName, amountText, formattedDate, expenseCountText].filter(Boolean).join(', ');

  instead of raw item.reportName
• Use formattedReportName in the visible <Text> (line 62

  App/src/components/Search/SearchList/ListItem/ExpenseReportListItemRow/ExpenseReportListItemRowNarrow.tsx

  Line 62 in 8b5ddb4

  {item.reportName ?? ''}

  instead of {item.reportName ?? ''}

Change 2 — ExpenseReportListItemRowWide.tsx

Same pattern — add decoded formattedReportName and pass it to the title TextCell:

const reportName = item.reportName ?? '';
const formattedReportName = Parser.isHTML(reportName) ? Parser.htmlToText(reportName) : reportName;

• Use formattedReportName in the TextCell at line 152

  App/src/components/Search/SearchList/ListItem/ExpenseReportListItemRow/ExpenseReportListItemRowWide.tsx

  Line 152 in 8b5ddb4

  text={item.reportName ?? ''}

  instead of {item.reportName ?? ''}

Change 3 — ReportPreviewHeader.tsx

Consolidate the fallback chain into the variable, decode the result, and wrap in useMemo (matching the component's existing memoization pattern for reportStatus, reportStatusTooltip, and expenseCount):

const reportName = (derivedReportName ?? iouReport?.reportName) || action.childReportName || '';
const formattedReportName = useMemo(
    () => (Parser.isHTML(reportName) ? Parser.htmlToText(reportName) : reportName),
    [reportName],
);

• Use formattedReportName in the <Text> at line 105

  App/src/components/ReportActionItem/MoneyRequestReportPreview/ReportPreviewHeader.tsx

  Line 105 in 8b5ddb4

  {reportName || action.childReportName}

  instead of {reportName || action.childReportName}

What alternative solutions did you explore? (Optional)

Data-layer fix in getReportSections (lines 2925–2931). Decoding reportName when the list item is built — matching the task-row pattern at line 2592

App/src/libs/SearchUIUtils.ts

Line 2592 in 8b5ddb4

const reportName = StringUtils.lineBreaksToSpaces(Parser.htmlToText(taskItem.reportName));

This would fix both row components in one place but has a wider blast radius: every consumer of the list item's reportName would get the decoded value. The render-site approach is more explicit about which surfaces are affected and avoids changing the data contract.

**Global decode in computeReportName ReportNameUtils.ts:981–982

App/src/libs/ReportNameUtils.ts

Lines 981 to 982 in 8b5ddb4

	if (report?.reportName && report.type === CONST.REPORT.TYPE.EXPENSE) {
	return report?.reportName;

** Fixing the expense branch of the central name resolver to match the task branch at line 1009

App/src/libs/ReportNameUtils.ts

Line 1009 in 8b5ddb4

return Parser.isHTML(taskName) ? Parser.htmlToText(taskName).trim() : taskName.trim();

This would fix all consumers of the derived report name, not just the three listed components. However, it changes the semantics of a shared derived value and would not cover the action.childReportName fallback path in ReportPreviewHeader.

Hand-rolled HtmlUtils.ts. Rejected — the codebase already has Parser.htmlToText() as the canonical decode utility. Creating a new file with only 3 entity replacements (&, ', ") is an incomplete subset that misses <, >, £, numeric references, etc.

Str.htmlDecode from expensify-common. Rejected — Str.htmlDecode only decodes entities (&, ') but does not strip HTML markup (<b>, <i>). Report names can contain markup, and Parser.htmlToText() is the established convention for report/merchant names (see MerchantCell.tsx:37, ReportUtils.ts:6919, SearchUIUtils.ts:2592).

parentReportName for task rows (SearchUIUtils.ts:2614). This reads from getReportName() which returns encoded names for expense reports — same class of bug in the same file. This is outside the three affected components listed in the issue, so it is not included in the fix above, but could be folded into the same PR if desired.

Before / After

Before:

Before.mp4

After:

Final.mp4

[wildan-m]

Proposal

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

Report titles that contain HTML entities (for example &, ', ") are rendered verbatim as raw escaped text instead of being decoded to the characters they represent (&, ', "). This affects the report title shown in the Search expense-report list (both the wide/table layout and the narrow/mobile layout) and the report title shown in the money request report preview card in chat.

What is the root cause of that problem?

Report names arrive from the back end HTML-encoded. Throughout the app, a report name is expected to be run through Parser.htmlToText() before it is displayed as plain text. There are two independent places where that decoding step is missing.

1. The Search expense-report list items never decode reportName.

The list item objects for expense-report search results are built by spreading the raw search snapshot report straight into the list item, so reportName carries the encoded string through untouched:

App/src/libs/SearchUIUtils.ts

Lines 2925 to 2931 in 242f0cd

	reportIDToTransactions[reportKey] = {
	...reportItem,
	action: getAction(allActions, primaryActionExclusions),
	allActions,
	...getRowCapabilities(allActions),
	keyForList: String(reportItem.reportID),
	groupedBy: CONST.SEARCH.DATA_TYPES.EXPENSE_REPORT,

Both row components then render that value directly as plain text. The wide layout passes it into the title TextCell:

App/src/components/Search/SearchList/ListItem/ExpenseReportListItemRow/ExpenseReportListItemRowWide.tsx

Lines 149 to 156 in 242f0cd

	[CONST.SEARCH.TABLE_COLUMNS.TITLE]: (
	<View style={[StyleUtils.getReportTableColumnStyles(CONST.SEARCH.TABLE_COLUMNS.TITLE)]}>
	<TextCell
	text={item.reportName ?? ''}
	isLargeScreenWidth
	/>
	</View>
	),

and the narrow layout renders it inside a Text:

App/src/components/Search/SearchList/ListItem/ExpenseReportListItemRow/ExpenseReportListItemRowNarrow.tsx

Lines 58 to 63 in 242f0cd

	<Text
	numberOfLines={2}
	style={[styles.lh20, styles.flex1]}
	>
	{item.reportName ?? ''}
	</Text>

Neither TextCell nor Text decodes entities, so the escaped sequence reaches the screen as-is.

This is a gap rather than an intentional choice: the sibling branch of the very same builder, which produces the task search list items, does decode its reportName before handing it to the row component:

App/src/libs/SearchUIUtils.ts

Lines 2592 to 2593 in 242f0cd

	const reportName = StringUtils.lineBreaksToSpaces(Parser.htmlToText(taskItem.reportName));
	const description = StringUtils.lineBreaksToSpaces(Parser.htmlToText(taskItem.description));

The expense-report branch simply never received the equivalent treatment.

2. The money request report preview header never decodes reportName.

MoneyRequestReportPreviewBody is a pure layout component and owns no text of its own — it composes ReportPreviewHeader, which is the component that actually resolves and renders the report title. It picks the derived report name, falling back to the report's own reportName:

App/src/components/ReportActionItem/MoneyRequestReportPreview/ReportPreviewHeader.tsx

Lines 48 to 50 in 242f0cd

	const selectReportName = useCallback((attributes: OnyxEntry<ReportAttributesDerivedValue>) => reportNameSelector(attributes, iouReportID), [iouReportID]);
	const [derivedReportName] = useOnyx(ONYXKEYS.DERIVED.REPORT_ATTRIBUTES, {selector: selectReportName});
	const reportName = derivedReportName ?? iouReport?.reportName ?? '';

and renders the result as plain text without decoding:

App/src/components/ReportActionItem/MoneyRequestReportPreview/ReportPreviewHeader.tsx

Lines 100 to 106 in 242f0cd

	<Animated.View style={[styles.flexRow, styles.alignItemsCenter, previewMessageStyle, styles.flexShrink1]}>
	<Text
	style={[styles.headerText]}
	testID="MoneyRequestReportPreview-reportName"
	>
	{reportName || action.childReportName}
	</Text>

Both branches of that fallback are encoded. The derived value comes from computeReportName, and the fallback is the raw report.reportName — and elsewhere in the codebase, exactly that pair is explicitly wrapped in Parser.htmlToText before being surfaced as text:

App/src/libs/ReportUtils.ts

Line 6916 in 242f0cd

const reportName = Parser.htmlToText(getReportName(report, reportAttributes) ?? report?.reportName ?? '');

So the root cause is that these three components sit on two display paths where the established "decode the report name before showing it as plain text" step was never applied.

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

Apply the decoding at the two points where the encoded value is produced, so that every consumer of it benefits and the row components stay presentational.

For the Search expense-report list items, decode reportName in the expense-report branch of the search sections builder in src/libs/SearchUIUtils.ts, at the point where the list item is assembled from the snapshot report. Pass the report name through the parser's HTML-to-text conversion (and collapse line breaks to spaces) before it is placed on the list item, mirroring exactly what the task branch of the same builder already does a few hundred lines above. Do this after the existing IOU report-name override runs, so a generated IOU name and a user-supplied name are both normalised the same way.

Decoding here rather than inside the row components is the better fix for three reasons: it fixes the wide layout and the narrow layout with one change; it also fixes the narrow layout's accessibility label, which is composed from the same reportName and would otherwise still announce the raw entity to screen readers; and it makes title sorting in the table compare decoded names, which is what a user visually sorting by title expects.

For the money request report preview, decode the resolved title in ReportPreviewHeader, which is the component MoneyRequestReportPreviewBody delegates the title to. Run the already-resolved name — after the derived-name/reportName/childReportName fallback chain has settled on a value — through the same HTML-to-text conversion before it is rendered into the Text element. Decoding after the fallback chain resolves means the encoded form cannot slip through on any of the three branches.

Both changes reuse the same src/libs/Parser wrapper that the codebase already relies on for report names — it is already imported in SearchUIUtils, and ReportPreviewHeader only needs to import it — so no new dependency or utility is introduced, and the decoding stays idempotent for names that contain no entities.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/95808-decode-html-entities-report-name?expand=1

What alternative solutions did you explore? (Optional)

I considered decoding inside the leaf presentational components — TextCell and the narrow row's Text — but rejected it. TextCell is a generic cell reused for report IDs, payroll IDs, order/deal numbers and paid status, none of which are HTML-encoded, so decoding there would apply an unrelated transformation to unrelated data and would silently mangle any legitimately literal ampersand-hash sequence in an ID field. It would also leave the narrow row's accessibility label and the table's title sort still operating on the encoded string.

I also considered normalising reportName once at the Onyx/derived-attributes layer so that every consumer receives a decoded name. That is arguably the cleanest long-term shape, but the derived report name is consumed in places that expect the HTML form (it is fed to renderers that parse markup), so changing it centrally risks double-decoding and regressions well outside the scope of this issue. Decoding at the two display-path boundaries keeps the blast radius proportionate to the bug.