[$250] – Android – Markdown is not applied to pasted text

[applause-bot]

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: v9.4.16-1
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/folder/13176723/test-cases/41237042
Email or phone of affected tester (no customers): sintayewhaylu01@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Android
App Component: Other

Action Performed:

1. Open the Hybrid app.
2. Copy text from a mweb expensify chat .
3. Paste the copied text into the compose box.

Expected Result:

The pasted text should be displayed with the Markdown formatting

Actual Result:

The text is pasted without the Markdown formatting being applied.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7185816_1781899120380.video_2026-06-19_22-56-56.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Nathan Lemma
Bug ID: 7185816

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/2d77b779b59faa70e292ce5bca71484d48aebc69d17eed148a670c26c665b87d

[MelvinBot]

Proposal

What is the root cause of that problem?

Pasting rich text into the compose box never gets converted to Markdown on native (Android/iOS) — that conversion is web-only.

When you copy a rendered message from an mweb Expensify chat, the clipboard's plain‑text representation no longer contains the literal Markdown markers (*bold*, _italic_); the formatting lives only in the HTML representation. Live‑markdown can only style text that contains those literal markers, so the pasted plain text comes through unstyled.

On web, the App handles this: the paste listener reads the text/html clipboard data and runs it through Parser.htmlToMarkdown(...), rebuilding the */_ syntax before inserting it, so live‑markdown styles it.

On native, that whole pipeline is missing:

• src/hooks/useHtmlPaste/index.native.ts:3 is a complete no‑op (const useHtmlPaste: UseHtmlPaste = () => {};).
• The native composer's only paste handler, src/components/Composer/implementation/index.native.tsx:97-114, early‑returns for text/plain and otherwise treats the clipboard item as a file — it never reads text/html or calls htmlToMarkdown.

