[$250] [Exploratory] 88633 - Web- QBD - Page become unresponsive after clicking on Manage settings button on Features

[unzig21]

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: v9.3.62-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-22025/folder/13176907/41237420/1363739274
Email or phone of affected tester (no customers): applausetester+vq@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 10/Chrome
App Component: Workspace Settings

Action Performed:

Preconditions
QBD connection is established in the workspace.

1. Open the New Dot app
2. Navigate to the QBD connected Workspace -> More Features
3. Click on the Lock icon of Accounting, Categories, Tags, or Taxes
4. Click on the Manage Settings button

Expected Result:

Can click on the Accounting QBD page normally after the redirect

Actual Result:

No response on the Accounting page

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7137238_1777011978427.unrespone_page.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022054389637126141168
• Upwork Job ID: 2054389637126141168
• Last Price Increase: 2026-06-10

[MelvinBot]

Proposal

What is the root cause of that problem?

On web, useConfirmModal injects shouldHandleNavigationBack: true into every confirm modal. This causes the web Modal to push a browser history guard entry ({shouldGoBack: true}) when the modal opens.

When the user clicks "Manage Settings", the dismiss chain fires: the modal close animation plays → onDismiss → onModalHide chain → ConfirmModalWrapper.handleModalHide → closeModal(CONFIRM) → resolves the promise → Navigation.navigate(POLICY_ACCOUNTING).

The problem is in hideModal: after calling onModalHide() (which triggers the navigation above via a microtask/promise resolution), it schedules setTimeout(() => window.history.back(), 0). The intent is for React Navigation's replaceState to clear shouldGoBack before the timeout fires. But the navigation state commit is also async (React batch flush), and both the flush and the setTimeout compete as macrotasks — their ordering is non-deterministic.

If the setTimeout wins the race, history.back() fires while shouldGoBack is still set. This pops the history entry and dispatches a popstate event that React Navigation handles — navigating the app back to More Features. Meanwhile, the pending Navigation.navigate(Accounting) commit also applies, creating a conflicting navigation state. This mismatch between browser history and React Navigation's internal state leaves the Accounting page rendered but effectively unresponsive.

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

In useConfirmModal.ts:16, stop hardcoding shouldHandleNavigationBack: true by moving it after the spread so callers can override it, or default it to false:

// Before
props: { shouldHandleNavigationBack: true, ...options },

// After — let callers opt in; the default becomes false (Modal's own default)
props: { ...options },

Then, in WorkspaceMoreFeaturesPage, explicitly pass shouldHandleNavigationBack: false to the showConfirmModal calls in warnAccountingManagesOrganizeFeature and warnDisconnectAccountingFirst, since these modals navigate on confirm and must not leave a history guard entry that races with the navigation.

What alternative solutions did you explore? (Optional)

An alternative is to fix the race in Modal/index.tsx:hideModal directly — e.g., synchronously clearing shouldGoBack with replaceState before calling onModalHide() so the setTimeout guard always passes. This would fix all modals but changes the history cleanup behavior for every shouldHandleNavigationBack modal, which has a wider blast radius.

Investigation details

Flow trace:

1. Lock icon click → Switch.handleSwitchPress → disabledAction() → warnAccountingManagesOrganizeFeature
2. showConfirmModal() → ConfirmModalWrapper renders inside ModalProvider → ConfirmModal → web Modal (with shouldHandleNavigationBack: true) → BaseModal → ReanimatedModal → RN Web Modal
3. Web Modal's showModal pushes {shouldGoBack: true} guard entry
4. "Manage Settings" click → handleConfirm → setIsVisible(false) → Container exit animation → onCloseCallBack → RN Modal visible=false → onDismiss → onModalHide chain → closeModal(CONFIRM) → promise resolves (microtask) → Navigation.navigate(Accounting)
5. Web Modal's hideModal schedules setTimeout(() => history.back(), 0) — this races with React's batch commit of the navigation state

Why the race is non-deterministic: Navigation.navigate dispatches inside a promise callback (microtask). React 18 batches the resulting setState and flushes via MessageChannel (macrotask). The setTimeout(0) from hideModal is also a macrotask. Browser task scheduling determines which fires first.

Why it causes unresponsiveness, not just a wrong page: If history.back() fires first, it triggers popstate → React Navigation navigates back. Then React's batch commit applies the Accounting navigation. This creates a conflict in the navigation state. The RN Web Modal's fullscreen position: fixed overlay from ModalContent may also persist in a zombie state during the conflict, intercepting clicks while rendering transparently.

