[Due for payment 2025-11-14] [$250] Chat - Composer loses focus after returning to Inbox from Account tab

[nlemma]

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.2.13-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: #67523
Email or phone of affected tester (no customers): msdonjssodis22@gmail.com
Issue reported by: Applause Internal Team
Device used: Mac 15.5 / Chrome
App Component: Chat Report View

Action Performed:

1. Go to staging.new.expensify.com
2. Go to any chat.
3. Click on the composer if not focused.
4. Go to Account.
5. Go back to Inbox.

Expected Result:

The composer will remain focused.

Actual Result:

The composer loses focus after returning to Inbox from Account tab.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6942379_1757657925844.Screen_Recording_2025-09-12_at_14.16.31.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021967462997761748140
• Upwork Job ID: 1967462997761748140
• Last Price Increase: 2025-10-27

Issue Owner

Current Issue Owner: @RachCHopkins

[melvin-bot]

Triggered auto assignment to @RachCHopkins (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.

[SAYAN02-DEV]

Actually the chat composer is still focused after you come back from accounts tab. The highlighted green color goes away after few seconds but once you start typing it will automatically continue from where you left.

Screencast.from.2025-09-12.18-33-50.webm

[lorretheboy]

Proposal

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

Composer loses focus after returning to Inbox from Account tab

What is the root cause of that problem?

When the focus trap is activated, it calls activeElement?.blur() on any active input or textarea elements:

App/src/components/FocusTrap/FocusTrapForScreen/index.web.tsx

Lines 44 to 50 in ade4430

	onActivate: () => {
	const activeElement = document?.activeElement as HTMLElement;
	if (activeElement?.nodeName === CONST.ELEMENT_NAME.INPUT || activeElement?.nodeName === CONST.ELEMENT_NAME.TEXTAREA) {
	return;
	}
	activeElement?.blur();
	},

However, this only returns early if the active element is an INPUT or TEXTAREA. The composer is using RNMarkdownTextInput (div) that's not being caught by this check.

When we navigate to the Account section, the Settings navigator with FocusTrapForScreen gets activated, and this focus trap blurs the active element (the composer), which removes the visual focus indicator.

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

Modify the FocusTrapForScreen component to also check for contentEditable elements, we need to check composer's native ID as well

                    if (activeElement?.nodeName === CONST.ELEMENT_NAME.INPUT ||
                        activeElement?.nodeName === CONST.ELEMENT_NAME.TEXTAREA ||
                        activeElement?.id === CONST.COMPOSER.NATIVE_ID) {
                        return;
                    }

We can add to other similar places to add check for CONST.COMPOSER.NATIVE_ID if needed

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

NA

What alternative solutions did you explore? (Optional)

NA

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.

[dmkt9]

Proposal

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

The composer loses focus after returning to Inbox from Account tab.

What is the root cause of that problem?

1. Although FocusTrap is not activated on ReportScreen
   

   App/src/components/FocusTrap/FocusTrapForScreen/index.web.tsx

   Lines 31 to 34 in aa03ded

   	// Focus trap can't be active on these screens if the layout is wide because they may be displayed side by side.
   	if (WIDE_LAYOUT_INACTIVE_SCREENS.includes(route.name) && !shouldUseNarrowLayout) {
   	return false;
   	}

   
   

   App/src/components/FocusTrap/WIDE_LAYOUT_INACTIVE_SCREENS.ts

   Lines 7 to 10 in aa03ded

   	const WIDE_LAYOUT_INACTIVE_SCREENS: string[] = [
   	SCREENS.HOME,
   	SCREENS.SETTINGS.ROOT,
   	SCREENS.REPORT,

   The onActivate callback still gets triggered and causes the current composer to blur:
   

   App/src/components/FocusTrap/FocusTrapForScreen/index.web.tsx

   Lines 45 to 49 in aa03ded

   	const activeElement = document?.activeElement as HTMLElement;
   	if (activeElement?.nodeName === CONST.ELEMENT_NAME.INPUT || activeElement?.nodeName === CONST.ELEMENT_NAME.TEXTAREA) {
   	return;
   	}
   	activeElement?.blur();

2. The FocusTrap is being activated from SettingsSplitNavigator, which can be confirmed by adding a log. This happens because we always activate FocusTrap regardless of whether the route is currently focused:
   

   App/src/components/FocusTrap/FocusTrapForScreen/index.web.tsx

   Lines 39 to 41 in aa03ded

   	<FocusTrap
   	active={isActive}
   	paused={!isFocused}

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

Currently, we activate FocusTrap when isActive === true, and then pause it if isFocused === false.
- However, note that FocusTrap operates synchronously. Calling pause does not cancel the activation process—it always runs active → onActivate → pause.
- As a result, the onActivate callback will always be triggered if isActive === true.

So we have a few options:

1. Only activate FocusTrap when the route is focused:
   

   App/src/components/FocusTrap/FocusTrapForScreen/index.web.tsx

   Line 35 in aa03ded

   return true;

   return isFocused;

   Or:
   

   App/src/components/FocusTrap/FocusTrapForScreen/index.web.tsx

   Line 40 in aa03ded

   active={isActive}

   active={isActive && isFocused}

2. Only trigger the onActivate callback when the route is focused:
   

   App/src/components/FocusTrap/FocusTrapForScreen/index.web.tsx

   Line 46 in aa03ded

   if (activeElement?.nodeName === CONST.ELEMENT_NAME.INPUT || activeElement?.nodeName === CONST.ELEMENT_NAME.TEXTAREA) {

   if (!isFocused || activeElement?.nodeName === CONST.ELEMENT_NAME.INPUT || activeElement?.nodeName === CONST.ELEMENT_NAME.TEXTAREA) {

3. Add NAVIGATORS.SETTINGS_SPLIT_NAVIGATOR to WIDE_LAYOUT_INACTIVE_SCREENS

Note: Since the composer on web is a div element, we can add an exception for it here to be safer.

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

NA

What alternative solutions did you explore? (Optional)

NA

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.

2025-09-12.22-48-46.mp4

[Eskalifer1]

Proposal

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

Chat - Composer loses focus after returning to Inbox from Account tab

What is the root cause of that problem?

This all comes from the navigation preload, which was recently added to the project.

The main reason is that we have a hook call usePreloadFullScreenNavigators in every SplitNavigator:

App/src/libs/Navigation/AppNavigator/Navigators/SettingsSplitNavigator.tsx

Line 34 in d8adfa5

usePreloadFullScreenNavigators();

App/src/libs/Navigation/AppNavigator/Navigators/WorkspaceSplitNavigator.tsx

Line 44 in d8adfa5

usePreloadFullScreenNavigators();

App/src/libs/Navigation/AppNavigator/Navigators/SearchFullscreenNavigator.tsx

Line 24 in d8adfa5

usePreloadFullScreenNavigators();

App/src/libs/Navigation/AppNavigator/Navigators/ReportsSplitNavigator.tsx

Line 42 in d8adfa5

usePreloadFullScreenNavigators();

This hook preloads specified routes, but currently only loads two splitNavigators:

App/src/libs/Navigation/AppNavigator/usePreloadFullScreenNavigators.ts

Line 27 in d8adfa5

const TABS_TO_PRELOAD = [NAVIGATION_TABS.SETTINGS, NAVIGATION_TABS.WORKSPACES];

But what exactly is this preload?
The preload mounts hidden navigators for other tabs in advance, so when the user switches tabs later, the screens are already created and load instantly.

And the problem arises specifically with SettingsSplitNavigator, but why does the problem arise only with it and not with Workspace?

In fact, it occurs if you enter the application for the first time and have never been to the workspaces page, but since we have an additional check here that checks whether we have ever loaded it before, and if so, we do nothing. As a result of this check, this bug does not reproduce in this case (if you remove this check for testing, the bug will also reproduce with this splitNavigator):

App/src/libs/Navigation/AppNavigator/usePreloadFullScreenNavigators.ts

Lines 33 to 35 in d8adfa5

	if (lastWorkspacesSplitNavigator) {
	return;
	}

And SettingSplitNavigator has a FocusTrap:

App/src/libs/Navigation/AppNavigator/Navigators/SettingsSplitNavigator.tsx

Lines 29 to 37 in d8adfa5

	function SettingsSplitNavigator() {
	const route = useRoute();
	const splitNavigatorScreenOptions = useSplitNavigatorScreenOptions();
	// This hook preloads the screens of adjacent tabs to make changing tabs faster.
	usePreloadFullScreenNavigators();
	return (
	<FocusTrapForScreens>

And it turns out that when we go to another SplitNavigator, after a second (because there is a delay here:

App/src/libs/Navigation/AppNavigator/usePreloadFullScreenNavigators.ts

Lines 127 to 135 in d8adfa5

	setTimeout(() => {
	TABS_TO_PRELOAD.filter((tabName) => {
	const isCurrentTab = TAB_TO_FULLSCREEN[tabName].includes(route.name as FullScreenName);
	const isRouteAlreadyPreloaded = preloadedRoutes.some((preloadedRoute) => TAB_TO_FULLSCREEN[tabName].includes(preloadedRoute.name as FullScreenName));
	return !isCurrentTab && !isRouteAlreadyPreloaded;
	}).forEach((tabName) => {
	preloadTab(tabName, navigation, subscriptionPlan);
	});
	}, TIMING_TO_CALL_PRELOAD);

), we preload all splitNavigators (which is essentially mounting), and since SettingSplitNavigator has FocusTrap, it activates, causing us to lose focus on the input.

And in most cases, preload for WorkspaceSplitNavigator will not occur because it is already considered loaded.

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

Since even with the check used in WorkspaceSplitNavigator this bug can occur, I think we need to remove FocusTrap for Split navigators, because each page is still wrapped in ScreenWraper, which has FocusTrap inside itself.

For example, ReportsSplitNavigator already uses this pattern (if necessary, we can replace FocusTrapForScreens with FreezeWrapper instead of removing it):

App/src/libs/Navigation/AppNavigator/Navigators/ReportsSplitNavigator.tsx

Lines 44 to 64 in d8adfa5

	return (
	<FreezeWrapper>
	<Split.Navigator
	persistentScreens={[SCREENS.HOME]}
	sidebarScreen={SCREENS.HOME}
	defaultCentralScreen={SCREENS.REPORT}
	parentRoute={route}
	screenOptions={splitNavigatorScreenOptions.centralScreen}
	>
	<Split.Screen
	name={SCREENS.HOME}
	getComponent={loadSidebarScreen}
	options={splitNavigatorScreenOptions.sidebarScreen}
	/>
	<Split.Screen
	name={SCREENS.REPORT}
	initialParams={{reportID: initialReportID, openOnAdminRoom: shouldOpenOnAdminRoom() ? true : undefined}}
	getComponent={loadReportScreen}
	/>
	</Split.Navigator>
	</FreezeWrapper>

PS: We can leave FocusTrap and make it active depending on the screen focus:

const isActive = useIsFocused();

<FocusTrapForScreens focusTrapSettings={{active: isActive}}>

The same should be done for WorkspaceSplitNavigator, other SplitNavigators do not have focusTrap yet.

PS2: Adding any checks to see if we have already loaded SpliNavigator will not fix the bug, but will make it less noticeable, because when the user logs in for the first time, this bug will reproduce, since at that moment the navigation stack will be empty, and as a result, preloading will occur anyway.

PS3: We can add a check here:

App/src/components/FocusTrap/FocusTrapForScreen/index.web.tsx

Lines 17 to 36 in d8adfa5

	const isActive = useMemo(() => {
	if (typeof focusTrapSettings?.active !== 'undefined') {
	return focusTrapSettings.active;
	}
	// Focus trap can't be active on sidebar screens because it would block access to the tab bar.
	if (isSidebarScreenName(route.name)) {
	return false;
	}
	// in top tabs only focus trap for currently shown tab should be active
	if (TOP_TAB_SCREENS.find((screen) => screen === route.name)) {
	return isFocused;
	}
	// Focus trap can't be active on these screens if the layout is wide because they may be displayed side by side.
	if (WIDE_LAYOUT_INACTIVE_SCREENS.includes(route.name) && !shouldUseNarrowLayout) {
	return false;
	}
	return true;
	}, [isFocused, shouldUseNarrowLayout, route.name, focusTrapSettings?.active]);

And if it's SplitNavigator and it's !isFocused, then return false

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

N/A

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.

[RachCHopkins]

@SAYAN02-DEV is correct, it's a display issue.

[melvin-bot]

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

[melvin-bot]

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