[$250] Web-Per diem-Back browser leads to ws settings page instead of exiting selection mode

[applause-bot]

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.4.26-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #94912
Email or phone of affected tester (no customers): applausetester+ag010726@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11/ Chrome
App Component: Workspace Settings

Action Performed:

Preconditions: Have a control workspace with Per diem enabled, and rates added.

1. Navigate to https://staging.new.expensify.com/
2. Log in with any Expensifail account as a workspace admin
3. Go to workspace settings > Per diem
4. Resize the browser to enable narrow layout
5. Long-click on any row > Select
6. Press the browser back button

Expected Result:

The multiple selection mode is dismissed, and the selection clears.

Actual Result:

The app redirects to the Overview page or workspace settings page.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7197007_1782943490124.browser_back_button.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7197007

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022072555008213077203
• Upwork Job ID: 2072555008213077203
• Last Price Increase: 2026-07-02

Issue Owner

Current Issue Owner: @Krishna2323

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/18e2af00024483e71ba247eddec4048841cf5d763320529c0813429522e85c07

[MelvinBot]

Proposal

What is the root cause of that problem?

On web, the browser/OS back button is never intercepted to dismiss multi‑selection mode — so it just performs normal navigation (back to the workspace settings/Overview page).

The "back exits selection mode" behavior is wired to only two things, neither of which is the web browser back button:

1. The on‑screen header back arrow (onBackButtonPress), which does correctly exit selection mode — WorkspacePerDiemPage.tsx:398-402.
2. The Android hardware back button, via useSearchBackPress / the Table selection middleware.

Both back‑handling hooks are Android‑native only and are no‑ops on web:

