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-10-27] Web- Browser back button doesn't dismiss "You appear to be offline" alert #104154
Version Number: v9.5.10-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:#103554 Email or phone of affected tester (no customers):gd868gd+1@gmail.com Issue reported by: Applause Internal Team Bug source: Pull Request QA execution Device used: Desktop / Windows 11 App Component: Other
Action Performed:
Preconditions:
The account has a workspace.
There are a couple of unreported expenses.
There are a couple of expenses in a report.
Open the Expensify WebApp and log in with the account from the Precondition
Go to Account / Troubleshooting and switch the "Force offline" toggle on
Go to Search / Expenses and select several different expenses
Click on "Export" and select any option ("Basic export", for example)
When the "You appear to be offline" modal appears, click the browser back button and observe
Expected Result:
The "You appear to be offline" modal should be dismissed.
Actual Result:
The "You appear to be offline" modal is not dismissed.
👋 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.
Recommendation: Revert. The revert applies cleanly to staging (a3d62cc) and main (7e9ad84). The PR is a refactor, so reverting costs little. There is no verified small roll-forward fix yet.
Root cause: The PR replaced the inline <DecisionModal> in the Search screen with the global useDecisionModal modal, which renders at the app root. Before, browser Back navigated away and the modal went with the screen. Now the modal lives outside the screen, so only its history back-guard can close it, and that guard does not fire in this flow.
The modal, popover, BulkActionBar, and useSyncModalWithHistory code is identical between production (5ca624c) and staging (a3d62cc).
The PR merged 2026-10-14 and is in 9.5.10-0. Its test notes say browser Back on web wasn't tested. They also report a stuck SelectionToolbar Export offline alert on Android.
Why the guard doesn't fire (unconfirmed hypothesis): In @react-navigation/native 7.4.1, browser Back sends goBack() to the innermost active navigator. If the Search stack or tab history can go back, it handles the action, so the root-level guard entry is never removed. I did not reproduce this in a running app.
Why not a quick fix
Setting shouldHandleNavigationBack: false makes it worse: Back navigates, but the root modal stays on top.
Closing the modal from a navigation listener risks an extra browser back when the guard cleans up.
Before re-landing, prove the guard closes on browser Back in Search and SelectionToolbar, and add a test for it.
Severity: Low. It affects web only, offline only, after browser Back, and "Got it" still dismisses it. Demoting is defensible if the team wants to keep the refactor. Given the clean revert and the Android stuck-alert risk, reverting is the safer choice.
Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis.
changed the title [-]Web- Browser back button doesn't dismiss "You appear to be offline" alert[/-][+][Due for payment 2026-10-27] Web- Browser back button doesn't dismiss "You appear to be offline" alert[/+]on Oct 20, 2026
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.5.14-3 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-10-27. 🎊
The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the Contributor+ 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]. If no checklist is needed for this issue, you can click: [no checklist button]
[Contributor] The offending PR and associated issue have been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.
Link to the comment on the PR: N/A
Link to the comment on the Issue: N/A
It's @react-navigation/native issue that affects all modals
[Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.
Link to discussion: N/A
[Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.
Regression Test Proposal
Precondition:
Use web (Chrome).
The account has a workspace and several expenses.
Test:
Go to Account > Troubleshoot and turn on "Force offline".
Go to Search > Expenses and select several expenses.
Click "Export" and select "Basic export".
Verify that the "You appear to be offline" modal appears.
Click the browser back button.
Verify that the "You appear to be offline" modal is dismissed.
Activity
applause-bot commentedon Oct 15, 2026
While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/9b4c88ebdd604ea4de683438140fb243b5de4b2aeba0c6cb985585ee43690132
melvin-bot commentedon Oct 15, 2026
@roryabraham recently merged #103554, but they are OOO right now, so I'll auto-assign someone else.
melvin-bot commentedon Oct 15, 2026
Triggered auto assignment to @carlosmiceli (
DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.github-actions commentedon Oct 15, 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:
melvin-bot commentedon Oct 15, 2026
@roryabraham @ZhenjaHorbach you have been assigned to this deploy blocker because you reviewed the offending PR: #103554
melvin-bot commentedon Oct 15, 2026
💬 A slack conversation has been started in #expensify-open-source
MelvinBot commentedon Oct 15, 2026
Deploy Blocker Analysis
Causing PR: Use useDecisionModal for Search bulk actions and SelectionToolbar alerts (high confidence). It is a real regression: production dismisses the modal on browser Back.
Recommendation: Revert. The revert applies cleanly to staging (
a3d62cc) and main (7e9ad84). The PR is a refactor, so reverting costs little. There is no verified small roll-forward fix yet.Root cause: The PR replaced the inline
<DecisionModal>in the Search screen with the globaluseDecisionModalmodal, which renders at the app root. Before, browser Back navigated away and the modal went with the screen. Now the modal lives outside the screen, so only its history back-guard can close it, and that guard does not fire in this flow.Investigation details
Why this PR
useSearchBulkActions.ts, but not the offline modal.BulkActionBar, anduseSyncModalWithHistorycode is identical between production (5ca624c) and staging (a3d62cc).Production
Staging
showOfflineModal(): useSearchBulkActions.ts:686 defines it, and useSearchBulkActions.ts:1247 calls it for Basic export. SelectionToolbar does the same at index.tsx:96, :120, and :183.shouldHandleNavigationBack: true(useDecisionModal.ts:11-14). The modal renders at the app root (App.tsx:130).onClose(DecisionModalWrapper.tsx:48). In this flow it doesn't.Why the guard doesn't fire (unconfirmed hypothesis): In
@react-navigation/native7.4.1, browser Back sendsgoBack()to the innermost active navigator. If the Search stack or tab history can go back, it handles the action, so the root-level guard entry is never removed. I did not reproduce this in a running app.Why not a quick fix
shouldHandleNavigationBack: falsemakes it worse: Back navigates, but the root modal stays on top.Severity: Low. It affects web only, offline only, after browser Back, and "Got it" still dismisses it. Demoting is defensible if the team wants to keep the refactor. Given the clean revert and the Android stuck-alert risk, reverting is the safer choice.
Next Steps: Reply with
@MelvinBot <your feedback>to refine this analysis.view run
3 remaining items
cristipaval commentedon Oct 16, 2026
Demoting
[-]Web- Browser back button doesn't dismiss "You appear to be offline" alert[/-][+][Due for payment 2026-10-27] Web- Browser back button doesn't dismiss "You appear to be offline" alert[/+]melvin-bot commentedon Oct 20, 2026
@ZhenjaHorbach
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.5.14-3 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-10-27. 🎊
The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the Contributor+ 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]. If no checklist is needed for this issue, you can click: [no checklist button]
melvin-bot commentedon Oct 21, 2026
@ZhenjaHorbach Huh... This is 4 days overdue. Who can take care of this?
ZhenjaHorbach commentedon Oct 23, 2026
Contributor+ Checklist:
[Contributor] The offending PR and associated issue have been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.
Link to the comment on the PR: N/A
Link to the comment on the Issue: N/A
It's @react-navigation/native issue that affects all modals
[Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.
Link to discussion: N/A
[Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.
Regression Test Proposal
Precondition:
Test:
Do we agree 👍 or 👎
ZhenjaHorbach commentedon Oct 23, 2026
I suppose it's a separate issue and not a regression
Since all modals were broken