---

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.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @truph01 (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022054389637126141168

[neerajbachani]

Proposal

What is the root cause of that problem?

When a QBD-connected workspace has Accounting, Categories, Tags, or Taxes locked on More Features, clicking the lock icon opens a confirm modal with a Manage settings button. On confirm, the handler navigates to the Accounting page (ROUTES.POLICY_ACCOUNTING). On web, the Accounting page renders but becomes unresponsive to clicks.

Repro path (4 entry points, 2 handlers):

Lock icon row	Handler	Modal copy
Accounting (Integrate)	warnDisconnectAccountingFirst	disconnectText
Categories / Tags / Taxes (Organize)	warnAccountingManagesOrganizeFeature	featureEnabledText

Both handlers live in src/pages/workspace/WorkspaceMoreFeaturesPage/index.tsx and follow the same shape:

const {action} = await showConfirmModal({...});
if (action !== ModalActions.CONFIRM) return;
Navigation.navigate(ROUTES.POLICY_ACCOUNTING.getRoute(policyID));

The race is web-specific and lives in the modal history guard:

1. useConfirmModal defaults every confirm modal to shouldHandleNavigationBack: true (src/hooks/useConfirmModal.ts:17). Callers can override because ...options is spread after the default.

2. On web, when shouldHandleNavigationBack is true, Modal.showModal() pushes a browser history guard entry {...currentState, shouldGoBack: true} and registers a popstate listener (src/components/Modal/index.tsx:87-95).

3. On confirm, the close chain runs: animation → onModalHide → ConfirmModalWrapper.handleModalHide → closeModal({action: CONFIRM}) → promise resolves → handler calls Navigation.navigate(POLICY_ACCOUNTING).

4. In parallel, Modal.hideModal() schedules setTimeout(() => window.history.back(), 0) to pop the guard entry (src/components/Modal/index.tsx:63-81). The intent is that React Navigation's route commit clears shouldGoBack before the timeout fires.

5. The race: Navigation.navigate resolves as a microtask, but React Navigation's history push/replace happens in a later macrotask (React 18 batched commit). The setTimeout(0) is also a macrotask. On Chrome/Windows, the timeout frequently wins — window.history.state.shouldGoBack is still true, so history.back() fires. This triggers a popstate event that React Navigation handles as a back navigation, while the pending Navigation.navigate(Accounting) commit also lands. Browser history and React Navigation's internal stack diverge, leaving the Accounting page mounted but effectively unresponsive.

This is consistent with the bug being reproducible on web (Windows/Chrome) but not on native platforms, where window.history does not exist and the history.back() branch is never reached.

Why QBD makes it reliably reproducible: QBD is one of the accounting integrations that sets hasAccountingConnections(policy) === true, which locks all four toggles. The destination Accounting page is the same regardless of integration type — the bug is in the modal-to-navigation transition, not QBD-specific rendering logic.

---

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

Primary fix — opt out of history guard at the two repro callsites

In src/pages/workspace/WorkspaceMoreFeaturesPage/index.tsx, pass shouldHandleNavigationBack: false to the two showConfirmModal calls whose confirm path performs programmatic navigation:

1. warnAccountingManagesOrganizeFeature (Categories, Tags, Taxes lock icons):

 const {action} = await showConfirmModal({
+    shouldHandleNavigationBack: false,
     title: translate('workspace.moreFeatures.connectionsWarningModal.featureEnabledTitle'),
     prompt: translate('workspace.moreFeatures.connectionsWarningModal.featureEnabledText'),
     confirmText: translate('workspace.moreFeatures.connectionsWarningModal.manageSettings'),
     cancelText: translate('common.cancel'),
 });

2. warnDisconnectAccountingFirst (Accounting lock icon):

 const {action} = await showConfirmModal({
+    shouldHandleNavigationBack: false,
     title: translate('workspace.moreFeatures.connectionsWarningModal.featureEnabledTitle'),
     prompt: translate('workspace.moreFeatures.connectionsWarningModal.disconnectText'),
     confirmText: translate('workspace.moreFeatures.connectionsWarningModal.manageSettings'),
     cancelText: translate('common.cancel'),
 });

With shouldHandleNavigationBack: false, no guard history entry is pushed, so no setTimeout(0) history.back() runs on close. The confirm → navigate flow completes cleanly.

No change to useConfirmModal.ts is required — the hook already allows callers to override the default.

Diagnostic logs — for RCA validation in staging/production

Add [88977]-tagged structured logs to confirm the race hypothesis and catch regressions:

Location	When	Payload
Both handlers — entry	Lock icon pressed	handlerName, policyID, connectedIntegration
Both handlers — post-modal	After await showConfirmModal	handlerName, policyID, action
Both handlers — pre-navigate	Before Navigation.navigate	handlerName, route, historyShouldGoBack (web), activeRoute
Modal/index.tsx hideModal	History guard branch entered	shouldHandleNavigationBack, historyShouldGoBack, historyLength, activeRoute
Modal/index.tsx setTimeout	Cleanup skipped or executed	Same fields + whether history.back() ran

These logs let us filter by [88977] and reconstruct the exact ordering of modal teardown vs navigation commit if any edge case persists.

What alternative solutions did you explore?