Android - Spend - Filter page closes after tapping device back button

[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.3.82-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #90029
Email or phone of affected tester (no customers): jodijojosjojso@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: Search

Action Performed:

1. Launch Expensify app.
2. Go to Spend > Expenses.
3. Tap Filters.
4. Tap Type
5. Tap device back button.

Expected Result:

App will return to main filter page after tapping device back button.

Actual Result:

Filter page closes completely after tapping device back button.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7163055_1779753303940.8.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7163055

[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/f9aef4cb3c1be1c45cdd0b36a8b9d8a55cbece2472eef6b5c403fcb3f80fc76e

[melvin-bot]

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

[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

Problem: PR #90029 replaced the old React Navigation-based filter screens with a single modal that manages sub-page state via useState. The Android hardware back button is handled by ReanimatedModal's BackHandler, which calls closeTop() — unconditionally closing the entire modal. There is no intermediate handler that checks whether a sub-filter (e.g. Type) is currently displayed and should navigate back to the filter list first.

Solution: Add a BackHandler in AdvancedFiltersFullscreen.tsx that intercepts the hardware back press when selectedFilter is not null, clears the selection (returning to the filter list), and returns true to prevent the modal from closing.

This mirrors the existing logic in the onBackButtonPress callback on line 51-57 — which correctly handles the visual back button but is never invoked by the Android hardware key.

// Add useEffect with BackHandler in AdvancedFiltersFullscreen
useEffect(() => {
    if (!selectedFilter) {
        return;
    }
    const subscription = BackHandler.addEventListener('hardwareBackPress', () => {
        setSelectedFilter(null);
        return true;
    });
    return () => subscription.remove();
}, [selectedFilter]);

Investigation details

Why the old code worked: The previous implementation used React Navigation routes (search/filters/:filterKey?/:subPage? — ROUTES.ts:725-734). Navigating to a filter sub-page was a proper navigation stack push, so the Android back button naturally popped the stack.

Why the new code breaks: AdvancedFiltersFullscreen.tsx:32 uses useState<SearchFilter['key'] | null>(null) for sub-page navigation inside a single modal. The modal's BackHandler in ReanimatedModal/index.tsx:67-76 fires closeTop() (from BaseModal.tsx:341), closing the entire modal without checking internal sub-filter state.

Data flow:

1. User opens Filters → modal shown → selectedFilter = null (FilterList displayed)
2. User taps "Type" → setSelectedFilter('type') → SelectedFilterContent displayed
3. User presses Android hardware back button
4. ReanimatedModal BackHandler → closeTop() → entire modal closes
5. Expected: Should check selectedFilter, call setSelectedFilter(null), return to filter list

---

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.

[godzillaxbox19982014-lgtm]

Small implementation delta to the bot's write-up: I would use the existing useAndroidBackButtonHandler hook in AdvancedFiltersFullscreen instead of adding a raw BackHandler effect there.

That lets us share one handleBackButtonPress with HeaderWithBackButton: when selectedFilter is set, clear it and return true; when it is already on the main Filters list, call closeOverlay() and return true. This keeps the visual back arrow and Android device back on the same path, avoids a second native listener pattern, and gives a clear regression test: first device back from Type must keep the overlay open and show the Filters list, second device back from the Filters list should close it.