Chat - Website crashes after deleting a comment

[lanitochka17]

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.38-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: #83824
Email or phone of affected tester (no customers): biruknew45+66yyjjj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Critical User Impact
Device used: Web
App Component: Chat Report View

Action Performed:

1. https://staging.new.expensify.com
2. Go to new chat (new WS chat or user)
3. Send any message
4. Press Arrow Up key on keyboard
5. Select All - Ctrl / Cmd + A
6. Press 'Delete' key
7. Press 'Enter' key
8. Click "Enter" key to confirm

Expected Result:

it shouldn't crash

Actual Result:

website crashes

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7104313_1773674279568.bandicam_2026-03-16_18-00-46-843.mp4

Bug7104313_1773674279576!staging.new.expensify.com-1773674246256.txt

View all open jobs on GitHub

[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]

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

[melvin-bot]

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

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #83824 - "Fix : Not able to focus on main composer while edit composer is open." by @M00rish (High confidence)
Related Issues: #79769

Recommendation: REVERT

PR #83824 introduced a conditional check that prevents the main composer ref from being updated when the composer loses focus. This causes crashes when code attempts to access the now-stale or null composer reference, particularly during the delete-comment-and-confirm flow described in the reproduction steps.

Labels: This is a frontend bug caused by an App PR. Keeping DeployBlockerCash label as appropriate. No label changes needed.

📋 Detailed Analysis

Evidence

• The bug is reproducible on staging (v9.3.38-0) but not production, indicating it was introduced in this deploy cycle
• PR Fix : Not able to focus on main composer while edit composer is open. #83824 is explicitly linked in the issue as the regression test source
• The crash occurs during edit composer interactions (Arrow Up to edit, delete content, submit)
• PR Fix : Not able to focus on main composer while edit composer is open. #83824 merged on 2026-03-13, which aligns with the staging deploy timeline

Verification

• Affected file: src/pages/inbox/report/ReportActionCompose/ComposerWithSuggestions/ComposerWithSuggestions.tsx
• The change: Added if (isFocused) condition at line 317 before setting ReportActionComposeFocusManager.composerRef.current = el
• Confirmed: This is the exact file that handles composer focus management and edit functionality

Root Cause

The PR modified the setTextInputRef callback to only update ReportActionComposeFocusManager.composerRef.current when isFocused is true:

const setTextInputRef = useCallback(
    (el: TextInput) => {
        if (isFocused) {  // <-- New condition added
            ReportActionComposeFocusManager.composerRef.current = el;
        }
        textInputRef.current = el;
        // ...
    },
    [animatedRef, isFocused],
);

The problem: When the main composer loses focus (e.g., when edit composer opens), the composerRef.current is no longer updated. This creates a scenario where:

1. User presses Arrow Up to edit a message (edit composer opens, main composer loses focus)
2. The main composer's composerRef.current is not updated due to the isFocused check
3. User deletes content and presses Enter
4. Code elsewhere attempts to access composerRef.current expecting it to be valid
5. The ref is now stale/null, causing a crash

Additionally, there's an inconsistency: Line 759 in the same file still sets the ref unconditionally:

ReportActionComposeFocusManager.composerRef.current = textInputRef.current;

This inconsistency between conditional and unconditional ref updates creates unpredictable behavior.