So pasted text is inserted verbatim with no markers, and the live‑markdown engine (which does re‑parse pasted text — confirmed in the library's Android MarkdownTextWatcher) has nothing to style. This is why typed *bold* styles but pasted formatted text does not, and why it reproduces on native only.

Supporting evidence & data flow

• Web conversion (works): src/hooks/useHtmlPaste/index.ts:94-99 — handlePastedHTML → paste(Parser.htmlToMarkdown(html, {})); routed from the text/html branch at index.ts:147-167.
• Web composer wires the hook: src/components/Composer/implementation/index.tsx:277.
• Live‑markdown re‑parses pasted text on Android (node_modules/@expensify/react-native-live-markdown MarkdownTextWatcher.afterTextChanged → applyMarkdownFormatting), so the gap is the missing HTML→Markdown step, not the styling engine. Installed version: 0.1.327.

Flow: copy rendered mweb message → clipboard text/plain has no *_ markers → native pastes raw text (no htmlToMarkdown) → live‑markdown finds no markers → no styling.

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

Bring HTML‑aware paste to the native composer, mirroring what web already does:

1. Implement useHtmlPaste/index.native.ts (or extend the native composer's paste handler) so that when the clipboard contains rich/HTML content, it reads that HTML, runs it through Parser.htmlToMarkdown(...), and inserts the resulting Markdown syntax — reusing the same Parser already used on web.
2. Reading HTML from the Android/iOS clipboard isn't exposed by the current text‑only paste path, so this likely requires reading the rich clipboard data via the native paste event / live‑markdown's paste hook (iOS already has textInputDidPaste; Android has no paste hook today). Keep the existing text/plain early‑return as the fallback when no HTML is present.

This keeps behavior consistent with web and reuses the existing ExpensiMark/Parser conversion rather than introducing a new one.

What alternative solutions did you explore? (Optional)

• Fix the copy side instead: write Markdown syntax into the clipboard's plain‑text representation when copying a message, so any paste target receives *bold*. Simpler to reason about but changes copy semantics app‑wide (affects pasting into non‑Expensify apps too).

---

Confidence: High on root cause (deterministic, code‑level platform gap). Medium on the exact fix — accessing rich clipboard HTML on Android may need a native‑module/library change in @expensify/react-native-live-markdown; if so, that portion lives outside the App repo and would need an internal engineer with access.

---

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

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-20 18:21:46 UTC.

Proposal

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

When a user copies a formatted message from an Expensify chat (e.g. on mWeb) and pastes it into the compose box of the Android app, the markdown formatting is lost. The pasted content arrives as flat, unstyled plain text instead of carrying the original *bold* / _italic_ / quote markdown that the composer would render. On web this works correctly because the web composer converts the clipboard's HTML back into markdown, but the native Android composer never does that conversion.

What is the root cause of that problem?

The bug is a mismatch between what the copy path writes to the clipboard and what the native paste path reads back. On the copy side, setClipboardMessage in ContextMenuActions writes two representations to the clipboard whenever the platform supports HTML (which mWeb Chrome does): the rich text/html blob, and a text/plain blob produced by getClipboardText. On web, getClipboardText is implemented as Parser.htmlToText(selection), which strips every formatting tag down to bare text — so the text/plain portion has no markdown syntax at all.

App/src/pages/inbox/report/ContextMenu/ContextMenuActions.tsx

Lines 249 to 253 in cc90dd2

	if (!Clipboard.canSetHtml()) {
	Clipboard.setString(clipboardText);
	} else {
	Clipboard.setHtml(strippedContent, clipboardText);
	}

The markdown-equivalent formatting therefore lives only inside the text/html representation. On the web composer this is fine: useHtmlPaste intercepts the paste event, reads text/html, and runs it through handlePastedHTML → Parser.htmlToMarkdown(html), regenerating the *bold*/_italic_ markdown before inserting. The native composer has no equivalent. Its only paste handler is pasteFile, which exists purely to catch image/file paste and bails out immediately for text:

const clipboardContent = e.nativeEvent.items.at(0);
if (clipboardContent?.type === 'text/plain') {
    return;
}

App/src/components/Composer/implementation/index.native.tsx

Lines 97 to 115 in cc90dd2

	const pasteFile = useCallback(
	(e: NativeSyntheticEvent<TextInputPasteEventData>) => {
	const clipboardContent = e.nativeEvent.items.at(0);
	if (clipboardContent?.type === 'text/plain') {
	return;
	}
	const mimeType = clipboardContent?.type ?? '';
	const fileURI = clipboardContent?.data;
	const baseFileName = fileURI?.split('/').pop() ?? 'file';
	const {fileName: stem, fileExtension: originalFileExtension} = splitExtensionFromFileName(baseFileName);
	const fileExtension = originalFileExtension || (mimeDb[mimeType].extensions?.[0] ?? 'bin');
	const fileName = `${stem}.${fileExtension}`;
	let file: FileObject = {uri: fileURI, name: fileName, type: mimeType, size: 0};
	getFileSize(file.uri ?? '')
	.then((size) => (file = {...file, size}))
	.finally(() => onPasteFile(file));
	},
	[onPasteFile],
	);

Because it returns early on text/plain, the underlying Android EditText performs the default OS paste, which inserts the clipboard's plain-text item — i.e. the markdown-stripped text. There is no htmlToMarkdown step anywhere on the native path: useHtmlPaste's native implementation is a no-op stub (const useHtmlPaste = () => {};), and the @expensify/react-native-live-markdown library does no clipboard handling of its own. So the formatting that was preserved in text/html is simply discarded on paste, and the user sees unformatted text.

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

We should give the native composer the same HTML→markdown conversion the web composer already has, applied at paste time. The clean place is the native Composer (src/components/Composer/implementation/index.native.tsx): when a paste lands and the clipboard carries an HTML representation, read the HTML, convert it with the existing Parser.htmlToMarkdown helper, and insert that markdown at the cursor instead of letting the OS insert the stripped plain text. The conversion helper is already battle-tested on web, so we reuse it rather than writing new parsing logic:

// on paste, when clipboard has html
const markdown = Parser.htmlToMarkdown(htmlFromClipboard);
// insert `markdown` at the current selection, then preventDefault the OS plain-text paste

The wrinkle is that React Native's onPaste only fires for non-text MIME items and @react-native-clipboard/clipboard exposes only getString() (plain text), getImage*, and has* checks — it has no API to read text/html. Android ClipData.Item does carry HTML via getHtmlText(), so the proper fix is to surface that to JS. The lowest-risk option that stays in the App repo is to extend our native Clipboard wrapper with a getHtml() that bridges ClipData.Item.coerceToHtmlText() / getHtmlText(), then in the native composer's paste flow do Clipboard.getHtml() and, if non-empty, insert Parser.htmlToMarkdown(html) and suppress the default paste. This keeps the change scoped to native paste only — web is untouched, the file-paste branch in pasteFile is untouched, and pure plain-text pastes (no text/html on the clipboard) fall through to normal OS behavior, so nothing regresses for users pasting from non-Expensify sources.

What alternative solutions did you explore? (Optional)

The other end of the fix would be to make the copy path write markdown into text/plain (i.e. use Parser.htmlToMarkdown instead of htmlToText in the web getClipboardText), so the plain text the native app pastes is already markdown. We rejected this because it changes what every consumer pastes everywhere (including non-Expensify targets and OldDot), turning clean copied text into raw *asterisk* syntax — a much broader, more disruptive change than fixing the paste side where the bug actually manifests.

[ahmdshrif]

Proposal

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

On Android, copying formatted text from a chat and pasting it into the compose box drops the Markdown — the text lands plain instead of styled.

What is the root cause of that problem?

HTML→Markdown paste conversion only exists on web; native never gets the chance to run it.

1. On web the composer wires useHtmlPaste, which reads the clipboard's text/html and runs Parser.htmlToMarkdown before inserting, so pasted rich text becomes Markdown source the live-markdown input then styles.

   App/src/components/Composer/implementation/index.tsx

   Lines 141 to 143 in cc90dd2

   	* Otherwise, convert pasted HTML to Markdown and set it on the composer.
   	*/
   	const handlePaste = useCallback(

   and

   App/src/hooks/useHtmlPaste/index.ts

   Line 96 in cc90dd2

   paste(Parser.htmlToMarkdown(html, {}));

2. The native useHtmlPaste is a no-op stub — there is no native HTML paste path at all.

   App/src/hooks/useHtmlPaste/index.native.ts

   Lines 1 to 4 in cc90dd2

   	import type UseHtmlPaste from './types';
   	const useHtmlPaste: UseHtmlPaste = () => {};
   	export default useHtmlPaste;

3. The native composer's only paste handler, pasteFile, handles images/files and early-returns on text/plain, doing nothing with the content.

   App/src/components/Composer/implementation/index.native.tsx

   Lines 97 to 139 in cc90dd2

   	const pasteFile = useCallback(
   	(e: NativeSyntheticEvent<TextInputPasteEventData>) => {
   	const clipboardContent = e.nativeEvent.items.at(0);
   	if (clipboardContent?.type === 'text/plain') {
   	return;
   	}
   	const mimeType = clipboardContent?.type ?? '';
   	const fileURI = clipboardContent?.data;
   	const baseFileName = fileURI?.split('/').pop() ?? 'file';
   	const {fileName: stem, fileExtension: originalFileExtension} = splitExtensionFromFileName(baseFileName);
   	const fileExtension = originalFileExtension || (mimeDb[mimeType].extensions?.[0] ?? 'bin');
   	const fileName = `${stem}.${fileExtension}`;
   	let file: FileObject = {uri: fileURI, name: fileName, type: mimeType, size: 0};
   	getFileSize(file.uri ?? '')
   	.then((size) => (file = {...file, size}))
   	.finally(() => onPasteFile(file));
   	},
   	[onPasteFile],
   	);
   	const maxHeightStyle = useMemo(
   	() => StyleUtils.getComposerMaxHeightStyle(isInLandscapeMode ? CONST.COMPOSER.MAX_LINES_LANDSCAPE_MODE : maxLines, isComposerFullSize),
   	[StyleUtils, isComposerFullSize, maxLines, isInLandscapeMode],
   	);
   	const composerStyle = useMemo(() => StyleSheet.flatten([style, textContainsOnlyEmojis ? styles.onlyEmojisTextLineHeight : {}]), [style, textContainsOnlyEmojis, styles]);
   	return (
   	<RNMarkdownTextInput
   	id={CONST.COMPOSER.NATIVE_ID}
   	multiline
   	autoComplete="off"
   	placeholderTextColor={theme.placeholderText}
   	ref={setTextInputRef}
   	value={value}
   	rejectResponderTermination={false}
   	smartInsertDelete={false}
   	textAlignVertical="center"
   	style={[composerStyle, maxHeightStyle]}
   	markdownStyle={markdownStyle}
   	{...props}
   	autoFocus={isInLandscapeMode ? false : props.autoFocus}
   	readOnly={isDisabled}
   	onPaste={pasteFile}

4. The underlying RN paste patch forwards only text/plain (plus image URIs) to JS, and Android additionally remaps paste → pasteAsPlainText, so the clipboard's text/html is discarded before JS sees it and the OS inserts the rendered, markdown-stripped text. https://github.com/Expensify/App/blob/cc90dd2dd512e525f69350c293e44d36dd8d5250/patches/react-native/react-native%2B0.83.1%2B011%2BAdd-onPaste-to-TextInput.patch

So the Markdown markers are gone because the rich representation is never converted — typed Markdown still styles (decorator runs on every change), which is why only pasting is affected.

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

Give native the same HTML→Markdown path web has:

1. In the RN paste patch, when the clip has text/html, forward it (item.coerceToHtmlText() on Android; the html pasteboard type on iOS) as a text/html item and suppress the default plain insert.
2. In pasteFile, replace the text/plain early-return with a text/html branch that runs Parser.htmlToMarkdown(data) and inserts the result at the caret — mirroring web handlePaste.

Regression-safe: the image/file branch and plain-text-only pastes are untouched; we only add an html branch, so non-Markdown pastes behave exactly as before.

What alternative solutions did you explore? (Optional)

• JS-only fix in pasteFile (the obvious spot-fix): impossible — native onPaste never delivers text/html, so there is nothing to convert without the native patch change. It would silently no-op.
• Implement the conversion inside useHtmlPaste/index.native.ts and wire it into the native composer for clean web/native symmetry, instead of inlining in pasteFile. Still requires the native html-forwarding change above.

[lorretheboy]

Note: Not duplicated as MobileMage's proposal posted before Help Wanted label -- Thus, MobileMage's proposal is invalid according to our rules

Proposal

What is the root cause of that problem?

Copying from an mWeb chat runs the web copy path. The text/plain entry it writes to the clipboard is built with Parser.htmlToText, which strips all markdown syntax — the markdown only survives in the text/html entry:

App/src/libs/Clipboard/getClipboardText/index.ts

Lines 3 to 5 in cc90dd2

	export default function getClipboardText(selection: string): string {
	return Parser.htmlToText(selection);
	}

On web that is fine, because pasting reconstructs markdown from the text/html entry via useHtmlPaste (handlePastedHTML → Parser.htmlToMarkdown):

App/src/hooks/useHtmlPaste/index.ts

Lines 94 to 99 in cc90dd2

	const handlePastedHTML = useCallback(
	(html: string) => {
	paste(Parser.htmlToMarkdown(html, {}));
	},
	[paste],
	);

But the native Android app has no equivalent. useHtmlPaste is an empty no-op on native:

App/src/hooks/useHtmlPaste/index.native.ts

Lines 1 to 4 in cc90dd2

	import type UseHtmlPaste from './types';
	const useHtmlPaste: UseHtmlPaste = () => {};
	export default useHtmlPaste;

And the native Composer's paste handler only deals with file/image items — for text/plain it returns early and lets the OS insert the raw clipboard text:

App/src/components/Composer/implementation/index.native.tsx

Lines 97 to 115 in cc90dd2

	const pasteFile = useCallback(
	(e: NativeSyntheticEvent<TextInputPasteEventData>) => {
	const clipboardContent = e.nativeEvent.items.at(0);
	if (clipboardContent?.type === 'text/plain') {
	return;
	}
	const mimeType = clipboardContent?.type ?? '';
	const fileURI = clipboardContent?.data;
	const baseFileName = fileURI?.split('/').pop() ?? 'file';
	const {fileName: stem, fileExtension: originalFileExtension} = splitExtensionFromFileName(baseFileName);
	const fileExtension = originalFileExtension || (mimeDb[mimeType].extensions?.[0] ?? 'bin');
	const fileName = `${stem}.${fileExtension}`;
	let file: FileObject = {uri: fileURI, name: fileName, type: mimeType, size: 0};
	getFileSize(file.uri ?? '')
	.then((size) => (file = {...file, size}))
	.finally(() => onPasteFile(file));
	},
	[onPasteFile],
	);

So the only thing native can insert is the markdown-stripped plain text → the pasted text has no formatting. (Native-to-native copy works because the native getClipboardText uses htmlToMarkdown, so its plain-text entry already carries markdown.)

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

Give the native paste path the same HTML→markdown step that web has. In the native Composer paste handler, when the clipboard contains HTML, read it and insert Parser.htmlToMarkdown(html) rather than returning early and letting the OS paste the stripped text/plain:

App/src/components/Composer/implementation/index.native.tsx

Lines 97 to 115 in cc90dd2

	const pasteFile = useCallback(
	(e: NativeSyntheticEvent<TextInputPasteEventData>) => {
	const clipboardContent = e.nativeEvent.items.at(0);
	if (clipboardContent?.type === 'text/plain') {
	return;
	}
	const mimeType = clipboardContent?.type ?? '';
	const fileURI = clipboardContent?.data;
	const baseFileName = fileURI?.split('/').pop() ?? 'file';
	const {fileName: stem, fileExtension: originalFileExtension} = splitExtensionFromFileName(baseFileName);
	const fileExtension = originalFileExtension || (mimeDb[mimeType].extensions?.[0] ?? 'bin');
	const fileName = `${stem}.${fileExtension}`;
	let file: FileObject = {uri: fileURI, name: fileName, type: mimeType, size: 0};
	getFileSize(file.uri ?? '')
	.then((size) => (file = {...file, size}))
	.finally(() => onPasteFile(file));
	},
	[onPasteFile],
	);

This reuses the exact convergence point web already relies on (Parser.htmlToMarkdown), so cross-platform paste produces the same markdown source the live-markdown input then formats.

What alternative solutions did you explore? (Optional)

Align the web getClipboardText with native by using Parser.htmlToMarkdown so the text/plain clipboard entry carries markdown source. Then any native plain-text paste preserves formatting with no native paste changes. Trade-off: pasting into external (non-Expensify) apps would receive markdown source instead of clean plain text.

[melvin-bot]

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

[x-dev90]

Proposal

What is the root cause of that problem?

On native platforms, copied chat HTML is converted to plain text before being written to the clipboard.

Both the message context-menu copy flow and selection-copy helper call getClipboardText(selection) before writing clipboard content:

• setClipboardMessage() converts the report action HTML before Clipboard.setString() / Clipboard.setHtml():

  App/src/pages/inbox/report/ContextMenu/ContextMenuActions.tsx

  Lines 242 to 253 in cc90dd2

  	/** Sets the HTML string to Clipboard */
  	function setClipboardMessage(content: string | undefined) {
  	const strippedContent = stripFollowupListFromHtml(content);
  	if (!strippedContent) {
  	return;
  	}
  	const clipboardText = getClipboardText(strippedContent);
  	if (!Clipboard.canSetHtml()) {
  	Clipboard.setString(clipboardText);
  	} else {
  	Clipboard.setHtml(strippedContent, clipboardText);
  	}

• copySelectionToClipboard() does the same for selected rendered chat content:

  App/src/hooks/useCopySelectionHelper.ts

  Lines 7 to 17 in cc90dd2

  	function copySelectionToClipboard() {
  	const selection = SelectionScraper.getCurrentSelection();
  	if (!selection) {
  	return;
  	}
  	const clipboardText = getClipboardText(selection);
  	if (!Clipboard.canSetHtml()) {
  	Clipboard.setString(clipboardText);
  	return;
  	}
  	Clipboard.setHtml(selection, clipboardText);

The web implementation converts selected HTML to markdown, so the plain-text clipboard value still contains markdown markers:

App/src/libs/Clipboard/getClipboardText/index.ts

Lines 1 to 5 in cc90dd2

	import Parser from '@libs/Parser';
	export default function getClipboardText(selection: string): string {
	return Parser.htmlToText(selection);
	}

The native implementation converts the same selected HTML to plain text instead:

App/src/libs/Clipboard/getClipboardText/index.native.ts

Lines 1 to 5 in cc90dd2

	import Parser from '@libs/Parser';
	export default function getClipboardText(selection: string): string {
	return Parser.htmlToMarkdown(selection);
	}

Android cannot use the App web clipboard HTML path because native Clipboard.setHtml() is a noop, so the composer receives only the plain text value. Since the native composer’s live markdown styling is driven by markdown syntax in the input value, pasted copied text has no markdown markers left to render.

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

Use Parser.htmlToMarkdown() in src/libs/Clipboard/getClipboardText/index.native.ts, matching the web implementation.

Required change:

• Replace Parser.htmlToText(selection) with Parser.htmlToMarkdown(selection) in the native clipboard text helper.

Tests that should be added:

• Add a small unit test for the native getClipboardText helper verifying that copied rendered HTML such as bold, italic, links, lists, and line breaks is converted to markdown instead of plain text.

I also considered handling this in the native composer paste event, but that would be the wrong boundary. By the time Android pastes into the composer, the clipboard already contains plain text. The root fix is to preserve markdown when App writes copied chat content to the native clipboard.

What alternative solutions did you explore? (Optional)

[melvin-bot]

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