Skip to content

[Due for payment 2026-03-30] Expense - Expense auto enters selection mode after clicking Move to report #85537

New issue
New issue
Closed
Closed
[Due for payment 2026-03-30] Expense - Expense auto enters selection mode after clicking Move to report#85537
Assignees
mallenexpensifyaldo-expensify
Labels
Awaiting PaymentAuto-added when associated PR is deployed to productionBugSomething is broken. Auto assigns a BugZero manager.DailyKSv2Engineering

Description

@jponikarchuk
jponikarchuk
opened on Mar 17, 2026

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.39-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: #85038
Email or phone of affected tester (no customers): sjdoisjoisdjonsnjo@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

  1. Go to staging.new.expensify.com
  2. Go to workspace chat.
  3. Create two expenses.
  4. Open expense report.
  5. Open any expense.
  6. Click More > Move to report.
  7. Close the RHP.
  8. Close expense details RHP.

Expected Result:

Expense will not enter selection mode.

Actual Result:

Expense auto enters selection mode after clicking Move to report, even after RHP is closed.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Activity

  1. jponikarchuk
    added this to #expensify-bugson Mar 17, 2026
  2. jponikarchuk
    added
    DeployBlockerCashThis issue or pull request should block deployment
    BugSomething is broken. Auto assigns a BugZero manager.
    on Mar 17, 2026

  3. melvin-bot commented on Mar 17, 2026

    @melvin-bot
    melvin-botBot
    on Mar 17, 2026 – with Melvin Bot

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

  4. melvin-bot
    assigned
    aldo-expensify
    on Mar 17, 2026

  5. melvin-bot commented on Mar 17, 2026

    @melvin-bot
    melvin-botBot
    on Mar 17, 2026 – with Melvin Bot

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

  6. github-actions
    added
    Engineering
    HourlyKSv2
    on Mar 17, 2026

  7. github-actions commented on Mar 17, 2026

    @github-actions
    github-actionsBot
    on Mar 17, 2026 – with GitHub Actions
    Contributor

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

  8. OSBotify commented on Mar 17, 2026

    @OSBotify
    OSBotify
    on Mar 17, 2026
    Contributor

    Investigation Summary

    Classification: Frontend bug
    Causing PR: #85038 - "Feat: Add 'Move to report' in the 'More' menu of a one-expense report" by @nyomanjyotisa (High confidence)
    Related Issues: None

    Recommendation: REVERT

    PR #85038 introduced a "Move to report" option in the More menu for single-expense reports. When this action is triggered, it calls setSelectedTransactions([transactionID]) to mark the transaction for moving. However, the selected transaction state persists in SearchContext even after the RHP is closed. The useHandleSelectionMode hook then detects this populated selectedTransactionIDs array and automatically activates mobile selection mode, causing the expense to unexpectedly enter selection mode.

    This is the exact behavior reported in the issue: "Expense auto enters selection mode after clicking Move to report, even after RHP is closed."

    Labels: Keeping DeployBlockerCash (frontend bug blocking App deploy)

    Detailed Analysis

    Evidence

    Verification

    PR #85038 modified the following files related to the bug:

    • src/components/MoneyReportHeader.tsx - Added Move Expense secondary action (line 1120-1137 in diff)
    • src/components/MoneyRequestHeader.tsx - Added Move Expense secondary action (line 211-236 in diff)
    • src/components/MoneyRequestReportView/MoneyRequestReportTransactionList.tsx - Uses useHandleSelectionMode hook
    • src/hooks/useHandleSelectionMode.ts - Automatically turns on selection mode when selectedTransactionIDs.length > 0

    Root Cause

    When the user clicks "Move to report" from the More menu:

    1. MoneyReportHeader.tsx (line 134 in diff):
    setSelectedTransactions([transactionToMove.transactionID]);
Navigation.navigate(ROUTES.MONEY_REQUEST_EDIT_REPORT.getRoute(...));
    1. MoneyRequestHeader.tsx (line 232 in diff):
    setSelectedTransactions([transaction.transactionID]);
Navigation.navigate(ROUTES.MONEY_REQUEST_EDIT_REPORT.getRoute(...));

    These calls populate the selectedTransactionIDs in SearchContext, which persists even after navigation or RHP closure.

    1. MoneyRequestReportTransactionList.tsx (line 225):
    const {selectedTransactionIDs} = useSearchStateContext();
