Chat - Cursor focuses at the beginning of the text after removing expense from report

[mitarachim]

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.74-7
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #90516
Email or phone of affected tester (no customers): sdsdjoijdoisnjodis@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create an empty report.
4. Open the report.
5. Send a message.
6. Right click on the message > Edit comment.
7. Click Add expense > Create expense.
8. Create a manual expense.
9. Click on the end of the message in the composer to focus it.
10. Click Report field.
11. Click Remove from report.

Expected Result:

The cursor will focus at the end of the text.

Actual Result:

The cursor focuses at the beginning of the text after removing expense from report.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7155307_1778866385595.8.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @chrispader

[melvin-bot]

@mountiny recently merged #90516, but they are OOO right now, so I'll auto-assign someone else.

[melvin-bot]

Triggered auto assignment to @yuwenmemon (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #90516 - "Allow editing messages in Composer on narrow screens V2" by @chrispader (High confidence)
Related Issues: None

Recommendation: REVERT

PR #90516 significantly rewrote the message editing flow in ReportActionItemMessageEdit.tsx and introduced new context/focus management code. The cursor-at-beginning regression is a side effect of how the refactored code handles re-focus when the "Remove from report" modal closes.

Assigned: @chrispader (PR author), @mountiny, @hungvu193 (approving reviewers)
Labels: DeployBlockerCash kept (frontend App PR is the cause). No label changes made.

Detailed Analysis

Evidence

• The bug is staging-only (not reproducible in production), meaning a recently merged staging PR introduced it.
• melvin-bot auto-commented pointing to PR Allow editing messages in Composer on narrow screens V2 #90516 as the cause, merged at 2026-05-15T16:05:58Z — the same day the issue was reported.
• PR Allow editing messages in Composer on narrow screens V2 #90516 is in the StagingDeployCash checklist (item Allow editing messages in Composer on narrow screens V2 #90516).
• The PR rewrote ReportActionItemMessageEdit.tsx extensively (110 additions / 248 deletions) and introduced new files: ReportActionEditMessageContext.tsx, useEditComposerToggle.ts, useEditMessage.ts, useActiveDraftReportAction.ts, and related context/selection management.
• The bug is reproducible on MacOS: Chrome (wide layout), which is the path through ReportActionItemMessageEdit (inline editing), which is exactly what this PR touched.

Verification

• Affected file: src/pages/inbox/report/ReportActionItemMessageEdit.tsx
• Confirmed PR Allow editing messages in Composer on narrow screens V2 #90516 modifies this file (110 additions / 248 deletions).
• Also affects: src/pages/inbox/report/ReportActionEditMessageContext.tsx (new file, 199 additions) and src/pages/inbox/report/ContextMenu/PopoverReportActionContextMenu.tsx.

Root Cause

When the user clicks "Remove from report" inside the IOURequestStepReport modal:

1. The context menu/modal closes.
2. PopoverReportActionContextMenu.performHide() calls refocusComposerAfterPreventFirstResponder('edit'), which invokes focusComposerWithDelay(editComposerRef)(true).
3. After a delay, input.focus() is called on the edit composer without a forcedSelectionRange. On web, a bare focus() call resets the cursor to position 0 (beginning of text).
4. The onSelectionChange callback fires with {start: 0, end: 0}, updating currentEditMessageSelection in ReportActionEditMessageContext to position 0.
5. A useEffect in ReportActionItemMessageEdit (lines 123–127) re-runs when currentEditMessageSelection changes, calling setSelectionState({start: 0, end: 0}) — placing the cursor at the beginning.

In the pre-PR version of ReportActionItemMessageEdit, the inline editing composer used a different selection management approach that did not propagate the transient focus() cursor reset back into persistent context state. The new ReportActionEditMessageContext and setCurrentEditMessageSelection mechanism introduced by PR #90516 causes the bare focus() reset to be persisted and re-applied via the useEffect.