[$250] Composer Not Displayed After App Relaunch from Chat

[m-natarajan]

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: (Latest staging)
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
Reproducible in production?: Needs Reproduction
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: @AndrewGable
Slack conversation (hyperlinked to channel name): #Quality

Action Performed:

1. Open a chat from the Inbox
2. Kill/force close the app
3. Reopen the app
4. Observe the bottom area of the chat screen

Expected Result:

The composer (text input field) should be visible at the bottom

Actual Result:

The bottom navigation bar appears where the composer should be
Composer is not visible or is overlapped

Workaround:

Unknown

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

The screenshot for the issue in in Slack thread

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @situchan

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022050288719784909672
• Upwork Job ID: 2050288719784909672
• Last Price Increase: 2026-05-08

[exfy-zapier]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[melvin-bot]

📣 @exfy-zapier! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[MelvinBot]

Proposal

What is the root cause of that problem?

Two interacting issues cause the composer to be hidden and the bottom tab bar to appear on iOS cold start after force-close:

1. Tab bar incorrectly shows during unhydrated navigator state. TabNavigatorBar.tsx:47 defines isAtTabRootLevel with a !name guard — when getFocusedLeafScreenName returns undefined (because the split navigator's inner state hasn't hydrated yet, exacerbated by lazy: true in TabNavigator.native.tsx:31), the tab bar treats it as "at root level" and renders visible, overlaying the composer area via negative marginTop.

2. shouldShowComposeInput can persist as false across restarts. On iOS, setShouldShowComposeInputKeyboardAwareBuilder.ts:17 transiently sets shouldShowComposeInput to false during keyboard transitions. Since this Onyx key is persisted to disk, force-killing the app during that window preserves false. On restart, ReportFooter.tsx:61 reads it with a default of false, and the composer only renders when shouldShowComposeInput is true on small screens (line 90). The recovery path — ReportFetchHandler calling setShouldShowComposeInput(true) — is deferred behind both shouldDeferNonEssentials in ReportScreen.tsx:131 and InteractionManager.runAfterInteractions in ReportFetchHandler.tsx:238.

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

Two targeted fixes:

1. In TabNavigatorBar.tsx: When focusedLeaf is undefined and the active route is a split navigator (like REPORTS_SPLIT_NAVIGATOR), treat it as "not at root" instead of "at root". This prevents the tab bar from flashing visible during state hydration. For example, change isAtTabRootLevel to return false when name is undefined but the active route is a known split navigator, or use getPushTargetLeaf from the route params as the fallback before falling back to "at root".

2. In setShouldShowComposeInputKeyboardAwareBuilder.ts: Ensure shouldShowComposeInput is reset to true before the app backgrounds (e.g., in saveCurrentPathBeforeBackground in App.ts), so a transient false value during keyboard transitions never persists across restarts. Alternatively, make this a non-persisted (in-memory only) Onyx key with initialValue: true.

What alternative solutions did you explore?

• Setting shouldShowComposeInput to true unconditionally during app initialization — this would work but could cause a flash of the composer in cases where it should be hidden.
• Removing lazy: true from the tab navigator — this would ensure child states hydrate immediately but could negatively impact cold start performance.

Investigation details

Navigation restoration flow:

• On force-close, App.ts:234-254 saves the current path to LAST_VISITED_PATH
• On cold start, NavigationRoot.tsx:133-143 restores it via getAdaptedStateFromPath
• getAdaptedStateFromPath.ts:277-291 builds state: TAB_NAVIGATOR > REPORTS_SPLIT_NAVIGATOR > [INBOX, REPORT]

Tab bar overlay mechanism:

• Tab bar uses marginTop: -(bottomTabHeight + safeAreaBottom) to overlay content (styles/utils/index.ts:2301)
• SCREENS.REPORT is correctly excluded from SCREENS_WITH_TAB_BAR (TabNavigatorBar.tsx:37-45), so the tab bar hides once the leaf resolves — but the initial undefined window causes the flash

Composer visibility chain:

• ReportFooter.tsx:90: composer shows only when shouldShowComposeInput || !isSmallScreenWidth
• ReportFetchHandler.tsx:236-245: sets shouldShowComposeInput(true) via InteractionManager.runAfterInteractions
• ReportScreen.tsx:131-153: gates ReportFetchHandler behind shouldDeferNonEssentials, and shows ReportActionComposePlaceholder instead of ReportFooter when deferred

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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

[nabi-ebrahimi]

Proposal

What is the root cause of that problem?

The report screen has two transient UI states that can survive or appear during iOS cold start.

First, the bottom tab bar treats an unresolved focused leaf as tab-root. isAtTabRootLevel() returns true when the focused leaf is undefined, and the tab bar then stays visible on narrow layouts:

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