useHandleSelectionMode(selectedTransactionIDs);
    1. useHandleSelectionMode.ts (lines 30-31):
    if (selectedItems.length > 0 && !isMobileSelectionModeEnabled) {
    turnOnMobileSelectionMode();
}

    When the user returns to the expense report view after closing the RHP, useHandleSelectionMode detects the persisted selected transaction and automatically activates mobile selection mode, causing the unexpected behavior.

    The fix should either:

    • Clear selected transactions when the "Move to report" flow completes or is cancelled
    • Use a different mechanism for tracking which transaction to move that doesn't trigger selection mode
    • Prevent useHandleSelectionMode from activating when transactions are selected for non-selection-mode purposes

  9. MelvinBot commented on Mar 17, 2026

    @MelvinBot
    MelvinBot
    on Mar 17, 2026
    Contributor

    Proposal

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

    After clicking "More > Move to report" on an expense in an expense report, then closing the RHP without selecting a target report, the expense report auto-enters selection mode. The user sees the selection UI (checkboxes, "Select multiple" header) even though they never intended to enter selection mode.

    What is the root cause of that problem?

    When "Move to report" is clicked, MoneyRequestHeader.tsx (line 681) calls setSelectedTransactions([transaction.transactionID]) to populate the global SearchContext with the transaction, then navigates to the IOURequestEditReport RHP.

    Meanwhile, MoneyRequestReportTransactionList.tsx (line 225) uses the useHandleSelectionMode hook, which automatically calls turnOnMobileSelectionMode() when it detects selectedTransactionIDs.length > 0 (useHandleSelectionMode.ts line 30).

    The problem is that IOURequestEditReport.tsx has no cleanup on unmount. It only calls turnOffMobileSelectionMode() and clearSelectedTransactions() inside the selectReport and removeFromReport handlers — the "happy path" where the user completes the move action (lines 87-112). When the user dismisses the RHP without taking action (back button, swipe), the component unmounts silently, leaving selectedTransactionIDs populated and mobile selection mode enabled.

    Additionally, the useFocusEffect cleanup in MoneyRequestReportTransactionList.tsx (line 243-252) intentionally skips clearing when navigating to the RHP, and doesn't re-clear when focus returns.

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

    Add a useEffect cleanup in IOURequestEditReport.tsx that calls turnOffMobileSelectionMode() and clearSelectedTransactions(true) on unmount. This ensures that when the user dismisses the RHP without completing the move, the selection state is properly cleaned up. On the happy path where the user does complete the move, these functions will have already been called, so calling them again on unmount is a safe no-op.

    What alternative solutions did you explore? (Optional)

    1. Enhancing navigateBack in IOURequestEditReportCommon.tsx — This would only cover the back button case, not all dismissal paths (swipe, navigation to another screen, etc.). A useEffect cleanup on unmount is more robust since it covers all dismissal scenarios.

    2. Clearing state in the useFocusEffect of MoneyRequestReportTransactionList — This would mean modifying the focus/blur logic that intentionally preserves selections when navigating to the RHP, which could have unintended side effects on other flows that use selection mode with the RHP open.

    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.

  10. ZhenjaHorbach commented on Mar 17, 2026

    @ZhenjaHorbach
    ZhenjaHorbach
    on Mar 17, 2026
    Contributor

    CC: @nyomanjyotisa

  11. ZhenjaHorbach commented on Mar 17, 2026

    @ZhenjaHorbach
    ZhenjaHorbach
    on Mar 17, 2026
    Contributor

    But as for me, it's not a deploy blocker

  12. nyomanjyotisa commented on Mar 17, 2026

    @nyomanjyotisa
    nyomanjyotisa
    on Mar 17, 2026
    Member

    Looking 👀
    Also, I agree that this is not a deploy blocker

  13. aldo-expensify commented on Mar 17, 2026

    @aldo-expensify
    aldo-expensify
    on Mar 17, 2026
    Contributor

    Are you planing to work on a PR to fix it? If it is the only issue, we could try to fix it instead of reverting

  14. 10 remaining items

  15. melvin-bot
    removed
    ReviewingHas a PR in review
    on Mar 23, 2026

  16. melvin-bot commented on Mar 23, 2026

    @melvin-bot
    melvin-botBot
    on Mar 23, 2026 – with Melvin Bot

    Reviewing label has been removed, please complete the "BugZero Checklist".

  17. melvin-bot commented on Mar 23, 2026

    @melvin-bot
    melvin-botBot
    on Mar 23, 2026 – with Melvin Bot

    The solution for this issue has been 🚀 deployed to production 🚀 in version 9.3.41-4 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

    If no regressions arise, payment will be issued on 2026-03-30. 🎊

  18. melvin-bot commented on Mar 23, 2026

    @melvin-bot
    melvin-botBot
    on Mar 23, 2026 – with Melvin Bot

    @aldo-expensify The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

  19. melvin-bot
    assigned
    mallenexpensify
    on Mar 23, 2026

  20. melvin-bot commented on Mar 23, 2026

    @melvin-bot
    melvin-botBot
    on Mar 23, 2026 – with Melvin Bot

    Triggered auto assignment to @mallenexpensify (Awaiting Payment)

  21. melvin-bot
    added
    DailyKSv2
    Overdue
    and removed
    WeeklyKSv2
    on Mar 29, 2026

  22. melvin-bot commented on Mar 30, 2026

    @melvin-bot
    melvin-botBot
    on Mar 30, 2026 – with Melvin Bot

    Skipping the payment summary for this issue since all the assignees are employees or vendors. If this is incorrect, please manually add the payment summary SO.

  23. melvin-bot commented on Mar 30, 2026

    @melvin-bot
    melvin-botBot
    on Mar 30, 2026 – with Melvin Bot

    Skipping the payment summary for this issue since all the assignees are employees or vendors. If this is incorrect, please manually add the payment summary SO.

  24. mallenexpensify commented on Mar 31, 2026

    @mallenexpensify
    mallenexpensify
    on Mar 31, 2026
    Contributor

    Closing, the issue linked to the offending PR has been commented on

  25. mallenexpensify
    closed this as completedon Mar 31, 2026
  26. melvin-bot
    removed
    Overdue
    on Mar 31, 2026
  27. github-project-automation
    moved this to Done in #expensify-bugson Mar 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Awaiting PaymentAuto-added when associated PR is deployed to productionBugSomething is broken. Auto assigns a BugZero manager.DailyKSv2Engineering

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions