You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Due for payment 2026-05-20] [$250] Android - Spend - User is navigated out of report after adding an existing expense. #89352
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.
Open the Expensify app.
Open any workspace chat.
Create a manual expense.
Create an empty report.
Navigate to "Spend" > "Reports"
Open the empty report created on step 4.
Tap on "Add Expense" > "Add existing expense"
Select the expense created on step 3 and add it to report.
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".
👋 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:
Identify the pull request that introduced this issue and revert it.
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.
The bug is reproducible on staging but not production ("new feature, doesn't exist in prod"), consistent with a regression introduced by this staging-only PR.
The PR modifies the screen name, route, navigator, and linking config for this flow, confirming it owns the navigation behavior in question.
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.
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 entireRIGHT_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:
User opens report from Spend > Reports → RIGHT_MODAL_NAVIGATOR pushed with EXPENSE_REPORT screen
User taps "Add Expense" > "Add existing expense" → ADD_EXISTING_EXPENSE pushed within same RHP
RHP stack: [EXPENSE_REPORT, ADD_EXISTING_EXPENSE]
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.
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.
Activity
melvin-bot commentedon May 1, 2026
You have been assigned to this deploy blocker because you recently merged this PR: #85225
melvin-bot commentedon May 1, 2026
💬 A slack conversation has been started in #expensify-open-source
github-actions commentedon May 1, 2026
👋 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:
OSBotify commentedon May 1, 2026
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:
DeployBlockerCashkept — this is a Frontend bug inExpensify/App. No label changes required; the existing label is correct.Detailed Analysis
Evidence
9.3.65-0, matching the version in the bug report.Verification
src/pages/AddExistingExpense.tsx— this file was substantially modified by PR Feat: Change Add unreported expense to Add existing expense in a report #85225 (146 additions, 34 deletions).src/components/AddExistingExpenseFooter.tsx— renamed fromAddUnreportedExpenseFooterand updated in PR Feat: Change Add unreported expense to Add existing expense in a report #85225.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.handleConfirmcallsNavigation.dismissToSuperWideRHP(), which on narrow layouts resolves todismissModal(). 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
dismissToSuperWideRHPcall was present in the priorAddUnreportedExpenseFooteras 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.MelvinBot commentedon May 1, 2026
Proposal
What is the root cause of that problem?
When the user confirms adding an existing expense,
AddExistingExpenseFooter.handleConfirm()callsNavigation.dismissToSuperWideRHP(). On narrow layouts (mobile/Android),dismissToSuperWideRHPfalls through todismissModal(), which pops the entireRIGHT_MODAL_NAVIGATOR— removing both theADD_EXISTING_EXPENSEscreen 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
navigateBackToLastSuperWideRHPScreenfinds 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(), replaceNavigation.dismissToSuperWideRHP()withNavigation.goBack()so that on narrow layouts only theADD_EXISTING_EXPENSEscreen 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
dismissToSuperWideRHPitself 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 ofdismissToSuperWideRHPglobally for all callers, which may have unintended side effects. A targeted fix inhandleConfirmis safer.Investigation details
Navigation stack on narrow layout:
RIGHT_MODAL_NAVIGATORpushed withEXPENSE_REPORTscreenADD_EXISTING_EXPENSEpushed within same RHP[EXPENSE_REPORT, ADD_EXISTING_EXPENSE]handleConfirmcallsdismissToSuperWideRHP()→ on narrow, callsdismissModal()→ pops entireRIGHT_MODAL_NAVIGATOR→ both screens removed → user lands on Search/Reports tabKey code paths:
dismissToSuperWideRHP: On narrow layout, directly callsdismissModal()with comment "Super Wide RHP doesn't exist"SUPER_WIDE_RIGHT_MODALS: ContainsSEARCH_MONEY_REQUEST_REPORTandEXPENSE_REPORT— these are the screens that should be preservedNext Steps for Contributor+ team: Reply with
@MelvinBot implement thisto create a draft PR,@MelvinBot <your feedback>to refine this analysis, or explain why you are rejecting Melvin's proposal.nyomanjyotisa commentedon May 1, 2026
I don't think this is an issue from
#85225, since production has the same behaviorMacOS-Chrome.mp4
puneetlath commentedon May 1, 2026
Ok, demoting this and marking external.
39 remaining items
sobitneupane commentedon May 14, 2026
Regression Test Proposal
Test:
Do we agree 👍 or 👎
melvin-bot commentedon May 19, 2026
Triggered auto assignment to @mallenexpensify (
Awaiting Payment)melvin-bot commentedon May 20, 2026
Payment Summary
Upwork Job
BugZero Checklist (@mallenexpensify)
mallenexpensify commentedon May 22, 2026
Payment Summary
Contributor+: @sobitneupane due $250 via NewDot
@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.
JmillsExpensify commentedon Jul 28, 2026
$250 approved for @sobitneupane