[Due for payment 2026-10-27] Web- Browser back button doesn't dismiss "You appear to be offline" alert

@ZhenjaHorbach

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

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): [email protected]
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.

Workaround:

Unknown

Platforms:

Screenshots/Videos

_To b

Bug7287536_1792091369696.Expensify_PR103554_Back_Web.mp4

e added by Applause Leads_

View all open jobs on GitHub

Applause Internal Information
Exported by: Chandana Kiran
Bug ID: 7287536

Issue Owner

Current Issue Owner: @ZhenjaHorbach

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

@roryabraham

@roryabraham recently merged #103554, but they are OOO right now, so I'll auto-assign someone else.

@carlosmiceli

Triggered auto assignment to @carlosmiceli (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

👋 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.
Find someone who can quickly fix the issue.
Fix the issue yourself.

@roryabraham

@roryabraham @ZhenjaHorbach you have been assigned to this deploy blocker because you reviewed the offending PR: #103554

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

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

Investigation details

Why this PR

It is the only PR in Deploy Checklist: New Expensify 2026-10-15 that changes the offline alert in Search bulk actions or SelectionToolbar.
Offer export templates when a group row is selected on a grouped search and [Payment due @truph01] fix: Add Contains / Equal to match type for the Merchant filter [80823] also touch useSearchBulkActions.ts, but not the offline modal.
The navigation PRs in this release (Keep split navigator state when navigating to the only sidebar screen on narrow layout #103746, [NoQA] Fix import/no-cycle - part 16 #103180, Restore last visited page on cold start for public domain accounts #103818) do not affect modal back handling.
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.

Production

The alert was an inline modal with no back handling: SearchBulkActionsButton.tsx:276-284.

Staging

Offline paths call 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.
That opens the global modal with shouldHandleNavigationBack: true (useDecisionModal.ts:11-14). The modal renders at the app root (App.tsx:130).
On Back, the guard in useSyncModalWithHistory/index.ts:61-125 should call onClose (DecisionModalWrapper.tsx:48). In this flow it doesn't.

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.

view run

@TMisiukiewicz

Looks like all modals that use the global modal have the same issue in prod also
I'm pretty sure it's related to the latest react-navigation updates

@TMisiukiewicz
Can you take a look, please?

Okay
Confirm
It's related to react navigation

And I have a patch that we can use as a temporary fix at least

diff --git a/patches/react-navigation/@react-navigation+native+7.4.1+001+initial.patch b/patches/react-navigation/@react-navigation+native+7.4.1+001+initial.patch
index b16466d5d91..c323f024fed 100644
--- a/patches/react-navigation/@react-navigation+native+7.4.1+001+initial.patch
+++ b/patches/react-navigation/@react-navigation+native+7.4.1+001+initial.patch
@@ -84,7 +84,7 @@ index 0000000..b996822
 +}
 +//# sourceMappingURL=findFocusedRouteKey.js.map
 diff --git a/node_modules/@react-navigation/native/lib/module/useLinking.js b/node_modules/@react-navigation/native/lib/module/useLinking.js
-index af0cd61..fb06350 100644
+index af0cd61..2805780 100644
 --- a/node_modules/@react-navigation/native/lib/module/useLinking.js
 +++ b/node_modules/@react-navigation/native/lib/module/useLinking.js
 @@ -4,6 +4,7 @@ import { CommonActions, findFocusedRoute, getActionFromState as getActionFromSta
@@ -139,7 +139,19 @@ index af0cd61..fb06350 100644
  export function useLinking(ref, {
    enabled = true,
    config,
-@@ -411,6 +449,9 @@ export function useLinking(ref, {
+@@ -266,7 +304,10 @@ export function useLinking(ref, {
+       if (record?.path === path && record?.state) {
+         const currentState = navigation.getRootState();
+         const [currentFocused, recordFocused] = findMatchingState(currentState, record.state);
+-        if (previousIndex - index === 1 && currentFocused && recordFocused && isPoppingLastEntry(currentFocused, recordFocused)) {
++        // Custom string history entries (e.g. modal back-guards) aren't routes, so no router can pop them with GO_BACK.
++        // Reset to the record's state instead, which drops the custom entry.
++        const isPoppingCustomHistoryEntry = typeof currentFocused?.history?.at(-1) === 'string';
++        if (previousIndex - index === 1 && currentFocused && recordFocused && !isPoppingCustomHistoryEntry && isPoppingLastEntry(currentFocused, recordFocused)) {
+           const pending = pendingPopStateDeltaRef.current;
+ 
+           // If we detect that the state change is popping the last entry
+@@ -411,6 +452,9 @@ export function useLinking(ref, {
          const historyDelta = getHistoryLength(focusedState) - getHistoryLength(previousFocusedState) - (
          // Subtract the delta already applied by the browser to sync only the remaining changes
          pendingPopStateDelta ?? 0);
@@ -149,7 +161,7 @@ index af0cd61..fb06350 100644
          if (historyDelta > 0) {
            // If history length is increased, we should pushState
            // Note that path might not actually change here, for example, drawer open should pushState
-@@ -422,7 +463,8 @@ export function useLinking(ref, {
+@@ -422,7 +466,8 @@ export function useLinking(ref, {
            // If history length is decreased, i.e. entries were removed, we want to go back
  
            const nextIndex = history.backIndex({
@@ -159,7 +171,7 @@ index af0cd61..fb06350 100644
            });
            const currentIndex = history.index;
            try {
-@@ -435,7 +477,18 @@ export function useLinking(ref, {
+@@ -435,7 +480,18 @@ export function useLinking(ref, {
                // We couldn't find an existing entry to go back to, so we'll go back by the delta
                // This won't be correct if multiple routes were pushed in one go before
                // Usually this shouldn't happen and this is a fallback for that
@@ -179,7 +191,7 @@ index af0cd61..fb06350 100644
              }
  
              // Store the updated state as well as fix the path if incorrect
-@@ -448,10 +501,26 @@ export function useLinking(ref, {
+@@ -448,10 +504,26 @@ export function useLinking(ref, {
            }
          } else {
            // If history length is unchanged, we want to replaceState
diff --git a/patches/react-navigation/details.md b/patches/react-navigation/details.md
index 54272192681..262472ca5cb 100644
--- a/patches/react-navigation/details.md
+++ b/patches/react-navigation/details.md
@@ -42,6 +42,7 @@
 - PR Introducing Patch: [#24165](https://github.com/Expensify/App/pull/24165)
 - PR Updating Patch: [#32087](https://github.com/Expensify/App/pull/32087) [#42465](https://github.com/Expensify/App/pull/42465) [#64155](https://github.com/Expensify/App/pull/64155) [#103346](https://github.com/Expensify/App/pull/103346) [#101715](https://github.com/Expensify/App/issues/101715)
 - Note: Re-ported onto 7.4.1. `createMemoryHistory` and `useLinking` were refactored upstream (`getPathWithoutHash`, `getHistoryLength`, `pendingPopStateDelta`, `isPoppingLastEntry`), so the hunks were re-anchored instead of applied verbatim: `backIndex` keeps upstream's hash handling and adds the focused-route-key match, and `useLinking` keeps upstream's `pendingPopStateDelta` guard and `getHistoryLength` delta while re-adding `historyDeltaByKeys`/`getStaleHistoryDiff`. Two parts of the old patch became redundant and were dropped: the `findFocusedRouteKey` helper file now matches upstream's own module, and the extra `history.replace` right after `history.go(nextIndex - currentIndex)` duplicated the replace that upstream already runs at the end of the same `try` block.
+- Note: The `popstate` listener skips upstream's `isPoppingLastEntry` → `GO_BACK` shortcut when the last root history entry is a custom string entry (e.g. a `useSyncModalWithHistory` back-guard). No router can pop such an entry with `GO_BACK`, so it falls back to `resetRoot(record.state)` (the pre-7.3 behavior), which drops the entry and lets the modal close on browser Back.
 
 ### [@react-navigation+stack+7.11.2+001+edge-drag-gesture.patch](@react-navigation+stack+7.11.2+001+edge-drag-gesture.patch)

@ZhenjaHorbach

Thanks @ZhenjaHorbach your patch looks good and fixes the issue, opened #104190 and will upstream it to React Navigation 🙏

Demoting

@ZhenjaHorbach

@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:

Fix browser Back not closing modals with history back-guard #104190

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]

Navigation Menu

Repository navigation

[Due for payment 2026-10-27] Web- Browser back button doesn't dismiss "You appear to be offline" alert #104154

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Deploy Blocker Analysis

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Due for payment 2026-10-27] Web- Browser back button doesn't dismiss "You appear to be offline" alert #104154

Description

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Activity

applause-bot commented on Oct 15, 2026

melvin-bot commented on Oct 15, 2026

melvin-bot commented on Oct 15, 2026

github-actions commented on Oct 15, 2026

melvin-bot commented on Oct 15, 2026

melvin-bot commented on Oct 15, 2026

MelvinBot commented on Oct 15, 2026

Deploy Blocker Analysis

ZhenjaHorbach commented on Oct 15, 2026

ZhenjaHorbach commented on Oct 15, 2026

TMisiukiewicz commented on Oct 16, 2026

cristipaval commented on Oct 16, 2026

melvin-bot commented on Oct 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions