[$250] Chat - All lines of message chat in the LHN are not separated by a space

[izarutskaya]

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.59-3
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://github.com/Expensify/Expensify/issues/359923
Email or phone of affected tester (no customers): undefined
Issue reported by: Applause Internal Team

Action Performed:

1. Open a chat
2. Send messages with some lines break:

Line 1

Line 2

Line 3

3. Verify that in LHN

Expected Result:

The chat in the LHN shows all lines of the message separated by a space.
Comment (#32497 (comment)) for more details of the expected result

Actual Result:

All lines of message chat in the LHN are not separated by a space.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7104903.1773722612333.A-32497.-.All.Lines.Of.Message.Chat.In.The.Lhn.Are.Not.Separated.By.A.Space.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @abzokhattab

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022044434328679460959
• Upwork Job ID: 2044434328679460959
• Last Price Increase: 2026-04-15

[MelvinBot]

Proposal

What is the root cause of that problem?

The LHN preview text pipeline converts <br /> tags to \n via Parser.htmlToText, then converts \n to spaces via lineBreaksToSpaces. This works correctly when the message HTML uses <br /> for line breaks.

However, expensify-common's htmlToText (ExpensiMark.js:687-765) only handles <br>, <blockquote>, <h1>, and <pre> as block elements that produce whitespace. All other block-level elements (<p>, <div>, etc.) are stripped by the catch-all stripTag rule with an empty string replacement — no whitespace is inserted.

If the message HTML contains <p> or <div> tags instead of (or alongside) <br /> tags for paragraph separation — which can happen through server-side HTML normalization, pasted external content, or OldDot messages — then htmlToText produces concatenated text like "Line 1Line 2Line 3" with no separators. Since there are no \n characters in the result, lineBreaksToSpaces (StringUtils/index.ts:126-128) has nothing to convert, and the lines appear concatenated in the LHN.

This is a regression of the fix from #32497 (PR #33217), which correctly addressed <br />-based newlines but didn't account for other block elements in htmlToText.

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

Add <p> and <div> to the block element handling rules in expensify-common's htmlToTextRules (alongside the existing <blockquote>, <h1>, <pre> rules), so that closing </p> and </div> tags produce a \n before being stripped. This ensures all block-level separators are converted to newlines, which lineBreaksToSpaces then converts to spaces for the LHN preview.

As a defense-in-depth measure in the App itself, formatLastMessageText in ReportActionsUtils.ts:1469-1482 could also collapse consecutive whitespace after converting line breaks to spaces (e.g., .replace(/\s{2,}/g, ' ')) to prevent multiple consecutive spaces from appearing.

What alternative solutions did you explore? (Optional)

An alternative would be to post-process the htmlToText output in the App by running a regex to ensure any run of zero-width transitions between text nodes gets at least one space. However, fixing htmlToText in expensify-common is the correct upstream fix since the gap affects all consumers of htmlToText, not just the LHN preview.

---

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 - @abzokhattab (External)

[melvin-bot]

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

[MobileMage]

Proposal

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

When a message contains multiple line breaks, the LHN (Left Hand Navigation) chat preview displays the message with multiple spaces between the lines instead of a single space.

What is the root cause of that problem?

The lineBreaksToSpaces function in src/libs/StringUtils/index.ts replaces each line break character (like \n or \r) with a space character. When there are consecutive line breaks (e.g., \n\n\n), it replaces them with consecutive spaces ( ). These multiple spaces are then displayed in the LHN as multiple spaces instead of collapsing into a single space, causing visual anomalies in the LHN text preview.

App/src/libs/StringUtils/index.ts

Lines 126 to 128 in c2bad17

	function lineBreaksToSpaces(text = '', useNonBreakingSpace = false) {
	return text.replaceAll(CONST.REGEX.LINE_BREAK, useNonBreakingSpace ? '\u00A0' : ' ');
	}

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

We should update the lineBreaksToSpaces function to collapse multiple consecutive line breaks (which become consecutive spaces) into a single space. We can do this by chaining a regex replace to collapse multiple spaces into a single space.

-function lineBreaksToSpaces(text = '', useNonBreakingSpace = false) {
-    return text.replaceAll(CONST.REGEX.LINE_BREAK, useNonBreakingSpace ? '\u00A0' : ' ');
-}
+function lineBreaksToSpaces(text = '', useNonBreakingSpace = false) {
+    const spaceChar = useNonBreakingSpace ? '\u00A0' : ' ';
+    return text.replaceAll(CONST.REGEX.LINE_BREAK, spaceChar).replaceAll(new RegExp(`${spaceChar}{2,}`, 'g'), spaceChar);
+}

What alternative solutions did you explore? (Optional)

Instead of modifying lineBreaksToSpaces, we could format the text specifically in formatLastMessageText in src/libs/ReportActionsUtils.ts. However, fixing it in lineBreaksToSpaces correctly ensures that any other component using this utility (like task descriptions, thread previews, etc.) also benefits from proper spacing when displaying multi-line text on a single line.

[KJ21-ENG]

Differentiation note. This proposal agrees with @MobileMage on the file and the function, but proposes a strictly narrower regex-level fix that avoids a silent side effect on pre-existing user whitespace, and explicitly addresses why @MelvinBot's <p>/<div>-stripping hypothesis does not apply to this issue's reproduction path.

Proposal

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

When a user sends a chat message containing multiple consecutive blank lines (e.g. Line 1\n\n\n\n\nLine 2\n\n\n\n\nLine 3), the LHN preview renders the lines run together with multiple consecutive spaces between them instead of a single separating space. The text is still readable but looks visually broken, wastes the preview's character budget, and deviates from the behavior agreed on in #32497 where each line should be separated by exactly one space.

What is the root cause of that problem?

The LHN preview pipeline for a chat action runs the message HTML through Parser.htmlToText and then through StringUtils.lineBreaksToSpaces, which is consumed by formatLastMessageText for the LHN preview.

Chain for the repro:

1. Composer writes <br /> per newline. The composer uses ExpensiMark, which replaces each typed \n with <br /> (ExpensiMark.js:441). So five consecutive blank lines in the composer become five consecutive <br /> tags in the stored message.html.
2. htmlToText converts each <br /> back to \n. ExpensiMark.js:690 matches <br[^>]*> and replaces each occurrence with a newline character. After this step the text is Line 1\n\n\n\n\nLine 2\n\n\n\n\nLine 3.
3. lineBreaksToSpaces replaces each newline with exactly one space. The regex is CONST.REGEX.LINE_BREAK = /\r\n|\r|\n|\u2028/g — it matches a single line-break token per capture, and the replacement is a single space. Five consecutive \ns therefore become five consecutive ' 's. That is what the LHN ends up displaying.
4. formatLastMessageText truncates to LAST_MESSAGE_TEXT_MAX_LENGTH and trims, but does not collapse the run of internal spaces — so the user sees "Line 1 Line 2 Line 3" in the LHN.

The fix from #32497 / PR #33217 correctly turned <br /> into \n and then \n into a space for the single-blank-line case, but it used a one-to-one replacement and never addressed the consecutive-linebreak case. This issue is the consecutive-linebreak edge case of that fix.

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

Change the regex used by lineBreaksToSpaces so that it matches runs of one-or-more consecutive line-break tokens and replaces each run with a single space, rather than matching individual tokens and replacing each one. Concretely, in src/libs/StringUtils/index.ts, replace the existing implementation of lineBreaksToSpaces with a version that uses a run-matching regex:

-function lineBreaksToSpaces(text = '', useNonBreakingSpace = false) {
-    return text.replaceAll(CONST.REGEX.LINE_BREAK, useNonBreakingSpace ? '\u00A0' : ' ');
-}
+function lineBreaksToSpaces(text = '', useNonBreakingSpace = false) {
+    return text.replaceAll(CONST.REGEX.CONSECUTIVE_LINE_BREAKS, useNonBreakingSpace ? '\u00A0' : ' ');
+}

And in src/CONST/index.ts add a companion regex next to the existing LINE_BREAK entry (around L4413):

     LINE_BREAK: /\r\n|\r|\n|\u2028/g,
+    CONSECUTIVE_LINE_BREAKS: /(?:\r\n|\r|\n|\u2028)+/g,

Why this shape rather than MobileMage's "replace then collapse doubled spaces" approach: the run-match regex leaves pre-existing whitespace in the source text completely untouched. With MobileMage's .replaceAll(spaceChar{2,}, spaceChar) second pass, a user-typed "Hello World" (two literal spaces) would silently become "Hello World" — the function would be quietly normalizing general whitespace in addition to doing its advertised "line breaks to spaces" job. The run-match regex gives the same visible result for every test case in this issue's repro, only one pass instead of two, and zero side effects on characters that were never line breaks.

The existing LINE_BREAK constant is left in place because it is also consumed outside this function (for instance it is used directly in other text-processing paths), and its semantics for those callers are the correct 1:1 semantics.

Downstream impact. lineBreaksToSpaces is consumed by 12 call sites (formatLastMessageText, DisplayNames, MergeTransactionUtils.buildComparisonItems, SearchUIUtils.getTaskHeaderItem, TransactionPreviewUtils.getTransactionDisplayItems, TransactionPreviewContent, the four Search input / autocomplete helpers, and the task-description path in the merge flow). All twelve consumers use it to produce a single-line display string — none of them depend on a 1:1 line-break → space mapping, so the collapse-at-source fix is a strict improvement for every consumer. It also reclaims characters inside the LAST_MESSAGE_TEXT_MAX_LENGTH budget of formatLastMessageText, so LHN previews of long multi-paragraph messages will show slightly more meaningful content.

Scope boundaries. Files touched: src/libs/StringUtils/index.ts (one function body change) and src/CONST/index.ts (one new regex constant added next to LINE_BREAK). Not touched: expensify-common, ExpensiMark, Parser.htmlToText, formatLastMessageText, or any of the twelve call sites (their behavior improves transparently). No API contracts change. Platforms: all (web, native, mWeb, desktop) via shared StringUtils.

What alternative solutions did you explore? (Optional)

• MobileMage's "replace then collapse doubled spaces" approach (comment). Rejected because the second .replaceAll(spaceChar{2,}, spaceChar) pass silently collapses pre-existing user whitespace that was never a line break — a real semantic leak for a function that advertises a narrow job. The collapse-at-source regex gives the same observable result on this issue's repro while keeping the function's scope exactly what its name says.
• Collapse consecutive whitespace inside formatLastMessageText (@MelvinBot's defense-in-depth suggestion). Rejected for the same reason — /\s{2,}/g → ' ' inside the LHN-specific helper would silently normalize any user-typed run of spaces into a single space in the preview. Also narrower: it only fixes the LHN preview and leaves the other 11 consumers broken.
• Fix expensify-common's htmlToText to handle <p>/<div> as block elements (@MelvinBot's primary suggestion). This is a real adjacent bug — htmlToTextRules does handle <br>, <blockquote>, <h1>, and <pre> but strips other block elements without inserting whitespace — but it is not the cause of this issue's repro. The composer path emits <br /> per newline (not <p>), so the bug reproduces without any <p> or <div> ever entering the pipeline. MelvinBot's scenario would affect paste-from-external-HTML or OldDot-cross-origin content, which is a different code path and a different reproduction. Recommend filing that observation as a separate expensify-common issue rather than bundling it here.
• Always use htmlToTextWithStripTags with newline-producing replacements for block tags. Same as above — a real but orthogonal refactor with broader blast radius.

[github-actions]

⚠️ @KJ21-ENG 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.

[KJ21-ENG]

@ProposalPolice this proposal is not a duplicate of @MobileMage's proposal. Both proposals target the same file (src/libs/StringUtils/index.ts) and the same function (lineBreaksToSpaces), but they propose different code that has different observable behavior on non-hypothetical input:

1. Different regex shape. MobileMage's fix keeps the existing CONST.REGEX.LINE_BREAK (/\r\n|\r|\n|\u2028/g) and adds a second .replaceAll(new RegExp(spaceChar{2,}, 'g'), spaceChar) pass that operates on spaces, not line breaks. My fix introduces a new CONST.REGEX.CONSECUTIVE_LINE_BREAKS (/(?:\r\n|\r|\n|\u2028)+/g) that matches runs of line breaks in a single pass, and leaves the existing LINE_BREAK constant untouched for its other callers.

2. Different side-effect profile — this is the load-bearing difference. MobileMage's second pass silently collapses any pre-existing run of spaces in the source text. A user who types "Hello World" with two literal spaces will have those normalized to "Hello World" in the LHN preview. My run-match regex touches only characters that were line breaks; pre-existing whitespace is left untouched. This is a real behavioral difference on real user input, not a stylistic preference.

3. Different files modified. MobileMage's diff only touches src/libs/StringUtils/index.ts. Mine touches that file and adds a new CONSECUTIVE_LINE_BREAKS constant next to LINE_BREAK in src/CONST/index.ts:4413.

4. Different analysis scope. My proposal enumerates all twelve lineBreaksToSpaces call sites (formatLastMessageText, DisplayNames, MergeTransactionUtils, SearchUIUtils, TransactionPreviewUtils, TransactionPreviewContent, four Search input / autocomplete helpers) and verifies that every consumer benefits from the collapse-at-source fix. MobileMage's proposal does not address any caller beyond the LHN preview, so the cascading behavior on DisplayNames, SearchUIUtils.getTaskHeaderItem, and the merge-transaction preview is left unexamined.

5. Different treatment of MelvinBot's proposal. My proposal explicitly evaluates @MelvinBot's <p>/<div>-stripping hypothesis against the actual composer pipeline (ExpensiMark.js:441 and :690), shows why it is an adjacent but unrelated bug, and recommends filing it separately rather than bundling. MobileMage's proposal does not address MelvinBot at all.

Please review and restore.

[wildan-m]

Proposal

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

When a chat message contains several blank lines between paragraphs (for example three paragraphs separated by six empty lines each), the LHN preview for that report shows the text with a large gap between paragraphs instead of a single space separator. The expected behavior is that the LHN preview collapses the message onto one line with each paragraph separated by exactly one space.

What is the root cause of that problem?

formatLastMessageText passes the trimmed message through StringUtils.lineBreaksToSpaces before truncating it for the LHN preview:

App/src/libs/ReportActionsUtils.ts

Lines 1469 to 1482 in 1d7d446

	function formatLastMessageText(lastMessageText: string | undefined) {
	const trimmedMessage = String(lastMessageText).trim();
	// Add support for inline code containing only space characters
	// The message will appear as a blank space in the LHN
	if (
	(trimmedMessage === '' && (lastMessageText?.length ?? 0) > 0) ||
	(trimmedMessage === '?\u2026' && (lastMessageText?.length ?? 0) > CONST.REPORT.MIN_LENGTH_LAST_MESSAGE_WITH_ELLIPSIS)
	) {
	return ' ';
	}
	return StringUtils.lineBreaksToSpaces(trimmedMessage).substring(0, CONST.REPORT.LAST_MESSAGE_TEXT_MAX_LENGTH).trim();
	}

The preview text is produced upstream by Parser.htmlToText, which emits one \n for every <br /> the composer originally stored. A message typed with several blank lines between paragraphs reaches lineBreaksToSpaces as something like "Line 1\n\n\n\n\n\n\nLine 2\n\n\n\n\n\n\nLine 3" — a run of line-break characters between each paragraph, not a single separator.

lineBreaksToSpaces treats every line-break character as an independent unit:

App/src/libs/StringUtils/index.ts

Lines 123 to 128 in 1d7d446

	/**
	* Replace all line breaks with white spaces
	*/
	function lineBreaksToSpaces(text = '', useNonBreakingSpace = false) {
	return text.replaceAll(CONST.REGEX.LINE_BREAK, useNonBreakingSpace ? '\u00A0' : ' ');
	}

The regex CONST.REGEX.LINE_BREAK matches exactly one line break at a time:

App/src/CONST/index.ts

Lines 4442 to 4443 in 1d7d446

	AFTER_FIRST_LINE_BREAK: /\n.*/g,
	LINE_BREAK: /\r\n|\r|\n|\u2028/g,

So each \n in the run is replaced one-by-one with its own space, and a run of seven newlines becomes a run of seven spaces. The subsequent .substring(...).trim() in formatLastMessageText only trims leading/trailing whitespace, so the internal runs of spaces survive and the LHN renders the preview with visible gaps between paragraphs. The same issue manifests in every other caller that funnels rendered chat text through lineBreaksToSpaces before display (task descriptions, workspace/room description change messages, transaction comments in search previews, thread subtitles).

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

Change lineBreaksToSpaces so that the substitution treats a run of one or more consecutive line-break characters as a single unit and replaces the whole run with exactly one space (or one non-breaking space, when requested). In practice this means matching one-or-more line break characters in a single regex pass and emitting a single separator character for each matched run, instead of replacing each line break individually and then leaving adjacent spaces behind in the output.

This fix has three important properties that motivate doing it at this specific layer rather than higher up:

1. It is confined to the function that is actually responsible for the mapping — the function name already advertises "line breaks to spaces", and today's implementation accidentally turns one line break into one space regardless of what came before or after. Treating runs as units matches the function's intent and name.
2. It does not alter any pre-existing runs of literal space characters that the caller passes in. Several callers feed user-supplied text through lineBreaksToSpaces without any prior whitespace normalization — for example the search bar's singleLineUserQuery path, which passes raw query text with useNonBreakingSpace=true, and TransactionPreviewUtils.getPreviewDescription which passes transaction comments directly. A user who intentionally typed "foo bar" with two spaces into a search query or transaction comment must still see "foo bar" afterwards. A fix that collapses the final output as a post-processing step (e.g. running a second regex over the result to squash all runs of 2+ spaces into one) would silently damage those callers, because it cannot distinguish "space that came from a line break" from "space the user typed". Fixing the substitution at the point where the line breaks are consumed avoids that entire class of collateral damage.
3. It leaves every other call site of the LINE_BREAK regex untouched, so there is no blast radius beyond lineBreaksToSpaces itself.

The unit test for lineBreaksToSpaces should cover four cases to lock the behavior down: a single \n still produces a single space; a run of consecutive \n produces exactly one space; mixed CRLF/CR/\u2028 sequences collapse as one run; and a pre-existing run of regular spaces in the input is preserved unchanged. I will add these to tests/unit/StringUtilsTest.ts alongside the fix.

Compare branch:

https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/87980-collapse-linebreak-runs?expand=1

What alternative solutions did you explore? (Optional)

I considered widening CONST.REGEX.LINE_BREAK itself from "one line break" to "one or more line breaks". The only other consumer of that constant today is ReportUtils.ts:3246, which replaces matches with the empty string — so collapsing runs there is a no-op, which means the global change would be safe. I still preferred the local edit inside lineBreaksToSpaces because the constant is a low-level primitive used as a tokenizer, and broadening its semantics to also mean "runs" changes what the name communicates to future readers; keeping the greedy match inside the function that actually wants a run-collapse is a cleaner separation.

I also considered normalizing the HTML at the Parser.htmlToText stage inside expensify-common so that runs of <br /> collapse before they ever reach the app. That would indeed fix this specific repro, but it would also change the text form that every other consumer of htmlToText receives (offline exports, attachments, notifications, copy-to-clipboard), and those consumers legitimately want the original paragraph structure preserved. The LHN preview is the one place where a single-line collapse is appropriate, so the fix belongs on the path that is already doing the single-line conversion.