Android - Copilot - Account switcher list appears behind device navigation bar

[applause-bot]

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.4.16-1
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #88578
Email or phone of affected tester (no customers): sdjnoisdjdosijsonssjo@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Samsung Galaxy S25 FE / Android 16
App Component: User Settings

Action Performed:

Precondition:

• Set device navigation to bar instead of gestures.
• Add 6 copilots to the account

1. Launch Expensify app.
2. Go to Account.
3. Open account switcher.
4. Scroll down the list.

Expected Result:

Account switcher list will appear above device navigation bar.

Actual Result:

Account switcher list appears behind device navigation bar.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

To be added by Applause Leads

View all open jobs on GitHub

Bug7185643_1781884864840.Screen_Recording_20260619_235804_Expensify.mp4

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7185643

Issue Owner

Current Issue Owner: @truph01

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/9137123d4f5b1f841386fd1c6ffbb612fc179340ed02df837d293151f2f4d2a9

[melvin-bot]

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

[melvin-bot]

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

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

[MelvinBot]

Proposal

🤖 Generated by MelvinBot · confidence: medium-high (mechanism verified in code; the exact in-modal inset value of 0 should be confirmed on an Android device with a 3-button nav bar).

Reproduce

Android, 3-button navigation bar, 6 copilots → open the account switcher and scroll. The bottom of the list renders behind the nav bar instead of above it.

Root cause

Regression from Expensify/App#88578 ("fix: bottom-safe-area-padding-in-modals (part 1)"), which is why this is staging-only (the PR hasn't reached production).

That PR changed AccountSwitcher.tsx to drop the hardcoded scrollContainerStyle={styles.pb4} and instead pass enableEdgeToEdgeBottomSafeAreaPadding. That flag flips the modal into edge-to-edge mode, and in that mode the modal stops adding its own bottom safe-area padding — see BaseModal.tsx:259-265:

const isUsingEdgeToEdgeMode = enableEdgeToEdgeBottomSafeAreaPadding !== undefined;
...
shouldAddBottomSafeAreaPadding: !isUsingEdgeToEdgeMode && ...,

The bottom inset is now expected to be applied by the child ScrollView addBottomSafeAreaPadding instead. But that ScrollView is rendered inside the native RN Modal (ReanimatedModal/index.tsx:5), and there is no SafeAreaProvider/SafeAreaInsetsContext re-established inside that modal window. So useSafeAreaInsets().bottom resolves to ~0 there, and paddingBottom = insets.bottom * 1 = 0 (useSafeAreaPaddings.ts:36,48).

Net effect: the modal padding was turned off, and its intended replacement evaluates to 0 → no bottom padding at all → scrollable content slides under the nav bar. Gesture nav has a near-zero inset, so it only shows with a 3-button nav bar.

The strongest tell that the inset is unavailable inside the modal: BaseModal reads insets from the outer tree (where they're correct) and used them for the modal's own padding pre-PR — edge-to-edge mode discards that correct value and relies on a child that can't see it.

Why the other 5 modals in the PR don't obviously break

AccountSwitcher is the only one combining shouldUseScrollView + a tall maxHeight: windowHeight / 2 container that actually reaches the nav bar with enough rows to scroll. The same latent zero-inset issue likely affects the others but isn't visible unless their content extends to the bottom edge. Worth spot-checking before a broad fix.

Solution

For the deploy blocker, the lowest-risk fix is to revert just the AccountSwitcher change at AccountSwitcher.tsx:305-310: restore scrollContainerStyle={styles.pb4} and remove enableEdgeToEdgeBottomSafeAreaPadding. This brings back the modal's own bottom safe-area padding (known-good in production).

Alternative (proper edge-to-edge follow-up)

Keep edge-to-edge but make the inset reach the content inside the modal — e.g. in BaseModal (edge-to-edge branch) wrap the children in <SafeAreaInsetsContext.Provider value={insets}> seeded with the already-correct outer insets, or pass the outer insets.bottom down as additionalPaddingBottom. This would also harden the other 5 modals. Higher risk; better as a non-blocker PR.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/94081) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.