[Due for payment 2026-05-22] [Due for payment 2026-05-20] Chat - Unable to delete edited message by removing all the content on composer.

@hungvu193

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.73-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #76741
Email or phone of affected tester (no customers): ibellicotest+2250@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Other

Action Performed:

Prerequisite: If testing on Web, switch screen to narrow size.

Open the Expensify app.
Open any chat.
Send a message.
Long tap on sent message and select "Edit Message"
Make any edition and send.
Long tap on message again and select "Edit Message"
Delete all the content from composer.
Note that "Send" button changes from green to gray and tapping on it doesn´t trigger "Delete" modal.
Try to select message again.
Note that message cannot be selected.

Expected Result:

Deleting all the content from composer while editing a message and tapping on "Send" should trigger a "Delete" modal.

Actual Result:

After deleting all the content on composer while editing an arleady edited message, send button becomes unresponsive and "Delete" modal doesn´t appear. Also, after this, message can´t be selected again.

Workaround:

Unknown

Platforms:

Screenshots/Videos

Bug7152765_1778667627196.Delete_Modal.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @hungvu193

You have been assigned to this deploy blocker because you recently merged this PR: #76741

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

👋 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:

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

@Kureev

Investigation Summary

Classification: Frontend bug
Causing PR: #76741 - "Adapt message editing behavior based on screen size (Slack-style UX)" by @Kureev (High confidence)
Related Issues: None

Recommendation: REVERT

PR #76741 introduced a large-scale refactor of the message editing flow for narrow layouts. The bug is staged-only, not in production, and the fix would require non-trivial changes to the new context-driven edit state machine — reverting is the safest option.

Assigned: @Kureev (PR author), @hungvu193, @adhorodyski, @mountiny (approving reviewers)
Labels: DeployBlockerCash kept (Frontend bug in App). No label changes made.

Detailed Analysis

Evidence

PR #76741 introduced a new Slack-style editing UX where narrow layouts (mobile/small screen) use the main bottom composer instead of inline editing. It added a substantial new context system (ComposerProvider, ComposerEditStateContext, ReportActionEditMessageContext) to manage the editing state machine.

The bug is staging-only (version 9.3.73-0) and not present in production, confirming it was introduced by one of the PRs in the current staging deploy. The melvin-bot also identified this PR directly, and it is the only PR in the staging list that touches the message editing/composer flow.

The repro steps specify narrow screen (Windows/Chrome narrow, or Android hybrid app), which aligns exactly with PR #76741's "narrow layout uses bottom composer" code path.

Verification

Files affected by the bug:

src/pages/inbox/report/ReportActionCompose/ComposerProvider.tsx
src/pages/inbox/report/ReportActionCompose/useComposerSubmit.ts
src/pages/inbox/report/ReportActionEditMessageContext.tsx
src/pages/inbox/report/ReportActionCompose/useEditComposerToggle.ts
src/pages/inbox/report/ReportActionCompose/ComposerSendButton.tsx

PR #76741 created or substantially rewrote all of these files. Confirmed via gh pr view 76741 --json files.

Root Cause

The bug occurs specifically when editing an already-edited message on narrow layout and then clearing all text.

In ReportActionEditMessageContext.tsx, the updateMessage() function (line 144) only updates editingMessage state when prevEditingReportActionID !== editingReportActionID. When re-editing the same message a second time, the report action ID has not changed, so editingMessage is NOT updated to the current draft — it retains the previously-submitted (already-once-edited) text.

In ComposerProvider.tsx line 69: effectiveDraft = isEditingInComposer ? editingMessage : draftComment. Since editingMessage is stale (not empty), when submitDraftAndClearComposer runs after clearing the text, the check at line 192 (effectiveDraft !== null && effectiveDraft !== '') evaluates as true using the stale editingMessage value.

This causes setDidResetComposerHeight(true) to be called. Since isEditingInComposer is computed as shouldUseNarrowLayout && editingState !== 'off' && !didResetComposerHeight, setting didResetComposerHeight = true flips isEditingInComposer to false. The submit path in validateAndSubmitDraft then does NOT call publishDraft (which would trigger the delete modal), instead calling addComment with an empty string (which also early-returns since it is empty). The draft is not cleared and the editing state becomes stuck — editingState remains 'editing' in the context but isEditingInComposer is now false, making the message unselectable and the composer unresponsive.

Reviewing label has been removed, please complete the "BugZero Checklist".

@hungvu193

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.3.73-4 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

[CP Staging] revert: New editing mechanism for small screens #90513

If no regressions arise, payment will be issued on 2026-05-20. 🎊

For reference, here are some details about the assignees on this issue:

@hungvu193 requires payment through NewDot Manual Requests
@chrispader does not require payment (Contractor)

@hungvu193

@hungvu193 The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

@hungvu193

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.3.74-7 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

If no regressions arise, payment will be issued on 2026-05-22. 🎊

For reference, here are some details about the assignees on this issue:

@hungvu193 requires payment through NewDot Manual Requests
@chrispader does not require payment (Contractor)

@hungvu193

@hungvu193 The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.