• useSearchBackPress/index.ts:4 → empty function (// the back press event is only supported on Android native). The real handler lives in index.android.ts:9-24 (BackHandler.addEventListener('hardwareBackPress', …)).
• useAndroidBackButtonHandler/index.ts → also a web no‑op, called by the shared Table selection middleware at Table/middlewares/selection.ts:74-84.

So on narrow web, entering selection mode does not push a history entry and nothing catches the browser back press → it navigates away instead of clearing the selection.

Note (scope): This is not unique to Per diem. Categories, Tags and Distance rates use the identical Table + useSearchBackPress wiring, so the browser back button should behave the same way on all of them. This was surfaced during QA of the Per diem → Table migration (#94912), but it's a pre‑existing web gap (consistent with "Reproducible in production: Yes"), not a regression from that PR.

Investigation details & confidence

• Pre‑migration Per diem used SelectionListWithModal, which also has no web popstate/history handling for selection mode — confirming this is a long‑standing web gap rather than a Table‑migration regression.
• The codebase already has a working web‑back interception pattern: Popover syncs its open/close state to browser history (history.pushState + popstate) so the browser Back button closes it instead of navigating — see components/Popover/index.tsx. The fix should reuse that pattern.
• Confidence: Medium‑High. High on the mechanism (the two hooks are provably web no‑ops and the browser back is never intercepted). Medium overall because I confirmed this statically only — a quick narrow‑web repro (browser back button, not the on‑screen arrow) on Per diem vs. Categories would confirm the shared‑gap conclusion. This is pure client‑side navigation behavior, so backend logs aren't relevant.

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

Add a web implementation for the selection‑mode back handler that mirrors the Android one, using the existing browser‑history pattern:

• When selection mode turns on, push a dummy history entry (history.pushState).
• Subscribe to popstate; when it fires while selection mode is on, clear the selection + turnOffMobileSelectionMode() and swallow the navigation (instead of letting the browser navigate).
• When selection mode turns off normally (via the on‑screen arrow), consume/replace that history entry so state and history stay in sync.

Because all these pages funnel through the same Table selection middleware, the cleanest place is to add this alongside the existing Android handler at Table/middlewares/selection.ts:84 (or as a web variant of useSearchBackPress), so Per diem, Categories, Tags and Distance rates are all fixed at once.

What alternative solutions did you explore? (Optional)

Reuse Popover's history‑sync approach directly rather than re‑implementing raw popstate handling, to stay consistent with how the app already closes overlays on browser Back.

Related issues

• #93972 — selection mode persistence issue (possibly related, different symptom).

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/95118) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[kitvasyl]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On narrow web, browser Back navigates away from the Per diem page instead of clearing the selected rates and exiting multiple-selection mode.

What is the root cause of that problem?

WorkspacePerDiemPage correctly passes clearTableSelection to useSearchBackPress, but web resolves the hook to an unconditional no-op. Consequently, browser Back commits the navigation RESET and removes the Per diem route; changing the Onyx selection-mode state does not create or guard navigation history.

The Table migration is not the failing state transition: Table.handleMobileSelectionPress enables selection and selects the row correctly. The missing behavior is web-specific back interception. The Android implementation already demonstrates the intended gate: when selectionMode is true, clear selection, turn off selection mode, and consume Back.

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

Add src/hooks/useSearchBackPress/index.web.ts implementing the same selectionMode gate for web:

• Read ONYXKEYS.RAM_ONLY_MOBILE_SELECTION_MODE and register a focused beforeRemove handler.
• When selection mode is active, prevent the route removal, call onClearSelection(), and call turnOffMobileSelectionMode().
• For a browser-generated RESET, also restore the browser history cursor with a guarded popstate/window.history.go(1) cycle, because preventing React Navigation's state update alone does not move browser history forward again. This follows the existing web handling in useDiscardChangesConfirmation.
• When selection mode is inactive, do not prevent the action, preserving normal browser Back behavior.

Keeping this in a .web.ts implementation avoids changing iOS/desktop resolution and fixes every existing consumer of this explicitly shared hook without modifying the Per diem page or Table.

Add hook coverage for active versus inactive selection mode and browser RESET restoration. Manually verify on narrow Chrome that the first Back clears selection while remaining on Per diem, the next Back navigates away exactly once, header Back still exits selection, and wide-layout and Android back behavior remain unchanged.

What alternative solutions did you explore? (Optional)

Using usePreventRemove alone in the generic index.ts is insufficient and broader than necessary: browser history has already moved when the removal is prevented, and the generic file also resolves on non-web platforms. A page-local popstate listener would duplicate navigation synchronization that belongs in the shared back-press hook.

[shivang-goliyan]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When you're in a workspace's Per diem list on a narrow web layout and enter selection mode (long-click a row > Select), pressing the browser's back button doesn't dismiss selection mode. Instead it navigates you out of the page entirely, back to the Overview / workspace settings screen. The expectation is that browser back should just clear the selection and exit selection mode, the same way the in-app back arrow does.

What is the root cause of that problem?

There's no interception of the browser's native back button for mobile selection mode on web, and entering selection mode doesn't push any history entry. So when you hit browser back, the browser pops its own history and React Navigation runs goBack, unwinding the WorkspaceSplitNavigator entry (Per diem → WS settings) instead of touching selection state. Onyx's RAM_ONLY_MOBILE_SELECTION_MODE is never consulted on this path.

The back-exit-on-selection behavior is only implemented for Android native. The Per diem page wires it up through useSearchBackPress at WorkspacePerDiemPage.tsx:335-338, with onNavigationCallBack: () => Navigation.goBack(backTo). But the web variant of that hook is an empty stub: src/hooks/useSearchBackPress/index.ts is literally const useSearchBackPress = () => {}; with the comment "the back press event is only supported on Android native." The real logic lives in index.android.ts. Same story for useAndroidBackButtonHandler/index.ts, which the new Table's selection.ts middleware relies on. On web both do nothing.

The in-app header back arrow works fine (WorkspacePerDiemPage.tsx:398-411 clears the selection and calls turnOffMobileSelectionMode), but the browser's native back button never routes through that handler, so it slips straight past it.

Worth calling out: this isn't specific to Per diem and it isn't a regression from the Table migration in #94912. The pre-migration page used the same Android-only useSearchBackPress, and all 11 pages that consume this hook (categories, tags, tax rates, distance rates, members, report field values, etc.) share the exact same web behavior. Because the intended back-exit was deliberately scoped to Android native (both hooks carry explicit "Android only" comments and the web variant was born a no-op), this reads partly as a by-design web platform limitation that QA surfaced by applying a native expectation to web. It'd be worth confirming with Expensify whether we want this on web at all before committing to the fix, since the reach is wider than one page.

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

Implement the empty web variant src/hooks/useSearchBackPress/index.ts instead of patching Per diem alone. When selection mode is active, push a sentinel history entry and add a popstate listener; on pop, call onClearSelection() + turnOffMobileSelectionMode() rather than navigating. This is the pattern SidePanelModal already uses for web back handling (src/components/SidePanel/SidePanelModal/index.tsx). Fixing it in the hook covers all 11 consumers in one place. Rough shape:

useEffect(() => {
  if (!selectionMode) return;
  window.history.pushState(SENTINEL, '');
  const onPop = () => { onClearSelection(); turnOffMobileSelectionMode(); };
  window.addEventListener('popstate', onPop);
  return () => window.removeEventListener('popstate', onPop);
}, [selectionMode, onClearSelection]);

One caution: since this touches browser history and the hook has 11 consumers, the change needs to be regression-tested across all of those pages on both Web and mWeb, not just Per diem. There's also no existing test asserting back-button behavior in selection mode, so I'd add a web test for useSearchBackPress covering both branches (popstate clears the selection and turns off selection mode; otherwise it navigates).

What alternative solutions did you explore? (Optional)

A Per-diem-only handler on that single page. Rejected because it leaves the other 10 pages that use this hook broken with the same bug, and it duplicates logic that belongs in the shared hook. I also considered suppressing the selection-mode history entry only on the Per diem screen, but that's brittle and non-reusable, and it doesn't generalize to the other consumers.

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-02 05:39:26 UTC.

Proposal

What is the root cause of that problem?

On web, when mobile selection mode is enabled, pressing the browser back button runs a normal history navigation (POP/RESET) and there is nothing that intercepts it to exit selection mode instead — so the app leaves the Per diem page and redirects to the previous route.

The page relies on useSearchBackPress to handle the back button while in selection mode:

App/src/pages/workspace/perDiem/WorkspacePerDiemPage.tsx

Lines 335 to 338 in a97126c

	useSearchBackPress({
	onClearSelection: clearTableSelection,
	onNavigationCallBack: () => Navigation.goBack(backTo),
	});

But useSearchBackPress only has a real implementation on Android native, where it hooks hardwareBackPress and returns true to swallow the navigation:

App/src/hooks/useSearchBackPress/index.android.ts

Lines 9 to 26 in a97126c

	const useSearchBackPress: UseSearchBackPress = ({onClearSelection, onNavigationCallBack}) => {
	const [selectionMode] = useOnyx(ONYXKEYS.RAM_ONLY_MOBILE_SELECTION_MODE);
	useFocusEffect(
	useCallback(() => {
	const onBackPress = () => {
	if (selectionMode) {
	onClearSelection();
	turnOffMobileSelectionMode();
	return true;
	}
	onNavigationCallBack();
	return true;
	};
	const backHandler = BackHandler.addEventListener('hardwareBackPress', onBackPress);
	return () => backHandler.remove();
	}, [selectionMode, onClearSelection, onNavigationCallBack]),
	);
	};

The default (web/iOS) implementation is an empty no-op:

App/src/hooks/useSearchBackPress/index.ts

Lines 1 to 6 in a97126c

	import type UseSearchBackPress from './types';
	// the back press event is only supported on Android native
	const useSearchBackPress: UseSearchBackPress = () => {};
	export default useSearchBackPress;

So on web the browser back is never caught. Note the app's own header back button already handles this correctly (it clears the selection and stays on the page instead of navigating):

App/src/pages/workspace/perDiem/WorkspacePerDiemPage.tsx

Lines 398 to 411 in a97126c

	onBackButtonPress={() => {
	if (isMobileSelectionModeEnabled) {
	clearTableSelection();
	turnOffMobileSelectionMode();
	return;
	}
	if (backTo) {
	Navigation.goBack(backTo);
	return;
	}
	Navigation.goBack();
	}}

So: browser back on web → useSearchBackPress is a no-op → the default history navigation fires → the app redirects away instead of exiting selection mode.

This is not a regression from the Per diem table migration in #94912 (where QA caught it). The previous Per diem page used the same Android-only useSearchBackPress hook, and the same modal-based "Select" flow, so it had the identical behavior on web — consistent with "Reproducible in production: Yes".

Because the gap is in the shared hook, the same issue exists on every page that uses it on web — e.g. WorkspaceCategoriesPage, WorkspaceTagsPage, WorkspaceMembersPage, WorkspaceTaxesPage, PolicyDistanceRatesPage, etc.

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

Implement the web variant of useSearchBackPress so the browser back is intercepted while selection mode is on, reusing the existing useBeforeRemove hook (already used across the app for exactly this kind of browser-back interception):

App/src/hooks/useBeforeRemove.tsx

Lines 6 to 13 in a97126c

	const useBeforeRemove = (onBeforeRemove: EventListenerCallback<EventMapCore<NavigationState>, 'beforeRemove'>) => {
	const navigation = useNavigation();
	useEffect(() => {
	const unsubscribe = navigation.addListener('beforeRemove', onBeforeRemove);
	return unsubscribe;
	}, [navigation, onBeforeRemove]);
	};

Add src/hooks/useSearchBackPress/index.web.ts (leaving index.ts as the iOS/default no-op so native behavior is untouched, and matching the web-only scope of this bug):

- // the back press event is only supported on Android native
- const useSearchBackPress: UseSearchBackPress = () => {};
+ const useSearchBackPress: UseSearchBackPress = ({onClearSelection}) => {
+     const [selectionMode] = useOnyx(ONYXKEYS.RAM_ONLY_MOBILE_SELECTION_MODE);
+     useBeforeRemove(
+         useCallback(
+             (e) => {
+                 if (!selectionMode) {
+                     return;
+                 }
+                 e.preventDefault();
+                 onClearSelection();
+                 turnOffMobileSelectionMode();
+             },
+             [selectionMode, onClearSelection],
+         ),
+     );
+ };

The pages already pass the right callback (onClearSelection: clearTableSelection), so this single file fixes the Per diem page and every sibling page listed above, with zero changes to native and zero changes to any page component.

One web detail: a prevented browser back leaves the browser's history entry already moved (the React Navigation state is blocked, but the URL is off by one). The exact fix for this is already proven in useDiscardChangesConfirmation — a popstate listener that restores the entry with history.go(1):

App/src/hooks/useDiscardChangesConfirmation/index.ts

Lines 126 to 150 in a97126c

	/**
	* Browser back is blocked by the patched `beforeRemove` before the state commits, but the browser entry has
	* already moved — this listener restores it with `history.go(1)`, and dismisses the prompt as Cancel when the back happened over it.
	*/
	useEffect(() => {
	// Register once: the listener reads the latest `closeModal` through `closeModalRef`, so it never needs to re-subscribe
	const handlePopState = () => {
	if (isRestoringHistory.current) {
	isRestoringHistory.current = false;
	return;
	}
	if (didPreventResetOnPopstate.current) {
	didPreventResetOnPopstate.current = false;
	isRestoringHistory.current = true;
	window.history.go(1);
	if (shouldDismissModalOnRestore.current) {
	shouldDismissModalOnRestore.current = false;
	closeModalRef.current();
	}
	}
	};
	window.addEventListener('popstate', handlePopState);
	return () => window.removeEventListener('popstate', handlePopState);
	}, []);

We should mirror that restore in the web hook (or extract it into a small shared helper) so the URL stays in sync after the back is swallowed. Minor changes/improvements can be discussed in the PR phase.

What alternative solutions did you explore? (Optional)

Add the useBeforeRemove guard directly inside WorkspacePerDiemPage instead of the hook. This works, but it duplicates the same guard across the 11+ pages that share useSearchBackPress and leaves the root cause (the no-op web hook) unfixed for the siblings. Fixing it once in useSearchBackPress/index.web.ts is the smaller, root-cause change. I also considered implementing it in the default index.ts, but that would also alter iOS swipe-back behavior beyond this web-only report, so scoping it to index.web.ts is cleaner.

[nabi-ebrahimi]

Proposal

What is the root cause of that problem?

The Per diem page enters table mobile selection mode through the shared Table selection flow, which turns on RAM_ONLY_MOBILE_SELECTION_MODE when a narrow-layout row is selected (Table calls turnOnMobileSelectionMode() from the mobile selection entry point: https://github.com/Expensify/App/blob/main/src/components/Table/Table.tsx#L232-L238). WorkspacePerDiemPage correctly clears the selected subrate keys when its own header back button is pressed (https://github.com/Expensify/App/blob/main/src/pages/workspace/perDiem/WorkspacePerDiemPage.tsx#L398-L402), and it also wires useSearchBackPress() expecting back navigation to clear table selection first (https://github.com/Expensify/App/blob/main/src/pages/workspace/perDiem/WorkspacePerDiemPage.tsx#L335-L338). However, the non-Android implementation of useSearchBackPress is currently a no-op (https://github.com/Expensify/App/blob/main/src/hooks/useSearchBackPress/index.ts#L1-L5), while only the Android implementation intercepts back and clears selection before navigating (https://github.com/Expensify/App/blob/main/src/hooks/useSearchBackPress/index.android.ts#L9-L24). So on web, pressing the browser Back button removes/navigates away from the Per diem route instead of first dismissing selection mode, which sends the user back to Overview/workspace settings.

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

Update the default useSearchBackPress implementation to participate in React Navigation’s route-removal flow on non-Android platforms. It should read ONYXKEYS.RAM_ONLY_MOBILE_SELECTION_MODE, register a beforeRemove listener using the existing useBeforeRemove hook (https://github.com/Expensify/App/blob/main/src/hooks/useBeforeRemove.tsx#L6-L14), and when selection mode is active, call event.preventDefault(), run onClearSelection(), and call turnOffMobileSelectionMode(). When selection mode is not active, it should not prevent the route removal, so normal browser Back navigation continues as-is.

Keep the Android-specific implementation as the hardware-back handler, since it already clears selection mode and uses onNavigationCallBack() for the native back case where the app must handle navigation manually (https://github.com/Expensify/App/blob/main/src/hooks/useSearchBackPress/index.android.ts#L13-L23). This keeps the fix in the shared back/selection hook instead of adding Per diem-only browser-back logic, and it should also align other table/list screens that already call useSearchBackPress() with the expected “back exits selection mode first” behavior.

What alternative solutions did you explore? (Optional)

I also considered adding a beforeRemove handler directly inside WorkspacePerDiemPage, but that would duplicate logic already represented by useSearchBackPress() and leave the same web/browser-back gap for other screens that use shared mobile selection mode.

Demo

Screen.Recording.2026-07-02.at.11.45.34.AM.mov

[lorretheboy]

Note: This isn't a duplicate — the proposal it was flagged against was posted before the Help Wanted label (2026-07-02T05:36:26Z, before 2026-07-02T05:36:28Z), so it isn't a valid earlier proposal.

Proposal

What is the root cause of that problem?

On narrow-layout web, long-pressing a row and choosing "Select" only sets the RAM_ONLY_MOBILE_SELECTION_MODE Onyx flag — nothing is pushed into browser history and no navigation listener guards it. The only "back exits selection mode" handling that exists is wired to the Android hardware back button. In the new Table component (which PR #94912 migrated this page to), that logic lives in the selection middleware behind useAndroidBackButtonHandler:

App/src/components/Table/middlewares/selection.ts

Lines 73 to 84 in acfa48f

	// Disable selection mode when the Android hardware back button is pressed
	const androidBackButtonDisableSelectionMode = useCallback(() => {
	if (!isSelectionModeEnabled) {
	return false;
	}
	clearSelection();
	turnOffMobileSelectionMode();
	return true;
	}, [isSelectionModeEnabled, clearSelection]);
	useAndroidBackButtonHandler(androidBackButtonDisableSelectionMode);

and that hook is an explicit no-op on every platform except Android:

App/src/hooks/useAndroidBackButtonHandler/index.ts

Lines 3 to 6 in acfa48f

	// We only need this hook to handle Android back button behavior.
	// See https://reactnavigation.org/docs/custom-android-back-button-handling for more details
	// eslint-disable-next-line @typescript-eslint/no-unused-vars
	export default function useAndroidBackButtonHandler(_callback: UseAndroidBackButtonHandlerCallback) {}

The page-level useSearchBackPress is likewise Android-only (web version is empty), and the header's onBackButtonPress (which does turn off selection mode) only runs when the in-app back arrow is clicked:

App/src/pages/workspace/perDiem/WorkspacePerDiemPage.tsx

Lines 398 to 411 in acfa48f

	onBackButtonPress={() => {
	if (isMobileSelectionModeEnabled) {
	clearTableSelection();
	turnOffMobileSelectionMode();
	return;
	}
	if (backTo) {
	Navigation.goBack(backTo);
	return;
	}
	Navigation.goBack();
	}}

So the browser back button bypasses all of this: it goes straight through React Navigation's URL sync, pops the WORKSPACE.PER_DIEM route, and lands on the workspace settings/overview screen while selection mode was never consulted. (The pre-migration SelectionListWithModal version had the same Android-only handling, which is why this also reproduces in production — the migration carried the gap into the shared Table component, so every Table-migrated page, e.g. Tags, has it too.)

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

Fix it once in the Table selection middleware, next to the existing Android handler, so all Table-migrated pages are covered. The codebase already has a proven pattern for intercepting browser back: useBeforeRemove + e.preventDefault() (browser-back RESETs fire preventable beforeRemove thanks to the propagate-beforeremove-on-nested-reset react-navigation patch), plus a popstate listener that restores the consumed history entry with window.history.go(1) — exactly what useDiscardChangesConfirmation does:

App/src/hooks/useDiscardChangesConfirmation/index.ts

Lines 111 to 117 in acfa48f

	e.preventDefault();
	blockedNavigationAction.current = e.data.action;
	if (e.data.action.type === 'RESET') {
	// A prevented RESET comes from a browser back; the popstate listener must restore the URL
	didPreventResetOnPopstate.current = true;
	}
	showDiscardModal();

Concretely: replace the direct useAndroidBackButtonHandler call in the selection middleware with a small platform-split hook (e.g. useDisableSelectionModeOnBack(callback)), where index.android.ts keeps the current BackHandler behavior and index.ts (web) does, while the screen is focused and selection mode is enabled on narrow layout:

useBeforeRemove((e) => {
    if (!isSelectionModeEnabled) return;
    e.preventDefault();          // stay on the page
    restoreHistoryOnPopstate();  // history.go(1), as in useDiscardChangesConfirmation
    clearSelection();
    turnOffMobileSelectionMode();
});

Native iOS/desktop keep the no-op. This dismisses selection and clears it on browser back, matching the expected result and the existing Android behavior.

What alternative solutions did you explore? (Optional)

Handling it only in WorkspacePerDiemPage (e.g. giving useSearchBackPress a web implementation) — rejected as the wrong level: the gap lives in the shared Table selection middleware, so a page-local fix would leave every other migrated table page (Tags, etc.) with the same bug.

[ahmdshrif]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[abbasifaizan70]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On the Workspace Per Diem page (narrow/web layout), when the admin long-presses a row to enter multi-selection mode and then presses the browser's Back button, the app does not exit selection mode. Instead it navigates all the way back to the Workspace Overview/Settings page. The expected behavior is that browser Back should only dismiss the selection mode and clear the selection, staying on the Per Diem page.

What is the root cause of that problem?

WorkspacePerDiemPage calls useSearchBackPress, passing onClearSelection and onNavigationCallBack, expecting this hook to intercept the back action and, when selection mode is active, clear the selection instead of navigating away:

App/src/pages/workspace/perDiem/WorkspacePerDiemPage.tsx

Lines 335 to 338 in f61c657

	useSearchBackPress({
	onClearSelection: clearTableSelection,
	onNavigationCallBack: () => Navigation.goBack(backTo),
	});

However, the default (fallback) implementation of useSearchBackPress — which is what web actually resolves to, since there is only an index.ts and an index.android.ts for this hook — is a complete no-op:

App/src/hooks/useSearchBackPress/index.ts

Lines 1 to 6 in f61c657

	import type UseSearchBackPress from './types';
	// the back press event is only supported on Android native
	const useSearchBackPress: UseSearchBackPress = () => {};
	export default useSearchBackPress;

The real logic only exists in the Android-specific file, which subscribes to the native hardwareBackPress event via BackHandler and, if RAM_ONLY_MOBILE_SELECTION_MODE is enabled, calls onClearSelection and turnOffMobileSelectionMode instead of letting the back press propagate:

App/src/hooks/useSearchBackPress/index.android.ts

Lines 1 to 28 in f61c657

	import {useFocusEffect} from '@react-navigation/native';
	import {useCallback} from 'react';
	import {BackHandler} from 'react-native';
	import useOnyx from '@hooks/useOnyx';
	import {turnOffMobileSelectionMode} from '@libs/actions/MobileSelectionMode';
	import ONYXKEYS from '@src/ONYXKEYS';
	import type UseSearchBackPress from './types';
	const useSearchBackPress: UseSearchBackPress = ({onClearSelection, onNavigationCallBack}) => {
	const [selectionMode] = useOnyx(ONYXKEYS.RAM_ONLY_MOBILE_SELECTION_MODE);
	useFocusEffect(
	useCallback(() => {
	const onBackPress = () => {
	if (selectionMode) {
	onClearSelection();
	turnOffMobileSelectionMode();
	return true;
	}
	onNavigationCallBack();
	return true;
	};
	const backHandler = BackHandler.addEventListener('hardwareBackPress', onBackPress);
	return () => backHandler.remove();
	}, [selectionMode, onClearSelection, onNavigationCallBack]),
	);
	};
	export default useSearchBackPress;

Because there is no .web.ts variant, web builds fall back to index.ts's empty no-op function, so nothing ever listens for the browser's Back button while in selection mode. The click on the browser Back button is left entirely to React Navigation's default history handling, which simply pops the current route, landing the admin on the previous screen (Workspace Overview/Settings) rather than clearing the selection.

The codebase already has an established pattern for intercepting a browser Back press through React Navigation on web: useBeforeRemove subscribes to the beforeRemove event (which fires with a RESET action when the browser Back button is used), and callers can preventDefault() it and use window.history.go(1) to restore the URL when they want to swallow the back navigation:

App/src/hooks/useBeforeRemove.tsx

Lines 1 to 15 in f61c657

	import {useNavigation} from '@react-navigation/native';
	import type {EventListenerCallback, EventMapCore, NavigationState} from '@react-navigation/native';
	import {useEffect} from 'react';
	// beforeRemove have some limitations. When the react-navigation is upgraded to 7.x, update this to use usePreventRemove hook.
	const useBeforeRemove = (onBeforeRemove: EventListenerCallback<EventMapCore<NavigationState>, 'beforeRemove'>) => {
	const navigation = useNavigation();
	useEffect(() => {
	const unsubscribe = navigation.addListener('beforeRemove', onBeforeRemove);
	return unsubscribe;
	}, [navigation, onBeforeRemove]);
	};
	export default useBeforeRemove;

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

Add a web-specific implementation of useSearchBackPress (index.web.ts) that mirrors the Android behavior using useBeforeRemove: when selection mode is active and the beforeRemove event is a browser-back-triggered RESET, prevent it, restore the URL, and clear the selection instead of navigating away.

App/src/hooks/useSearchBackPress/index.ts

Lines 1 to 6 in f61c657

	import type UseSearchBackPress from './types';
	// the back press event is only supported on Android native
	const useSearchBackPress: UseSearchBackPress = () => {};
	export default useSearchBackPress;

Create a new file src/hooks/useSearchBackPress/index.web.ts:

import { useRef } from "react";
import useBeforeRemove from "@hooks/useBeforeRemove";
import useOnyx from "@hooks/useOnyx";
import { turnOffMobileSelectionMode } from "@libs/actions/MobileSelectionMode";
import ONYXKEYS from "@src/ONYXKEYS";
import type UseSearchBackPress from "./types";

const useSearchBackPress: UseSearchBackPress = ({ onClearSelection }) => {
  const [selectionMode] = useOnyx(ONYXKEYS.RAM_ONLY_MOBILE_SELECTION_MODE);
  const isRestoringHistory = useRef(false);

  useBeforeRemove((e) => {
    if (isRestoringHistory.current) {
      isRestoringHistory.current = false;
      return;
    }
    if (!selectionMode || e.data.action.type !== "RESET") {
      return;
    }
    e.preventDefault();
    isRestoringHistory.current = true;
    window.history.go(1);
    onClearSelection();
    turnOffMobileSelectionMode();
  });
};

export default useSearchBackPress;

With this file in place, webpack's .web.ts-first resolution (config/webpack/webpack.common.ts) will pick it up for the web build instead of falling back to the no-op index.ts, so pressing browser Back while in selection mode on the Per Diem page (and every other list page already wired to useSearchBackPress, such as WorkspaceMembersPage, WorkspaceCategoriesPage, WorkspaceTagsPage, WorkspaceTaxesPage, PolicyDistanceRatesPage, ReportFieldsListValuesPage, and DomainMembersPage) will simply clear the selection and stay on the current page, matching the existing Android behavior and the expected result in this issue.