[$250] Not able to focus on main composer while edit composer is open

[aimane-chnaif]

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.3.2-2
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @aimane-chnaif
Slack conversation (hyperlinked to channel name):

Action Performed:

1. Go to any chat and send any message
2. Focus on composer
3. Press Up Arrow to edit message
4. Switch to another chat and come back
5. Focus on edit composer
6. Focus on main composer

Expected Result:

Main composer should be focused

Actual Result:

Main composer is focused briefly, and then edit composer is focused back

Workaround:

Close edit composer to be able to focus back on main composer

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

bug.mov

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022013509624834775039
• Upwork Job ID: 2013509624834775039
• Last Price Increase: 2026-02-17

Issue Owner

Current Issue Owner: @QichenZhu

[melvin-bot]

Triggered auto assignment to @greg-schroeder (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[annaweber830]

Proposal

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

When the edit composer is open, the user can’t reliably focus the main composer. The main composer receives focus briefly, then focus snaps back to the edit composer—especially after switching chats and returning.

What is the root cause of that problem?

Our focus-management behavior includes automatic refocusing intended to keep editing stable (e.g., restoring the last focused composer / maintaining edit state across navigation). In this scenario, that auto-refocus logic can run after the user explicitly focuses the main composer, causing the edit composer to steal focus back.
Concretely, a delayed “restore focus” (triggered by blur/navigation/interaction completion) doesn’t distinguish between:

• “Edit composer lost focus unintentionally, restore it”
• “User intentionally focused a different input (main composer), do not override”

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

• Update composer focus restoration logic to be non-invasive:
  • If another text input is already focused (e.g., the main composer), do not refocus the edit composer.
  • If a delayed refocus is scheduled, re-check what is currently focused right before applying focus, and cancel if focus has moved elsewhere.
    Ensure the “last focused composer should regain focus” rule only applies when focus was lost due to non-user-intentional causes (e.g., transient UI events), not when the user explicitly taps/focuses the main composer.
    

    App/src/libs/actions/InputFocus/index.website.ts

    Lines 21 to 31 in e94f05d

    	if (!isFocused && !onyxFocused && !modal.willAlertModalBecomeVisible && !modal.isVisible && refSave) {
    	if (!ReportActionComposeFocusManager.isFocused()) {
    	// Focusing will fail when it is called immediately after closing modal so we call it after interaction.
    	// eslint-disable-next-line @typescript-eslint/no-deprecated
    	InteractionManager.runAfterInteractions(() => {
    	refSave?.focus();
    	});
    	} else {
    	refSave = undefined;
    	}
    	}

if (!isFocused && !onyxFocused && !modal.willAlertModalBecomeVisible && !modal.isVisible && refSave) {
        const activeElement = DomUtils.getActiveElement();
        const isAnotherTextInputFocused =
            !!activeElement && activeElement !== refSave && (activeElement.nodeName === 'INPUT' || activeElement.nodeName === 'TEXTAREA');

        if (isAnotherTextInputFocused) {
            refSave = undefined;
            return;
        }

        // Focusing will fail when it is called immediately after closing modal so we call it after interaction.
        // eslint-disable-next-line @typescript-eslint/no-deprecated
        InteractionManager.runAfterInteractions(() => {
            // Re-check after interactions: focus may have moved to another input by the time this runs.
            if (ReportActionComposeFocusManager.isFocused()) {
                refSave = undefined;
                return;
            }

            const currentActiveElement = DomUtils.getActiveElement();
            const isTextInputCurrentlyFocused =
                !!currentActiveElement && currentActiveElement !== refSave && (currentActiveElement.nodeName === 'INPUT' || currentActiveElement.nodeName === 'TEXTAREA');
            if (isTextInputCurrentlyFocused) {
                refSave = undefined;
                return;
            }

            refSave?.focus();
        });
    }

What alternative solutions did you explore? (Optional)

[yatin-italy]

Proposal

Restate the problem this issue is trying to solve.

• When the edit composer is open, the user clicks the main composer.
• The main composer gets focus for a moment.
• Then the edit composer takes focus back.
• The user cannot type a new message.

What is the root cause of that problem?

• The edit composer schedules a delayed refocus after blur.
• It assumes no other composer will get focus.
• If the user clicks the main composer before the callback runs, the callback still fires.
• This steals focus back to the edit composer.

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

• Enforce one rule.
• Never refocus the edit composer if another composer is focused.
• Add a check inside the delayed callback.
• If a composer is already focused, exit and clear the ref.
• Apply the same logic on desktop and website.

index.desktop.ts
Lines 20-32

    if (!isFocused && !onyxFocused && !modal.willAlertModalBecomeVisible && !modal.isVisible && refSave) {
-        if (!ReportActionComposeFocusManager.isFocused()) {
-            InteractionManager.runAfterInteractions(() => {
-                refSave?.focus();
-            });
-        } else {
-            refSave = undefined;
-        }
+        InteractionManager.runAfterInteractions(() => {
+            if (ReportActionComposeFocusManager.isFocused()) {
+                refSave = undefined;
+                return;
+            }
+            refSave?.focus();
+        });
    }

index.website.ts
Lines 20-32

    if (!isFocused && !onyxFocused && !modal.willAlertModalBecomeVisible && !modal.isVisible && refSave) {
-        if (!ReportActionComposeFocusManager.isFocused()) {
-            InteractionManager.runAfterInteractions(() => {
-                refSave?.focus();
-            });
-        } else {
-            refSave = undefined;
-        }
+        InteractionManager.runAfterInteractions(() => {
+            if (ReportActionComposeFocusManager.isFocused()) {
+                refSave = undefined;
+                return;
+            }
+            refSave?.focus();
+        });
    }

What alternative solutions did you explore? (Optional)

[aimane-chnaif]

@greg-schroeder Please assign @blazejkustra and me here. This is coming from #79359 (comment)

[melvin-bot]

@greg-schroeder Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot]

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

[melvin-bot]

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