[Due for payment 2026-07-28] [$250] Expense - Export system message cannot be selected by clicking and dragging

[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: 9.4.28-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: #92142
Email or phone of affected tester (no customers): sdjoisjdnojsodjiosjo@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Workspace is connected to Sage Intacct.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create an expense.
4. Open the report.
5. Click Submit, Approve and Mark as paid.
6. Click More > Export > Mark as exported.
7. Try to select export system message by clicking and dragging.

Expected Result:

Export system message can be selected by clicking and dragging.

Actual Result:

Export system message cannot be selected by clicking and dragging.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7201040_1783361950727.4.1.mp4

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7201040

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022074204959729888287
• Upwork Job ID: 2074204959729888287
• Last Price Increase: 2026-07-06

Issue Owner

Current Issue Owner: @ahmedGaber93

[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/d24aff4b4de1c12a2af05355b0477e84033c0456aad6456c4b9fc44fd8d22b24

[MelvinBot]

Proposal

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

The export system message (e.g. "…marked as manually exported to Sage Intacct" shown after More > Export > Mark as exported) cannot be selected by clicking and dragging on desktop web, even though other system/violation messages now can.

What is the root cause of that problem?

This is a follow-up gap from Expensify/App#92142 (merged today), which made system/violation messages selectable but did not touch the export renderer.

The export message is rendered by ExportIntegration, not by the two renderers that PR #92142 patched. The ordinary "Mark as exported" action has no reasoning, so it falls through hasReasoning() into the fragment branch, which renders plain <Text style={[styles.chatItemMessage, styles.colorMuted]}> with no styles.userSelectText. Since every report action is wrapped in a pressable that applies user-select: none, this text inherits non-selectable behavior on desktop web.

Evidence

• Renderer: ExportIntegration.tsx:53-58 — plain <Text> in the no-reasoning fragment branch, missing userSelectText.
• The hasReasoning branch ExportIntegration.tsx:34-44 delegates to ReportActionItemMessageWithExplain, which PR Make system/violation messages text-selectable on desktop web #92142 already made selectable — but the standard "Mark as exported" flow doesn't set reasoning, so it never hits that branch.
• Pattern from PR Make system/violation messages text-selectable on desktop web #92142 to mirror: ReportActionItemBasicMessage.tsx:25 applies const selectableStyle = !canUseTouchScreen() || !shouldUseNarrowLayout ? styles.userSelectText : styles.userSelectNone; to the same [styles.chatItemMessage, styles.colorMuted] text.

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

Apply the exact same conditional selectable style PR #92142 used, in src/components/ReportActionItem/ExportIntegration.tsx:

1. Add imports: useResponsiveLayout (@hooks/useResponsiveLayout) and canUseTouchScreen (@libs/DeviceCapabilities).
2. Inside the component: const {shouldUseNarrowLayout} = useResponsiveLayout(); and const selectableStyle = !canUseTouchScreen() || !shouldUseNarrowLayout ? styles.userSelectText : styles.userSelectNone;
3. Change the plain <Text> style at line 55 from [styles.chatItemMessage, styles.colorMuted] to [styles.chatItemMessage, styles.colorMuted, selectableStyle].

This preserves touch/narrow-layout behavior (no accidental selection while scrolling) and matches how every other system message is now handled. The TextLink fragments are already selectable/clickable.

What alternative solutions did you explore?

None needed — this reuses the established pattern from PR #92142 rather than introducing a new one.

Related

• Original selectability issue/PR: Expensify/App#84639 → PR #92142. This issue is the QA-execution follow-up covering the one renderer that PR missed.

---

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

[kitvasyl]

Proposal

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

On desktop web, the system message created by Mark as exported cannot be selected by clicking and dragging.

What is the root cause of that problem?

EXPORTED_TO_INTEGRATION actions are routed to ExportIntegration, rather than the generic system-message renderer fixed in #92142.

For Mark as exported, buildOptimisticExportIntegrationAction() sets markedManually without reasoning, and getExportIntegrationActionFragments() creates a non-link fragment. Consequently, ExportIntegration takes its !hasReasoning(action) branch and renders that fragment with a plain <Text> lacking any userSelect override.

The surrounding report action has accessibilityRole="button", causing BaseGenericPressable to apply styles.userSelectNone. That inherited style blocks selection. The reasoning branch works because ReportActionItemMessageWithExplain now explicitly enables desktop selection, while this special fragment branch was omitted.

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

In ExportIntegration, use the established desktop-selection condition:

const selectableStyle = !canUseTouchScreen() || !shouldUseNarrowLayout
    ? styles.userSelectText
    : styles.userSelectNone;

Apply selectableStyle to the fragment <Text> (and the fragment TextLink for consistent CSS behavior). This matches ReportActionItemBasicMessage, keeps narrow touch layouts non-selectable, and avoids changing every report-action pressable.

Add a focused regression test for manually marked export actions, then manually verify that:

• the Sage Intacct Mark as exported message can be dragged, selected, and copied on desktop Chrome;
• automatic/reasoning export messages remain selectable and their links remain clickable;
• narrow touch layouts retain their existing scrolling and context-menu behavior.

What alternative solutions did you explore? (Optional)

Removing userSelectNone from the shared report-action pressable would also expose the text, but it would make unrelated button content selectable. Re-rendering all export fragments through RenderHTML is also broader and risks changing link handling; the local style override is the smallest safe fix.

[ashu75575]

Proposal

What is the root cause of that problem?

EXPORTED_TO_INTEGRATION actions currently maintain two distinct rendering paths in ExportIntegration.tsx. When hasReasoning(action) is true, the message is converted to HTML and rendered through ReportActionItemMessageWithExplain (which leverages RenderHTML and explicitly enables text selection). However, when hasReasoning(action) is false, it falls back to a manual mapping of fragments inside a View component:

    return (
        <View style={[styles.flex1, styles.flexRow, styles.alignItemsCenter, styles.flexWrap]}>
            {fragments.map((fragment, index) => {
                if (!fragment.url) {
                    return (
                        <Text key={index} style={[styles.chatItemMessage, styles.colorMuted]}>
                            {fragment.text}{' '}
                        </Text>
                    );
                }
                return (
                    <TextLink key={index} href={fragment.url}>
                        {fragment.text}{' '}
                    </TextLink>
                );
            })}
        </View>
    );

Because these fragments are individually wrapped inside a flex View (which maps to a block-level <div>), the browser's native continuous text selection breaks. Furthermore, this manual rendering path misses the userSelectText overrides that the HTML renderer provides for desktop layouts.

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

We should eliminate the duplicate rendering paths by unconditionally delegating to ReportActionItemMessageWithExplain. Since ReportActionItemMessageWithExplain correctly checks for hasReasoning(action) internally (and gracefully handles the non-reasoning case by simply omitting the "Explain" link), we can drastically simplify ExportIntegration.tsx while simultaneously fixing the selection issue:

In src/components/ReportActionItem/ExportIntegration.tsx:

function ExportIntegration({action, originalReport}: ExportIntegrationProps) {
    const {translate} = useLocalize();
    const [childReport] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${getNonEmptyStringOnyxID(action?.childReportID)}`);

    const message = getExportIntegrationMessageHTML(translate, action);

    return (
        <ReportActionItemMessageWithExplain
            message={message}
            action={action}
            childReport={childReport}
            originalReport={originalReport}
        />
    );
}

What alternative solutions did you explore? (Optional)

The competing proposal suggests keeping the duplicate manual-rendering path and manually pulling in useResponsiveLayout to inject selectableStyle conditionally onto the Text fragments. While they claim this is the "smallest safe fix," consolidating the rendering through ReportActionItemMessageWithExplain is architecturally superior.

The hasReasoning path already safely relies on RenderHTML to correctly render the identical messages (and handle their links). Standardizing around this unified rendering path deletes ~25 lines of redundant presentation logic, completely resolves the DOM wrapping selection bugs natively, and ensures that any future text rendering capabilities (like selection, theming, or emoji parsing) are applied uniformly across all export messages.

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-06 18:53:45 UTC.

Proposal

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

After marking a report as manually exported (More > Export > Mark as exported), the resulting "marked this report as manually exported to Sage Intacct" system message cannot be text-selected by clicking and dragging on desktop web, while other system messages can.

What is the root cause of that problem?

The structural cause: every report action must explicitly opt back in to text selection, and the export message renderer is the one system-message renderer that PR #92142 (the PR this QA regression test came from) did not patch.

The full chain:

1. Every report action row is wrapped in PressableWithSecondaryInteraction —

   App/src/pages/inbox/report/ReportActionItem.tsx

   Line 515 in 7ebf80b

   <PressableWithSecondaryInteraction

   — with accessibilityRole=BUTTON on non-Safari browsers:

   App/src/pages/inbox/report/ReportActionItem.tsx

   Line 535 in 7ebf80b

   accessibilityRole={isSafari() && hasHoverSupport() ? undefined : CONST.ROLE.BUTTON}

   (this is why the repro is on Chrome; Safari-with-hover gets undefined).

2. BaseGenericPressable applies styles.userSelectNone (user-select: none) whenever the role is BUTTON, and it cascades to every child:

   App/src/components/Pressable/GenericPressable/implementation/BaseGenericPressable.tsx

   Line 200 in 7ebf80b

   isRoleButton && styles.userSelectNone,

3. Children must therefore explicitly apply styles.userSelectText to be selectable. PR #92142 did exactly that for the other system-message renderers — ReportActionItemBasicMessage (

   App/src/pages/inbox/report/ReportActionItemBasicMessage.tsx

   Line 25 in 7ebf80b

   const selectableStyle = !canUseTouchScreen() || !shouldUseNarrowLayout ? styles.userSelectText : styles.userSelectNone;

   ), ReportActionItemMessageWithExplain, TaskAction (

   App/src/components/ReportActionItem/TaskAction.tsx

   Lines 28 to 29 in 7ebf80b

   	const isSelectable = !canUseTouchScreen() || !shouldUseNarrowLayout;
   	const selectableStyle = isSelectable ? styles.userSelectText : styles.userSelectNone;

   ), and InlineSystemMessage — but not for ExportIntegration.

4. ExportIntegration (rendered for EXPORTED_TO_INTEGRATION actions from

   App/src/pages/inbox/report/actionContents/ActionContentRouter.tsx

   Line 440 in 7ebf80b

   <ExportIntegration

   ) has two branches. The hasReasoning(action) branch delegates to the already-patched ReportActionItemMessageWithExplain and is selectable:

   App/src/components/ReportActionItem/ExportIntegration.tsx

   Lines 34 to 44 in 7ebf80b

   	if (hasReasoning(action)) {
   	const message = getExportIntegrationMessageHTML(translate, action);
   	return (
   	<ReportActionItemMessageWithExplain
   	message={message}
   	action={action}
   	childReport={childReport}
   	originalReport={originalReport}
   	/>
   	);
   	}

   . The plain-fragments branch renders its own <Text> (

   App/src/components/ReportActionItem/ExportIntegration.tsx

   Lines 53 to 58 in 7ebf80b

   	<Text
   	key={index}
   	style={[styles.chatItemMessage, styles.colorMuted]}
   	>
   	{fragment.text}{' '}
   	</Text>

   ) and <TextLink> (

   App/src/components/ReportActionItem/ExportIntegration.tsx

   Lines 62 to 69 in 7ebf80b

   	return (
   	<TextLink
   	key={index}
   	href={fragment.url}
   	>
   	{fragment.text}{' '}
   	</TextLink>
   	);

   ) with no user-select override, so both inherit user-select: none from step 2.

5. Substituting the repro: "Mark as exported" creates an action whose originalMessage has markedManually: true and no reasoning, so hasReasoning (

   App/src/libs/ReportActionsUtils.ts

   Lines 4738 to 4741 in 7ebf80b

   	function hasReasoning(action: OnyxInputOrEntry<ReportAction>): boolean {
   	const originalMessage = getOriginalMessage(action);
   	return !!originalMessage && typeof originalMessage === 'object' && 'reasoning' in originalMessage && !!originalMessage.reasoning;
   	}

   ) returns false and rendering takes the unpatched fragments branch, hitting the markedManually case of getExportIntegrationActionFragments:

   App/src/libs/ReportActionsUtils.ts

   Lines 2727 to 2731 in 7ebf80b

   	} else if (markedManually) {
   	result.push({
   	text: translate('report.actions.type.exportedToIntegration.manual', label),
   	url: '',
   	});

This explains every symptom detail: only the export message is affected (all sibling renderers were patched in #92142), on desktop Chrome (role=BUTTON applies there), for the manual-export repro (no reasoning, so the patched WithExplain path is bypassed).

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

Apply the exact selectable-style pattern PR #92142 established, to ExportIntegration.tsx, on both fragment types:

const {shouldUseNarrowLayout} = useResponsiveLayout();
const selectableStyle = !canUseTouchScreen() || !shouldUseNarrowLayout ? styles.userSelectText : styles.userSelectNone;
// plain fragment:
<Text style={[styles.chatItemMessage, styles.colorMuted, selectableStyle]}>
// link fragment:
<TextLink style={selectableStyle} href={fragment.url}>

This covers every message variant produced by getExportIntegrationActionFragments: pending, markedManually (this repro), automatic, automaticAction (which includes a help-doc TextLink), and the reimbursable / non-reimbursable / travel-invoicing report links. The hasReasoning branch is already covered via ReportActionItemMessageWithExplain.

Regression safety in one sentence: the change is an additive style on one leaf renderer — touch and narrow layouts keep userSelectNone exactly as #92142 intended (no accidental selection while scrolling), and no shared component or util changes.

Why the obvious spot-fix does not work: adding styles.userSelectText only to the <Text> branch fixes this exact repro but leaves every <TextLink> fragment inside the same user-select: none subtree — automatic-export messages and "exported to X" report links would remain unselectable and fail the same QA test on the next export variant. Equally, applying userSelectText unconditionally (without the canUseTouchScreen()/shouldUseNarrowLayout gate) reverts the intentional touch-device behavior #92142 explicitly preserved.

What alternative solutions did you explore? (Optional)

1. Spot-fix only the plain <Text> fragment — incomplete; misses the TextLink fragments (automatic exports and exported-report links), as explained above.
2. Remove userSelectNone from BaseGenericPressable / drop the BUTTON role on ReportActionItem — over-scoped; the role and no-select behavior on pressables are intentional (a11y, touch scrolling) and changing them regresses every pressable in the app.
3. Route all export messages through RenderHTML via getExportIntegrationMessageHTML (as the reasoning branch does) — works, but it swaps a static styled <Text> list for per-render HTML parsing and changes link handling/DOM structure; the one-style-array fix removes the problem with zero added runtime cost.

[shivang-goliyan]

Proposal

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

On desktop web, after you Mark as exported on a report connected to Sage Intacct, the export system message shows up in the chat but you can't select it by clicking and dragging. Every other recent system message can be selected now, so this one feels broken. Users expect to be able to highlight and copy that text.

What is the root cause of that problem?

The message renders in src/components/ReportActionItem/ExportIntegration.tsx. When the action has no reasoning, it falls to the branch at lines 48-72 and renders each fragment as a plain <Text style={[styles.chatItemMessage, styles.colorMuted]}> with no styles.userSelectText.

Every report action is wrapped in PressableWithSecondaryInteraction (accessibilityRole BUTTON), and BaseGenericPressable sets user-select: none on the pressable. So any child text starts non-selectable and has to opt back in with styles.userSelectText. This one never does.

PR #92142 (fb8771e18ed) added exactly that opt-in to the other system messages: ReportActionItemBasicMessage, ReportActionItemMessageWithExplain, TaskAction, and InlineSystemMessage. It just never touched ExportIntegration.tsx, which is why this issue was filed straight out of that PR's QA. Worth noting the hasReasoning branch here (lines 34-44) routes to ReportActionItemMessageWithExplain, which #92142 already made selectable via isSelectable={!canUseTouchScreen() || !shouldUseNarrowLayout}. The repro (Mark as exported = markedManually) hits the non-reasoning branch, so it lands on the raw <Text> that got missed.

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

Apply the same selectable style the rest of the system messages use, on the plain <Text> fragment in ExportIntegration.tsx. Import canUseTouchScreen from @libs/DeviceCapabilities and useResponsiveLayout from @hooks/useResponsiveLayout, then:

const {shouldUseNarrowLayout} = useResponsiveLayout();
const selectableStyle = !canUseTouchScreen() || !shouldUseNarrowLayout ? styles.userSelectText : styles.userSelectNone;

and add selectableStyle to the <Text> style array (line 55). This keeps the parent user-select: none intact on purpose, since that's what allows touch scrolling on narrow layouts, and only re-enables selection where #92142 intended it (desktop / wide web). I'd leave the TextLink fragments alone, since #92142 keeps links non-selectable by design. This closes the one gap that PR left behind.

I'd also extend tests/ui/ReportActionItemTest.tsx, which already has EXPORTED_TO_INTEGRATION render tests around line 2073 but doesn't assert the selectable style on the non-reasoning <Text>.

What alternative solutions did you explore? (Optional)

I checked whether the fix belonged on a RenderHTML/isSelectable prop, but only the reasoning branch uses RenderHTML and #92142 already handles it; the repro path is a plain <Text>, so that wouldn't fix it. I also confirmed the main message is a <Text> (fragments where !fragment.url), not a TextLink, so making links selectable isn't needed and would go against #92142's link behavior.

[dilshodmackbook-sketch]

Note: This was auto-flagged as a duplicate of #issuecomment-4896527199, but that proposal was posted at 2026-07-06T18:52:43Z — before the External (18:52:46Z) and Help Wanted (18:52:48Z) labels were applied. Proposals submitted before the issue is opened for external contribution don't count as valid earlier proposals, so this isn't a duplicate. Reinstating it below (also reworked with a distinct approach).

Proposal

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

The export system message created by More > Export > Mark as exported (e.g. marked ... as manually exported to Sage Intacct) cannot be selected by clicking and dragging on desktop web, even though other system messages are now selectable.

What is the root cause of that problem?

ExportIntegration renders the export message through two divergent paths, and only one of them inherited the selectability fix from PR #92142:

App/src/components/ReportActionItem/ExportIntegration.tsx

Lines 34 to 72 in fb8771e

	if (hasReasoning(action)) {
	const message = getExportIntegrationMessageHTML(translate, action);
	return (
	<ReportActionItemMessageWithExplain
	message={message}
	action={action}
	childReport={childReport}
	originalReport={originalReport}
	/>
	);
	}
	const fragments = getExportIntegrationActionFragments(translate, action);
	return (
	<View style={[styles.flex1, styles.flexRow, styles.alignItemsCenter, styles.flexWrap]}>
	{fragments.map((fragment, index) => {
	if (!fragment.url) {
	return (
	<Text
	key={index}
	style={[styles.chatItemMessage, styles.colorMuted]}
	>
	{fragment.text}{' '}
	</Text>
	);
	}
	return (
	<TextLink
	key={index}
	href={fragment.url}
	>
	{fragment.text}{' '}
	</TextLink>
	);
	})}
	</View>
	);

• When the action has reasoning, it goes through ReportActionItemMessageWithExplain (an HTML/RenderHTML renderer), which Make system/violation messages text-selectable on desktop web #92142 already made selectable.
• When it does not (the markedManually / Mark as exported case), it renders the fragments directly as raw <Text>/<TextLink> with only styles.chatItemMessage/styles.colorMuted and no selectability handling.

Because every report action is wrapped in a PressableWithSecondaryInteraction (accessibilityRole=BUTTON → user-select: none), this raw-<Text> branch inherits user-select: none with nothing to override it, so the manual-export message can't be selected. This is the same class of gap #92142 fixed elsewhere — it just never touched this branch.

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

Instead of patching the raw fragments, converge the non-reasoning branch onto the same HTML path that is already selectable. We already have getExportIntegrationMessageHTML, which builds the exact same message (links included) as HTML, so we can render it with RenderHTML + isSelectable — the identical pattern #92142 applied to TaskAction:

App/src/components/ReportActionItem/TaskAction.tsx

Lines 28 to 39 in fb8771e

	const isSelectable = !canUseTouchScreen() || !shouldUseNarrowLayout;
	const selectableStyle = isSelectable ? styles.userSelectText : styles.userSelectNone;
	return (
	<View style={[styles.flex1, styles.flexRow, styles.alignItemsCenter, styles.breakWord, styles.preWrap]}>
	{message.html ? (
	<RenderHTML
	html={`<comment><muted-text>${message.html}</muted-text></comment>`}
	isSelectable={isSelectable}
	/>
	) : (
	<Text style={[styles.chatItemMessage, styles.colorMuted, selectableStyle]}>{message.text}</Text>

In ExportIntegration, replace the manual fragment mapping with:

const {shouldUseNarrowLayout} = useResponsiveLayout();
const isSelectable = !canUseTouchScreen() || !shouldUseNarrowLayout;
const message = getExportIntegrationMessageHTML(translate, action);

return (
    <View style={[styles.flex1, styles.flexRow, styles.alignItemsCenter, styles.flexWrap]}>
        <RenderHTML
            html={`<comment><muted-text>${message}</muted-text></comment>`}
            isSelectable={isSelectable}
        />
    </View>
);

with the added imports of RenderHTML, useResponsiveLayout, and canUseTouchScreen.

This makes both branches selectable on desktop web while preserving user-select: none on touch/narrow layouts, and it removes the duplicated rendering logic so this can't drift out of sync again. getExportIntegrationMessageHTML already emits the URLs as <a> links, so the existing link behavior is preserved.

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

• Render an EXPORTED_TO_INTEGRATION action with markedManually: true in ExportIntegration on a wide/desktop-web layout and assert the rendered message is selectable (isSelectable/userSelectText).
• Render the same action on a narrow/touch layout and assert it stays non-selectable so mobile-web scrolling isn't disrupted.
• Assert the integration URL still renders as a link in the message.

What alternative solutions did you explore? (Optional)

A smaller, in-place option is to keep the raw fragment rendering and just add the conditional selectableStyle (!canUseTouchScreen() || !shouldUseNarrowLayout ? styles.userSelectText : styles.userSelectNone) to the fragment <Text>, matching what #92142 did for ReportActionItemBasicMessage. That is a valid minimal fix, but it leaves the two rendering paths divergent; routing through the shared HTML renderer keeps the two branches consistent and reuses the already-tested selectable path.

[lorretheboy]

Note: This isn't a duplicate — the proposal it was flagged against was posted before the Help Wanted label (2026-07-06T18:52:43Z, before 2026-07-06T18:52:48Z), so it isn't a valid earlier proposal.

Proposal

What is the root cause of that problem?

Every report action is wrapped in a pressable with role=BUTTON, which applies user-select: none to the whole action:

App/src/components/Pressable/GenericPressable/implementation/BaseGenericPressable.tsx

Line 200 in 7ebf80b

isRoleButton && styles.userSelectNone,

So each message renderer must explicitly opt back in with styles.userSelectText. PR #92142 added that opt-in to ReportActionItemBasicMessage, ReportActionItemMessageWithExplain, TaskAction and InlineSystemMessage, but missed ExportIntegration — the renderer for EXPORTED_TO_INTEGRATION actions. A "Mark as exported" action has no reasoning in its original message, so hasReasoning(action) is false and the component skips the (fixed) ReportActionItemMessageWithExplain path, instead rendering the fragments with a plain <Text> that never overrides the inherited user-select: none:

App/src/components/ReportActionItem/ExportIntegration.tsx

Lines 48 to 71 in 7ebf80b

	return (
	<View style={[styles.flex1, styles.flexRow, styles.alignItemsCenter, styles.flexWrap]}>
	{fragments.map((fragment, index) => {
	if (!fragment.url) {
	return (
	<Text
	key={index}
	style={[styles.chatItemMessage, styles.colorMuted]}
	>
	{fragment.text}{' '}
	</Text>
	);
	}
	return (
	<TextLink
	key={index}
	href={fragment.url}
	>
	{fragment.text}{' '}
	</TextLink>
	);
	})}
	</View>

Result: the export system message can't be selected by clicking and dragging.

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

Apply the exact pattern PR #92142 established in the other renderers to ExportIntegration's fragment branch — compute the selectable style and add it to the fragment text (and the TextLink, which sits inside the same non-selectable pressable):

const {shouldUseNarrowLayout} = useResponsiveLayout();
const selectableStyle = !canUseTouchScreen() || !shouldUseNarrowLayout ? styles.userSelectText : styles.userSelectNone;
...
<Text style={[styles.chatItemMessage, styles.colorMuted, selectableStyle]}>

mirroring the existing implementation in ReportActionItemBasicMessage:

App/src/pages/inbox/report/ReportActionItemBasicMessage.tsx

Line 25 in 7ebf80b

const selectableStyle = !canUseTouchScreen() || !shouldUseNarrowLayout ? styles.userSelectText : styles.userSelectNone;

This keeps touch devices non-selectable (no accidental selection while scrolling), same as the rest of the PR.

What alternative solutions did you explore? (Optional)

Rendering the non-reasoning branch through ReportActionItemBasicMessage (building the text from the fragments) so it inherits the fix automatically — but that would lose the inline TextLink fragments, so the small local style addition is safer.

[samranahm]

Proposal

What is the root cause of that problem?

After marking a report as exported, NewDot posts an export system message (an EXPORTED_TO_INTEGRATION style report action). On web this message renders as an interactive report-action fragment because it contains a link back to the integration/download flow, rather than as a plain selectable comment.

The export flow surface lives in Export.ts:

App/src/libs/actions/Export.ts

Lines 14 to 15 in 7ebf80b

	function sendExportFileFromConcierge(exportID: string, exportDownload: OnyxEntry<ExportDownload>) {
	const onyxKey = `${ONYXKEYS.COLLECTION.EXPORT_DOWNLOAD}${exportID}` as const;

The message row is drawn through the report action fragment/message renderer, and because that container is wrapped in a pressable/link element with user-select: none behavior (the same treatment given to actionable system messages), the browser starts a click-and-drag as a press gesture instead of a text selection. So when the user tries to drag across the export message, the pointer never enters a user-select: text region and no text gets highlighted. Regular expense comment messages do not have this wrapper, which is why they select normally while the export system message does not.

The gap: the export system message container is not marked selectable, so a click-and-drag produces no selection, contrary to the expected behavior that any report message text can be highlighted.

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

1. Render the export system message text as selectable so pointer drag maps to text selection instead of a press gesture. In the fragment/message component that renders the export report action, apply the shared selectable-text style (styles.userSelect / selectable on the Text) to the text node, mirroring how ordinary comment fragments render, while keeping any embedded link pressable.

2. Ensure the outer wrapper for the export system message does not force user-select: none. Where the export message row is wrapped in a PressableWithoutFeedback/link container originating from the export action flow in Export.ts, allow text selection on the non-link portion so a drag across the message highlights it:

App/src/libs/actions/Export.ts

Lines 14 to 15 in 7ebf80b

	function sendExportFileFromConcierge(exportID: string, exportDownload: OnyxEntry<ExportDownload>) {
	const onyxKey = `${ONYXKEYS.COLLECTION.EXPORT_DOWNLOAD}${exportID}` as const;

<Text selectable style={styles.userSelectText}>
    {exportMessageText}
</Text>

3. Keep the interactive link (download/open integration) as a nested pressable inside the now-selectable text, so clicking the link still works while dragging over the surrounding text selects it. This preserves both behaviors and matches how other report messages allow selection alongside inline links.

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.