Lines 47 to 82 in a8dad1c

	const isAtTabRootLevel = (name: string | undefined): boolean => !name || SCREENS_WITH_TAB_BAR.has(name) || TAB_WRAPPER_NAVIGATORS.has(name);
	// Deepest `screen` in a `{screen, params}` chain (e.g. WORKSPACE_NAV → WORKSPACE_SPLIT_NAV → WORKSPACE.INITIAL).
	const getPushTargetLeaf = (params: unknown): string | undefined => {
	const p = params as {screen?: unknown; params?: unknown} | undefined;
	if (typeof p?.screen !== 'string') {
	return undefined;
	}
	return getPushTargetLeaf(p.params) ?? p.screen;
	};
	/**
	* Custom tab bar rendered by the BottomTabNavigator. Only receives `state` (not the
	* full BottomTabBarProps) to avoid `descriptors` thrashing memoization.
	* Wrapped in overflow:'visible' so floating buttons (FAB, GPS, Camera) aren't clipped.
	*/
	function TabNavigatorBar({state}: Pick<BottomTabBarProps, 'state'>) {
	const {shouldUseNarrowLayout} = useResponsiveLayout();
	const {isBlockingViewVisible} = useFullScreenBlockingViewState();
	const {paddingBottom: safeAreaPaddingBottom} = useSafeAreaPaddings(true);
	const styles = useThemeStyles();
	const StyleUtils = useStyleUtils();
	const activeRoute = state.routes[state.index];
	const selectedTab = ROUTE_TO_NAVIGATION_TAB[activeRoute?.name ?? SCREENS.HOME] ?? NAVIGATION_TABS.HOME;
	// Trust the focused leaf as the source of truth. Fall back to the push target only when the navigator
	// state hasn't hydrated yet (Android), so the tab bar doesn't flash on the push target during the transition.
	// Tab-level params can be stale after within-tab back navigation, so they must not override an already-hydrated focused leaf.
	const focusedLeaf = getFocusedLeafScreenName(activeRoute?.state);
	const isAtRoot = isAtTabRootLevel(focusedLeaf ?? getPushTargetLeaf(activeRoute?.params));
	// --- Narrow-only animation logic (hooks must run unconditionally per Rules of Hooks) ---
	// On native, screens also render the tab bar via bottomContent for swipe-back animations.
	// Delay showing this navigator's tab bar only when navigating back from a deeper screen
	// (where the tab bar was hidden). Keep it visible during tab switches so it doesn't flash.
	// Guard with shouldUseNarrowLayout so prevShouldHide stays false in wide layout,
	// preventing false shouldApplyDelay triggers on layout transitions (e.g. web resize).
	const shouldHide = shouldUseNarrowLayout && (!isAtRoot || isBlockingViewVisible);

On the Reports tab, the report can be resolved from the current URL before the nested split state is hydrated, so focusedLeaf and the param fallback can both be absent temporarily. The narrow tab bar uses a negative top margin, so when it is incorrectly visible it overlays the bottom composer area:

App/src/styles/utils/index.ts

Lines 2301 to 2304 in a8dad1c

	getTabBarNarrowStyle: (safeAreaPaddingBottom: number): ViewStyle => ({
	overflow: 'visible',
	marginTop: -(variables.bottomTabHeight + safeAreaPaddingBottom),
	paddingBottom: safeAreaPaddingBottom,

Second, shouldShowComposeInput is persisted even though it is only keyboard/edit-mode UI state. The keyboard-aware helper writes false while hiding the composer and writes true only after the keyboard hide event:

App/src/libs/setShouldShowComposeInputKeyboardAware/setShouldShowComposeInputKeyboardAwareBuilder.ts

Lines 16 to 29 in a8dad1c

	if (!shouldShow) {
	Composer.setShouldShowComposeInput(false);
	return;
	}
	// If keyboard is already hidden, we should show composer immediately because keyboardDidHide event won't be called
	if (!Keyboard.isVisible()) {
	Composer.setShouldShowComposeInput(true);
	return;
	}
	keyboardEventListener = Keyboard.addListener(keyboardEvent, () => {
	Composer.setShouldShowComposeInput(true);
	keyboardEventListener?.remove();

Since SHOULD_SHOW_COMPOSE_INPUT has an initial value but is not listed as a RAM-only key, a force close can relaunch with the stale persisted false:

App/src/setup/index.ts

Lines 49 to 73 in a8dad1c

	[ONYXKEYS.SHOULD_SHOW_COMPOSE_INPUT]: true,
	[ONYXKEYS.MODAL]: {
	isVisible: false,
	willAlertModalBecomeVisible: false,
	},
	// Ensure the Supportal permission modal doesn't persist across reloads
	[ONYXKEYS.SUPPORTAL_PERMISSION_DENIED]: null,
	[ONYXKEYS.IS_OPEN_APP_FAILURE_MODAL_OPEN]: false,
	},
	skippableCollectionMemberIDs: CONST.SKIPPABLE_COLLECTION_MEMBER_IDS,
	snapshotMergeKeys: ['pendingAction', 'pendingFields'],
	ramOnlyKeys: [
	ONYXKEYS.RAM_ONLY_ARE_TRANSLATIONS_LOADING,
	ONYXKEYS.RAM_ONLY_MOBILE_SELECTION_MODE,
	ONYXKEYS.RAM_ONLY_IS_SIDEBAR_LOADED,
	ONYXKEYS.DERIVED.RAM_ONLY_SORTED_REPORT_ACTIONS,
	ONYXKEYS.RAM_ONLY_IS_CHECKING_PUBLIC_ROOM,
	ONYXKEYS.RAM_ONLY_UPDATE_AVAILABLE,
	ONYXKEYS.RAM_ONLY_UPDATE_REQUIRED,
	ONYXKEYS.RAM_ONLY_IS_SEARCHING_FOR_REPORTS,
	ONYXKEYS.RAM_ONLY_WALLET_ONFIDO,
	ONYXKEYS.COLLECTION.RAM_ONLY_REPORT_LOADING_STATE,
	ONYXKEYS.RAM_ONLY_PLAID_LINK_TOKEN,
	ONYXKEYS.COLLECTION.RAM_ONLY_ISSUE_NEW_EXPENSIFY_CARD,
	],

On small screens, ReportFooter only renders the composer when this key is true:

App/src/pages/inbox/report/ReportFooter.tsx

Lines 61 to 90 in a8dad1c

	const [shouldShowComposeInput = false] = useOnyx(ONYXKEYS.SHOULD_SHOW_COMPOSE_INPUT);
	const [isBlockedFromChat] = useOnyx(ONYXKEYS.NVP_BLOCKED_FROM_CHAT, {
	selector: isBlockedFromChatSelector,
	});
	const [policyRole] = useOnyx(`${ONYXKEYS.COLLECTION.POLICY}${report?.policyID}`, {
	selector: policyRoleSelector,
	});
	const [isComposerFullSize = false] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT_IS_COMPOSER_FULL_SIZE}${reportIDFromRoute}`);
	const [isLoadingInitialReportActions] = useOnyx(`${ONYXKEYS.COLLECTION.RAM_ONLY_REPORT_LOADING_STATE}${reportIDFromRoute}`, {
	selector: isLoadingInitialReportActionsSelector,
	});
	const isUserPolicyAdmin = policyRole === CONST.POLICY.ROLE.ADMIN;
	const isArchivedRoom = isArchivedNonExpenseReport(report, isReportArchived);
	const shouldShowComposerOptimistically = !isAnonymousUser && isPublicRoom(report) && !!isLoadingInitialReportActions;
	const canPerformWriteAction = canUserPerformWriteAction(report, isReportArchived) ?? shouldShowComposerOptimistically;
	const shouldHideComposer = !canPerformWriteAction || isBlockedFromChat;
	const canWriteInReport = canWriteInReportUtil(report);
	const isSystemChat = isSystemChatUtil(report);
	const isAdminsOnlyPostingRoom = isAdminsOnlyPostingRoomUtil(report);
	if (!isCurrentReportLoadedFromOnyx || !report || !reportIDFromRoute) {
	return null;
	}
	const chatFooterStyles = {...styles.chatFooter, minHeight: !isOffline ? CONST.CHAT_FOOTER_MIN_HEIGHT : 0};
	// Happy path — user can compose
	if (!shouldHideComposer && (shouldShowComposeInput || !isSmallScreenWidth)) {

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

Fix both transient states at their source:

• In TabNavigatorBar.tsx, stop treating an unresolved Reports split leaf as tab-root. Use the focused leaf first, then the pushed target leaf, and only fall back to the active tab route name for tabs where the wrapper itself is safe to display as root.
• In src/setup/index.ts, add ONYXKEYS.SHOULD_SHOW_COMPOSE_INPUT to ramOnlyKeys.
• Remove ONYXKEYS.SHOULD_SHOW_COMPOSE_INPUT from preservation lists in src/libs/actions/App.ts and src/libs/actions/QueuedOnyxUpdates.ts, because this key should not survive resets or logged-out queued-update filtering.
• Add focused tests for TabNavigatorBar visibility when the active route is REPORTS_SPLIT_NAVIGATOR with no hydrated child state, with a pushed Report target, and with normal tab-root routes.
• Add or update an Onyx setup test to assert SHOULD_SHOW_COMPOSE_INPUT is RAM-only and starts as true.

MelvinBot’s proposal identified the correct areas, but it leaves one navigation fix as an option that is already present in the code path (getPushTargetLeaf) and suggests resetting the composer key on background as an alternative. Resetting on background is weaker than making the key RAM-only because the bug is caused by persisting transient keyboard state in the first place.

What alternative solutions did you explore? (Optional)

[github-actions]

⚠️ @nabi-ebrahimi Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).