Spend - Filter popover closes after selecting month in RHP

[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): sdjsodnjiodsjsoinj1@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Search

Action Performed:

1. Go to staging.new.expensify.com
2. Go to Spend > Expenses.
3. Click Filters.
4. Hover over Date.
5. Click Custom date.
6. Click on the month.
7. Select another month.

Expected Result:

Filter popover will not close after selecting month in RHP.

Actual Result:

Filter popover closes after selecting month in RHP.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7163051_1779753300774.1.mp4

View all open jobs on GitHub

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

[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/1851d60168754ac6df12513f0be14fa762dc937aceff366786723688f597ba1c

[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

What is the root cause of that problem?

Both the filter popover and the MonthPickerModal use shouldHandleNavigationBack, which makes each Modal push a browser history entry and register a popstate listener that calls onClose (Modal/index.tsx:65-73).

When a month is selected, the MonthPickerModal closes → its Modal calls window.history.back() (Modal/index.tsx:54-58) → the resulting popstate event is caught by the filter popover's Modal-level listener (Modal/index.tsx:42-44) → the filter popover closes.

The existing shouldCloseWhenBrowserNavigationChanged={false} on FilterPopupButton.tsx:138 only guards the Popover-level popstate listener in Popover/index.tsx, not the Modal-level one. So the filter popover is still vulnerable to popstate events from nested modals closing. The same issue affects YearPickerModal.

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

The Modal's handlePopState listener should verify that the popstate event is actually meant for it before calling onClose. One approach: when showModal pushes the history entry, tag it with a unique identifier (e.g., a random ID stored in window.history.state). When handlePopState fires, check whether the current window.history.state still has the expected tag — if it doesn't match, the popstate was consumed by a different modal's history.back() and should be ignored.

Alternatively, the simpler fix: when shouldCloseWhenBrowserNavigationChanged is false, skip registering the Modal-level popstate listener in showModal as well (currently only the Popover-level listener respects this prop). This would require threading the prop through from PopoverWithMeasuredContent → Popover → Modal.

What alternative solutions did you explore? (Optional)

• Removing shouldHandleNavigationBack from MonthPickerModal/YearPickerModal — this would break standalone back-navigation for those modals when opened outside a popover context.
• Removing shouldHandleNavigationBack from FilterPopupButton — this would break back-button behavior for the filter popover itself.

---

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]

One implementation detail from checking the video/code: the month row click only changes local CalendarPicker.currentDateView; it should not write any dateOn/dateAfter/dateBefore/dateRange value or search query until a day/apply happens. So a low-risk patch can be scoped to the desktop filter popover history handling: keep shouldHandleNavigationBack for the small-screen/fullscreen filter modal path, but do not install that parent popstate listener for the desktop popover that hosts the Month/Year RHPs. I would also make the popover onClose an explicit close instead of toggleOverlay, so any late child-modal close event cannot flip it open/closed unexpectedly.

Verified against the attached clip: after selecting a month, the child RHP closes and the whole filter UI drops back to the table, before any date value is applied.