[Due for payment 2026-06-26] Spend - Sidebar is stuck and does not collapse after deleting saved search

[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.0-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: #91974
Email or phone of affected tester (no customers): jsodinjosdjsoinjsiojs@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. Apply any filter.
4. Click Save > Save view.
5. Click Collapse button to collapse the sidebar.
6. Hover over the sidebar.
7. Click 3-dot menu next to saved search > Delete > Delete.
8. Do not hover over the sidebar after deleting the saved search.

Expected Result:

Sidebar will auto collapse after deleting saved search when cursor is not hovered over the sidebar.

Actual Result:

Sidebar is stuck and does not collapse after deleting saved search when cursor is not hovered over the sidebar.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7172880_1780683526693.1.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @mallenexpensify

[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/73b3b077b93c10dccc165d389bcd14a9f138bf6c541b66dbb32035dcaa1b89ae

[melvin-bot]

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

[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

⚠️ Medium confidence — root cause is verified from the code paths; the precise pointer-event suppression during the modal flow is inferred (not log/UI-confirmed), but it cleanly explains every symptom.

This is a frontend-only regression in Expensify/App from PR #91974 (collapsible Spend sidebar), so it can be fixed here.

What is the root cause of that problem?

The collapsed sidebar "peek" state is a module-level flag, isPeeking, and the only thing that clears it during normal use is the outer Hoverable's onHoverOut → endPeek (i.e. a DOM mouseleave on the sidebar).

When you delete a saved search, two portal overlays open on top of the sidebar in sequence — the 3‑dot popover and then the delete‑confirmation modal (showDeleteModal). Because the cursor moves onto those overlays (rendered outside the sidebar's DOM subtree) and the row it was over is removed on deletion, the sidebar's onMouseLeave never fires. After the modal closes with the cursor parked off the sidebar, isPeeking is stuck true, so isVisuallyCollapsed stays false and the sidebar remains expanded. Only a fresh hover‑in‑then‑out resets it.

Evidence / data flow

• Peek is set on hover‑in of the inner menu (SearchSidebar.tsx:114) and only cleared by endPeek/toggleSidebar/narrow‑layout (SearchSidebarCollapseStore.ts:58-65).
• endPeek is wired to exactly one user-facing trigger in wide layout: the outer Hoverable onHoverOut (SearchSidebar.tsx:102). There is no re‑evaluation of hover when a popover/modal opened from the sidebar closes.
• Hoverable reacts only to React onMouseEnter/onMouseLeave (ActiveHoverable.tsx:108-116); a stationary cursor with overlays mounting/unmounting on top produces no mouseleave.
• Alternative considered: that endPeek fires too early and the bug is a re‑expand. Ruled out — the symptom is stuck expanded, and there is no code path that re‑sets isPeeking after deletion.
• This is also not specific to delete: rename/share (any sidebar popover that ends with the cursor off the rail) can leave the same stuck‑peek state.

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

Stop relying solely on the React onMouseLeave to dismiss the peek. While isPeeking is true, attach a document‑level pointermove (or mouseover) listener that calls endPeek() when the pointer is not over the sidebar element (compare against the sidebar's bounding rect / elementRef). After the confirmation modal closes with the cursor anywhere off the rail, the next pointer movement collapses it — matching the expected behavior and covering all popover/modal flows, not just delete.

What alternative solutions did you explore? (Optional)

• Targeted re-check on modal close: when the 3‑dot popover/confirm modal that originated in the sidebar dismisses, re‑evaluate elementRef.current?.matches(':hover') and endPeek() if not hovered. Smaller blast radius but only fixes the known overlay paths.
• Reset peek in the delete flow (call endPeek() after showDeleteModal confirms): a band‑aid that doesn't cover rename/share or future sidebar popovers.

Related issues

• [Due for payment 2026-06-25?] [CFI] [$250] Add collapsable sidebar functionality on Spend screen #91553 — the parent feature issue for the collapsible Spend sidebar (source of PR Add collapsible Spend sidebar #91974).

---

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

[blimpich]

@KJ21-ENG can you comment on this issue so I can assign you?