Android - Expense - Last category is hidden behind device navigation bar

[jponikarchuk]

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.21-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #76264
Email or phone of affected tester (no customers): sjiondjsondjoisjsojdos@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: Money Requests

Action Performed:

Precondition:

• Set device navigation to navigation bar instead of swipe gestures.

1. Launch Expensify app.
2. Go to workspace chat.
3. Create two expenses.
4. Open the expense report.
5. Select both expenses by long tapping on the expense > tap Select.
6. Tap dropdown button > Edit expenses.
7. Tap Category.
8. Scroll down to the bottom of the list.

Expected Result:

The last category will appear above device navigation bar.

Actual Result:

The last category is hidden 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

1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @stephanieelliott

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

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

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #76264 - "Feat: bulk edit multiple" by @waterim (High confidence)
Related Issues: None

Recommendation: REVERT

This is a clear regression introduced by the bulk edit feature. The PR can be cleanly reverted to unblock the deploy, and the fix can be applied in a follow-up PR.

Labels: Keeping DeployBlockerCash (blocks App deploy). Not removing any labels since this is a frontend bug that blocks the mobile app deployment.

Detailed Analysis

Evidence

PR #76264 introduced bulk edit functionality for expenses, including several new pages:

• SearchEditMultipleCategoryPage.tsx
• SearchEditMultipleTagPage.tsx
• SearchEditMultipleTaxPage.tsx

The issue specifically mentions:

• Category selection page (step 7: "Tap Category")
• Last category is hidden behind device navigation bar (Android)
• Only reproducible on staging (where PR Feat: bulk edit multiple #76264 exists)
• Uses Android device with navigation bar (not swipe gestures)

Verification

All three new picker pages follow the same pattern:

<ScreenWrapper
    includeSafeAreaPaddingBottom={false}  // Disables safe area padding
    shouldEnableMaxHeight
>
    <HeaderWithBackButton ... />
    <CategoryPicker
        policyID={policyID}
        selectedCategory={currentCategory}
        onSubmit={saveCategory}
        // MISSING: addBottomSafeAreaPadding={true}
    />
</ScreenWrapper>

The CategoryPicker, TagPicker, and TaxPicker components all support an addBottomSafeAreaPadding prop that gets passed to SelectionListWithSections to add bottom padding. However, the new bulk edit pages do NOT pass this prop, causing the list content to extend behind the Android navigation bar.

Files affected:

• /home/runner/_work/App/App/src/pages/Search/SearchEditMultiple/SearchEditMultipleCategoryPage.tsx (line 52)
• /home/runner/_work/App/App/src/pages/Search/SearchEditMultiple/SearchEditMultipleTagPage.tsx (line 73)
• /home/runner/_work/App/App/src/pages/Search/SearchEditMultiple/SearchEditMultipleTaxPage.tsx (line 63)

Root Cause

When ScreenWrapper has includeSafeAreaPaddingBottom={false}, the responsibility for adding bottom safe area padding falls to the child components. The picker components have this capability via the addBottomSafeAreaPadding prop, but it was not passed in the implementation.

On Android devices with a navigation bar (not using gesture navigation), the system navigation bar overlays the bottom of the screen, hiding the last items in scrollable lists when safe area padding is not applied.

[MelvinBot]

Proposal

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

On Android devices using a navigation bar (not gesture navigation), the last category in the bulk edit category picker is hidden behind the device navigation bar. The user cannot see or select the final items in the list.

What is the root cause of that problem?

SearchEditMultipleCategoryPage sets includeSafeAreaPaddingBottom={false} on its ScreenWrapper (line 44), which tells ScreenWrapper not to apply bottom safe area padding at the container level. This is a valid pattern — but it requires the inner scrollable content to handle the padding itself.

The problem is that CategoryPicker is rendered without the addBottomSafeAreaPadding prop (lines 52–56), so it defaults to false. This means BaseSelectionList never applies safeAreaPaddingBottomStyle to the list container (the condition addBottomSafeAreaPadding && paddingBottomStyle evaluates to false).

Neither the ScreenWrapper nor the SelectionList accounts for the bottom safe area, so the list content extends behind the Android navigation bar.

For comparison, CategorySelectorModal correctly passes addBottomSafeAreaPadding to its CategoryPicker, which is why other category pickers in the app work fine.

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

In src/pages/Search/SearchEditMultiple/SearchEditMultipleCategoryPage.tsx, pass addBottomSafeAreaPadding to CategoryPicker:

<CategoryPicker
    policyID={policyID}
    selectedCategory={currentCategory}
    onSubmit={saveCategory}
    addBottomSafeAreaPadding
/>

The same issue likely affects the other SearchEditMultiple pages that use scrollable lists. Specifically:

• SearchEditMultipleTaxPage.tsx — uses TaxPicker, which already supports addBottomSafeAreaPadding. Pass it there too.
• SearchEditMultipleTagPage.tsx — uses TagPicker, which does not currently support addBottomSafeAreaPadding. The prop would need to be threaded through TagPicker to its inner SelectionList.
• SearchEditMultipleBooleanPage.tsx — uses SelectionList directly. Pass addBottomSafeAreaPadding to it.

All of these pages set includeSafeAreaPaddingBottom={false} but none pass addBottomSafeAreaPadding to their list components.

What alternative solutions did you explore? (Optional)

Removing includeSafeAreaPaddingBottom={false} from the ScreenWrapper would also fix it by letting the wrapper handle the padding. However, this is a blunter approach — applying padding to the list's content container (via addBottomSafeAreaPadding) is the established pattern in the codebase and ensures the list scrolls properly while rendering edge-to-edge.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.