Skip to content

[Due for payment 2026-05-20] [$250] Android - Spend - User is navigated out of report after adding an existing expense. #89352

Closed

Description

@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.65-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: #85225
Email or phone of affected tester (no customers): ibellicotest+2250@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app)
App Component: Search

Action Performed:

Prerequisite: Account has at least one workspace.

  1. Open the Expensify app.
  2. Open any workspace chat.
  3. Create a manual expense.
  4. Create an empty report.
  5. Navigate to "Spend" > "Reports"
  6. Open the empty report created on step 4.
  7. Tap on "Add Expense" > "Add existing expense"
  8. Select the expense created on step 3 and add it to report.
  9. Note that after expense is added, user is navigated out of report, landing on "Reports" section again.

Expected Result:

User should remain on report after adding an existing expense to it.

Actual Result:

User is navigated out of report after adding an existing expense to it while on "Reports" section on "Spend".

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

Upwork Automation - Do Not Edit
  • Upwork Job URL: https://www.upwork.com/jobs/~022050258929939771054
  • Upwork Job ID: 2050258929939771054
  • Last Price Increase: 2026-05-01
Issue OwnerCurrent Issue Owner: @mallenexpensify

Activity

  1. added
    DeployBlockerCashThis issue or pull request should block deployment
    BugSomething is broken. Auto assigns a BugZero manager.
    on May 1, 2026
  2. melvin-bot commented on May 1, 2026

    @melvin-bot

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

  3. melvin-bot commented on May 1, 2026

    @melvin-bot

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

  4. github-actions commented on May 1, 2026

    @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.
  5. OSBotify commented on May 1, 2026

    @OSBotify
    Contributor

    Investigation Summary

    Classification: Frontend bug
    Causing PR: #85225 - "Feat: Change Add unreported expense to Add existing expense in a report" by @nyomanjyotisa (High confidence)
    Related Issues: #84130 (the feature request this PR implements)

    Recommendation: REVERT

    PR #85225 introduced this regression and can be cleanly reverted. The bug is staging-only (new feature, not in production), and the navigation issue is contained within this PR's scope.

    Assigned: @nyomanjyotisa (PR author), @sobitneupane, @puneetlath (approving reviewers)
    Labels: DeployBlockerCash kept — this is a Frontend bug in Expensify/App. No label changes required; the existing label is correct.

    Detailed Analysis

    Evidence

    Verification

    Root Cause

    When the user is on "Spend > Reports" and opens a report, then invokes "Add Expense > Add existing expense", the modal is opened as a RHP. On narrow layout (Android HybridApp), AddExistingExpenseFooter.handleConfirm calls Navigation.dismissToSuperWideRHP(), which on narrow layouts resolves to dismissModal(). This dismisses the entire RHP modal stack, navigating the user back to the previous fullscreen route — which is "Reports" — rather than keeping them on the report they were viewing.

    The underlying dismissToSuperWideRHP call was present in the prior AddUnreportedExpenseFooter as well, but the specific scenario that reproduces the bug (opening the flow from a report in "Spend > Reports" then adding a Draft expense) is new behavior enabled by this PR. The PR expanded the eligible transactions to include expenses on open expense reports (Draft status), creating a new user path that surfaces this dismiss-navigates-away behavior in the "Spend > Reports" context.

  6. MelvinBot commented on May 1, 2026

    @MelvinBot
    Contributor

    Proposal

    What is the root cause of that problem?

    When the user confirms adding an existing expense, AddExistingExpenseFooter.handleConfirm() calls Navigation.dismissToSuperWideRHP(). On narrow layouts (mobile/Android), dismissToSuperWideRHP falls through to dismissModal(), which pops the entire RIGHT_MODAL_NAVIGATOR — removing both the ADD_EXISTING_EXPENSE screen and the underlying report screen (EXPENSE_REPORT / SEARCH_MONEY_REQUEST_REPORT), landing the user back on the Reports/Search tab.

    On wide layouts this works correctly because navigateBackToLastSuperWideRHPScreen finds the super-wide RHP screen and only pops the screens above it.

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

    In AddExistingExpenseFooter.handleConfirm(), replace Navigation.dismissToSuperWideRHP() with Navigation.goBack() so that on narrow layouts only the ADD_EXISTING_EXPENSE screen is popped, returning the user to the report screen underneath. On wide layouts, goBack() also correctly pops back one screen within the RHP.

    What alternative solutions did you explore? (Optional)

    An alternative would be to modify dismissToSuperWideRHP itself to handle the narrow-layout case by popping back within the RHP stack instead of dismissing the entire modal. However, this would change the behavior of dismissToSuperWideRHP globally for all callers, which may have unintended side effects. A targeted fix in handleConfirm is safer.

    Investigation details

    Navigation stack on narrow layout:

    1. User opens report from Spend > Reports → RIGHT_MODAL_NAVIGATOR pushed with EXPENSE_REPORT screen
    2. User taps "Add Expense" > "Add existing expense" → ADD_EXISTING_EXPENSE pushed within same RHP
    3. RHP stack: [EXPENSE_REPORT, ADD_EXISTING_EXPENSE]
    4. handleConfirm calls dismissToSuperWideRHP() → on narrow, calls dismissModal() → pops entire RIGHT_MODAL_NAVIGATOR → both screens removed → user lands on Search/Reports tab

    Key code paths:

    • dismissToSuperWideRHP: On narrow layout, directly calls dismissModal() with comment "Super Wide RHP doesn't exist"
    • SUPER_WIDE_RIGHT_MODALS: Contains SEARCH_MONEY_REQUEST_REPORT and EXPENSE_REPORT — these are the screens that should be preserved

    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.

  7. nyomanjyotisa commented on May 1, 2026

    @nyomanjyotisa
    Member

    I don't think this is an issue from #85225, since production has the same behavior

    MacOS-Chrome.mp4
  8. puneetlath commented on May 1, 2026

    @puneetlath
    Contributor

    Ok, demoting this and marking external.

  9. 39 remaining items

  10. sobitneupane commented on May 14, 2026

    @sobitneupane
    Contributor

    Regression Test Proposal

    Test:

    1. Open the Expensify app.
    2. Open any workspace chat.
    3. Create a manual expense.
    4. Create an empty report.
    5. Navigate to "Spend" > "Reports"
    6. Open the empty report created on step 4.
    7. Tap on "Add Expense" > "Add existing expense"
    8. Select the expense created on step 3 and add it to report.
    9. Verify that after expense is added, user is navigated to the report.

    Do we agree 👍 or 👎

  11. added
    Awaiting PaymentAuto-added when associated PR is deployed to production
    and removed on May 14, 2026
  12. melvin-bot commented on May 19, 2026

    @melvin-bot

    Triggered auto assignment to @mallenexpensify (Awaiting Payment)

  13. melvin-bot commented on May 20, 2026

    @melvin-bot

    Payment Summary

    Upwork Job

    BugZero Checklist (@mallenexpensify)

    • (if NewFeature) I have created a PR for any necessary HelpDot updates, or I confirmed no updates are necessary.
    • I have verified the correct assignees and roles are listed above and updated the necessary manual offers
    • I have verified that there are no duplicate or incorrect contracts on Upwork for this job (https://www.upwork.com/ab/applicants/2050258929939771054/hired)
    • I have verified the PR was not reverted
    • I have applied any discounts due to bugs/regressions introduced by this PR
    • I have paid out the Upwork contracts or cancelled the ones that are incorrect
    • I have verified the payment summary above is correct
  14. mallenexpensify commented on May 22, 2026

    @mallenexpensify
    Contributor

    Payment Summary

    Contributor+: @sobitneupane due $250 via NewDot

    I don't think this is an issue from #85225, since production has the same behavior

    @sobitneupane please address instances of "deployer blockers" in the issue or associated PRs so , when it comes time for payment, if payment is due (without having to search abour issues/payments while paying alll issues)

    cc @puneetlath in case you disagree with the above.

  15. JmillsExpensify commented on Jul 28, 2026

    @JmillsExpensify
    Contributor

    $250 approved for @sobitneupane

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Awaiting PaymentAuto-added when associated PR is deployed to productionBugSomething is broken. Auto assigns a BugZero manager.DailyKSv2EngineeringExternalAdded to denote the issue can be worked on by a contributor

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions