[$250] Web - Categories list moving when pressing the up/down keyboard

[nlemma]

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.43-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://github.com/Expensify/Expensify/issues/390432
Email or phone of affected tester (no customers): -
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 10 Enterprise 64-bit - Chrome

Action Performed:

1. Open the NewDot app
2. Go to Collect Workspace> Taxes
3. Open one tax setting
4. Press the down and up arrow keys on the keyboard
5. Verify that pressing the arrow keys on the keyboard does nothing, as there is an RHP open
6. Go back and go to categories settings
7. Click to open one category setting (do not click on the RHP)
8. Press the down and up arrow keys on the keyboard

Expected Result:

Verify that pressing the arrow keys on the keyboard does nothing, as there is an RHP open

Actual Result:

Categories list moves when pressing the up/down keyboard

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7210395_1784256480268.390432.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022080369886001459787
• Upwork Job ID: 2080369886001459787
• Last Price Increase: 2026-07-23

Issue Owner

Current Issue Owner: @ahmdshrif

[MelvinBot]

Proposal

Confidence: High on the root cause, Medium on the exact fix location. Verified that this checkout is exactly the reported version (9.4.43-1), so this analysis is against the code that actually reproduces the bug — not a since-fixed version.

What is the root cause of that problem?

On web, opening an RHP does not make the background screen inert, so the underlying list is still natively scrollable with the keyboard.

• The workspace Categories list renders through the shared Table component, which is a plain FlashList with no JS arrow-key handling — src/components/Table/TableBody.tsx:100. So the movement you see is the browser's native arrow-key scroll of the background list container, not a focused-row highlight.
• The RHP is a React Navigation overlay rendered as a sibling over a still-mounted, still-scrollable background screen — RightModalNavigator.tsx:228. The overlay only dims the background visually — BaseOverlay.tsx:36 — it doesn't set inert / aria-hidden / pointer-events on it.
• The focus trap only manages Tab focus movement (focus-trap-react v11, which has no inert behavior) — FocusTrapForScreen/index.web.tsx:44. Nothing stops arrow-key scrolling of the background.

Why Taxes looks fine but Categories doesn't: it's not a different code path — both pages use the same Table/FlashList. The Taxes list is simply short enough that there's nothing to scroll, so the same underlying behavior isn't visible. This is also why the repro step says "do not click on the RHP": focus stays on the background list, so arrow keys scroll it.

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

Make the background full-screen navigator inert while an RHP is open on wide (non-narrow) layouts. The inert attribute disables focus, pointer, and keyboard interaction on all descendants, which stops native arrow-key scrolling of the background list. The natural place is at the RHP/background boundary — toggle inert on the background container when the RHP is displayed (around RightModalNavigator.tsx:228 / the root navigator that renders the background).

Investigation details, alternatives, and verification

Data flow: open RHP → RHP mounts as a nav overlay, background Categories screen stays mounted and scrollable → overlay dims but doesn't neutralize the background → arrow keys hit the still-scrollable background FlashList → native scroll.

Alternative fix: centralize the inert toggle in FocusTrapForScreen / ScreenWrapper for inactive background screens. Broader and riskier because it touches every screen; note focus-trap-react v11 has no inert option, so this would require an explicit inert attribute toggle regardless.

Verification recommended: this is a pure DOM/client behavior, so runtime confirmation is best done in a browser (Playwright/agent-device) — check whether the background Categories container gets inert/aria-hidden and whether it still scrolls on arrow keys with an RHP open. Logs won't help here.

Related issues: a quick scan of open issues turned up no existing report for this specific behavior.

---

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

[mukhrr]

Proposal

What is the root cause of that problem?

I reproduced this locally and the cause is not what it looks like. I instrumented the page and ran three controlled experiments with the RHP open:

state when I press ArrowDown	background list scrollTop
fresh page load, nothing clicked	unchanged
mouse hovering a row, never clicked	unchanged
clicked a row, then moved the mouse onto the RHP	0 → 40 (scrolls)

In every case document.activeElement was BODY. So the list is not scrolling because the document scrolls by default, and not because of hover — it scrolls only after a mouse press landed on a row, and it keeps scrolling even once the pointer has left the list entirely.

That is Chrome's keyboard-scroll fallback chain: when nothing is focused, Blink resolves the arrow-key scroll target from the node of the last mouse press and scrolls that node's nearest scrollable ancestor — here, the categories FlashList.

We land in the "nothing is focused" state by design, from two directions.

First, TableRow deliberately prevents the row from ever taking focus:

App/src/components/Table/TableRow.tsx

Lines 198 to 216 in a4b6ddf

	onMouseDown={(e) => {
	const target = e?.target;
	if (!(target instanceof HTMLElement)) {
	e.preventDefault();
	return;
	}
	if (target.tagName === CONST.ELEMENT_NAME.INPUT) {
	return;
	}
	if (target.closest('[role="switch"]') || target.closest('[role="checkbox"]')) {
	e.preventDefault();
	return;
	}
	e.preventDefault();
	}}

That preventDefault() is intentional — it was added in 1f06c844e28 so that toggling a switch inside a row does not steal focus from the table's search input, and it must stay.

Second, the screen focus trap blurs whatever was focused on activation and never focuses anything itself (initialFocus: false):

App/src/components/FocusTrap/FocusTrapForScreen/index.web.tsx

Lines 50 to 66 in a4b6ddf

	onActivate: () => {
	const activeElement = document?.activeElement as HTMLElement;
	if (activeElement?.nodeName === CONST.ELEMENT_NAME.INPUT || activeElement?.nodeName === CONST.ELEMENT_NAME.TEXTAREA) {
	return;
	}
	activeElement?.blur();
	},
	trapStack: sharedTrapStack,
	allowOutsideClick: true,
	// Clicking outside should break the trap so side panel can remain interactive.
	clickOutsideDeactivates: true,
	// Synthetic Escape events dispatched by cancelDndKeyboardDrag are only
	// meant for the dnd-kit KeyboardSensor. Ignore them so the trap stays active.
	escapeDeactivates: () => !isCancellingDndKeyboardDrag(),
	fallbackFocus: document.body,
	delayInitialFocus: CONST.ANIMATED_TRANSITION,
	initialFocus: false,

The result is that after opening a category the clicked row is still the browser's scroll owner, while the RHP owns nothing.

The background list stays mounted and scrollable behind the RHP:

App/src/components/Table/TableBody.tsx

Lines 95 to 119 in a4b6ddf

	return (
	<View
	style={[styles.flex1, styles.mnh0, style]}
	{...props}
	>
	<FlashList<DataType>
	ref={listRef}
	data={filteredAndSortedData}
	style={[styles.flex1, styles.mnh0]}
	showsVerticalScrollIndicator={false}
	maintainVisibleContentPosition={{disabled: true}}
	contentContainerStyle={[
	filteredAndSortedData.length === 0 && styles.flexGrow1,
	listContentContainerStyle,
	tableBodyContentContainerStyle,
	contentContainerStyle,
	shouldUseNarrowTableLayout &&
	typeof contentMinHeight === 'number' &&
	typeof tableBodyBottomPadding === 'number' && {minHeight: contentMinHeight + tableBodyBottomPadding},
	]}
	keyboardShouldPersistTaps="handled"
	ListHeaderComponent={ListHeaderComponent}
	ListEmptyComponent={ListEmptyComponent}
	{...restListProps}
	/>

One correction to how the report frames this: it is not specific to categories. TableRow is shared by every workspace table (tags, taxes, distance rates, members, per diem, report fields…), so every RHP opened by clicking a row of a table tall enough to overflow behaves the same way. The taxes step in the repro only appears unaffected because that list is short enough to have nothing to scroll — it is not protected by anything. Fixing this per page would leave every other table broken, so I would fix it once, where focus ownership is already decided.

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

The screen focus trap should hand the keyboard to the screen it just activated, instead of leaving focus nowhere for the browser to guess from a stale mouse press.

ScreenWrapper already holds a ref to the container that the trap wraps, and that container is already programmatically focusable (tabIndex={-1}):

App/src/components/ScreenWrapper/index.tsx

Lines 126 to 127 in a4b6ddf

	const screenWrapperRef = useRef<View | HTMLElement>(null);
	const mergedScreenWrapperRef = mergeRefs(screenWrapperRef, ref);

App/src/components/ScreenWrapper/index.tsx

Line 302 in a4b6ddf

<FocusTrapForScreen focusTrapSettings={focusTrapSettings}>

So I would pass that ref down to FocusTrapForScreen and use it in the existing onActivate:

 onActivate: () => {
     const activeElement = document?.activeElement as HTMLElement;
     if (activeElement?.nodeName === CONST.ELEMENT_NAME.INPUT || activeElement?.nodeName === CONST.ELEMENT_NAME.TEXTAREA) {
         return;
     }
     activeElement?.blur();
+    const container = containerRef?.current;
+    if (container instanceof HTMLElement) {
+        claimInitialFocus(container, {focusVisible: false});
+    }
 },

I would route it through the focus arbitration we already have rather than calling .focus() directly:

App/src/libs/claimInitialFocus.ts

Lines 7 to 21 in a4b6ddf

	function claimInitialFocus(el: HTMLElement, {focusVisible}: {focusVisible: boolean}): boolean {
	if (document.activeElement && document.activeElement !== document.body) {
	return false;
	}
	if (!tryClaim(Priorities.INITIAL)) {
	return false;
	}
	el.focus({preventScroll: true, focusVisible});
	// Focus silently no-ops when an inert / visibility:hidden ancestor passes the focusable + geometry checks.
	if (document.activeElement !== el) {
	resetCycle();
	return false;
	}
	return true;
	}

That gives three properties for free:

• its document.activeElement !== document.body check means we never steal focus from a field the screen auto-focused (I verified the Add category RHP still lands on its Name input);
• tryClaim(Priorities.INITIAL) means we never fight a higher-priority focus move such as focus-return on navigating back;
• focusVisible: false plus preventScroll: true means no focus ring is drawn and nothing is scrolled into view.

This is scoped correctly by construction. FocusTrapForScreen only activates for screens meant to own focus exclusively — sidebar screens and the side-by-side wide-layout screens (SCREENS.WORKSPACE.CATEGORIES among them) already opt out — so the background categories page keeps its current keyboard behaviour and only the overlaying RHP starts claiming the keyboard. Native is untouched because the change lives in index.web.tsx; the native FocusTrapForScreen just renders its children.

Verification. With the fix running on my dev build, the exact repro steps now leave the background list at scrollTop 0 across repeated ArrowDown/ArrowUp presses, with document.activeElement on the RHP's own container, and the Add category RHP still focuses its input.

I would add a unit test on FocusTrapForScreen that mocks focus-trap-react to capture focusTrapOptions, invokes onActivate(), and asserts three things: focus moves to the screen container; an already-focused text input is left alone; and the existing blur-only behaviour is preserved when no container ref is supplied. I confirmed the first assertion fails on current main and passes with the change.

What alternative solutions did you explore? (Optional)

I first tried overriding focusTrapOptions.initialFocus on CategorySettingsPage alone. It does stop the scrolling, but since the mechanism lives in the shared TableRow/focus-trap pair it would need repeating on every RHP reachable from a table, so I discarded it as whack-a-mole.

I also considered registering ArrowUp/ArrowDown shortcuts and calling preventDefault(). Because the key event is delivered to document.body — not to the list — that would need a document-level listener, and it would only patch two keys while PageDown, Home, End and Space scroll the background list by the same fallback.

Finally I considered removing the blanket preventDefault() in TableRow.onMouseDown so the row takes focus normally. That does not work: the trap's onActivate blurs the row moments later, putting us straight back into the "nothing focused" state, and it would regress the search-input focus behaviour that preventDefault() was added to protect.

[ahmdshrif]

Proposal

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

With a category-settings RHP open over Workspace > Categories, pressing the up/down arrow keys scrolls the categories list in the background. Expected: the keys do nothing while an RHP is open (as on the Taxes page).

What is the root cause of that problem?

The structural cause: the new generic Table component never adopted the screen-focus scroll lock (useScrollEnabled) that our older lists use, so any Table left in the background stays keyboard-scrollable while an RHP covers it.

The evidence chain:

1. When the RHP opens, its focus trap intentionally blurs the clicked row and focuses nothing (initialFocus: false), so document.activeElement becomes <body>:
   

   App/src/components/FocusTrap/FocusTrapForScreen/index.web.tsx

   Lines 50 to 55 in a4b6ddf

   	onActivate: () => {
   	const activeElement = document?.activeElement as HTMLElement;
   	if (activeElement?.nodeName === CONST.ELEMENT_NAME.INPUT || activeElement?.nodeName === CONST.ELEMENT_NAME.TEXTAREA) {
   	return;
   	}
   	activeElement?.blur();

   (blur on activate) and #L66 (initialFocus: false).
2. With no focused element, Chromium's keyboard-scroll logic falls back to the last mouse-press node — the category row the user just clicked. Arrow keys then scroll that node's nearest scrollable ancestor: the categories FlashList. This is exactly why the repro says "(do not click on the RHP)" — clicking the RHP moves the browser's mouse-press anchor inside the RHP and the bug disappears. It also explains the Windows/Chrome-only checkbox (Blink behavior).
3. That FlashList lives in the shared Table.Body, which renders it with no scrollEnabled gating:
   

   App/src/components/Table/TableBody.tsx

   Lines 100 to 118 in a4b6ddf

   	<FlashList<DataType>
   	ref={listRef}
   	data={filteredAndSortedData}
   	style={[styles.flex1, styles.mnh0]}
   	showsVerticalScrollIndicator={false}
   	maintainVisibleContentPosition={{disabled: true}}
   	contentContainerStyle={[
   	filteredAndSortedData.length === 0 && styles.flexGrow1,
   	listContentContainerStyle,
   	tableBodyContentContainerStyle,
   	contentContainerStyle,
   	shouldUseNarrowTableLayout &&
   	typeof contentMinHeight === 'number' &&
   	typeof tableBodyBottomPadding === 'number' && {minHeight: contentMinHeight + tableBodyBottomPadding},
   	]}
   	keyboardShouldPersistTaps="handled"
   	ListHeaderComponent={ListHeaderComponent}
   	ListEmptyComponent={ListEmptyComponent}
   	{...restListProps}

4. We already fixed this exact bug class in PR #56435 ("fix: prevent parent view scroll when press space bar and arrow") by adding useScrollEnabled, which on web returns useIsFocused() — i.e. a list refuses to scroll while its screen is covered:
   

   App/src/hooks/useScrollEnabled/index.ts

   Lines 5 to 8 in a4b6ddf

   	const useScrollEnabled: UseScrollEnabled = () => {
   	const isFocused = useIsFocused();
   	return isFocused;
   	};

   
   BaseSelectionList applies it (

   App/src/components/SelectionList/BaseSelectionList.tsx

   Line 107 in a4b6ddf

   const scrollEnabled = useScrollEnabled();

   and #L514), as do BaseSelectionListWithSections (L93/L342) and ProfilePage (L65/L220). The Table component introduced in PR #77788 never picked it up.
5. Why Taxes "works" and Categories doesn't: both pages use the identical Table stack (WorkspaceTaxesTable and WorkspaceCategoriesTable both render Table.Body; rows navigate to RHPs registered in the same modal stack —

   App/src/libs/Navigation/AppNavigator/ModalStackNavigators/index.tsx

   Line 537 in a4b6ddf

   [SCREENS.WORKSPACE.DYNAMIC_CATEGORY_SETTINGS]: () => require<ReactComponentModule>('../../../../pages/workspace/categories/CategorySettingsPage').default,

   and #L899). The difference is data, not code: a default Collect workspace has ~20 categories (scrollable) but only ~3 tax rates (nothing to scroll). With enough tax rates, Taxes reproduces too.

Affected paths — every screen backed by the shared Table.Body with enough rows to scroll: Categories (this issue), Tags, Taxes, Members, Distance rates, Per diem, Report fields, Company/Expensify cards, Rooms, Rules, Vendors, the Workspaces list, Domain tables, and Report participants/Room members (RHP-in-RHP). One fix in TableBody covers all of them.

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

Apply the existing useScrollEnabled hook to the shared table body — the same pattern BaseSelectionList has shipped since PR #56435. In src/components/Table/TableBody.tsx (

App/src/components/Table/TableBody.tsx

Lines 100 to 118 in a4b6ddf

	<FlashList<DataType>
	ref={listRef}
	data={filteredAndSortedData}
	style={[styles.flex1, styles.mnh0]}
	showsVerticalScrollIndicator={false}
	maintainVisibleContentPosition={{disabled: true}}
	contentContainerStyle={[
	filteredAndSortedData.length === 0 && styles.flexGrow1,
	listContentContainerStyle,
	tableBodyContentContainerStyle,
	contentContainerStyle,
	shouldUseNarrowTableLayout &&
	typeof contentMinHeight === 'number' &&
	typeof tableBodyBottomPadding === 'number' && {minHeight: contentMinHeight + tableBodyBottomPadding},
	]}
	keyboardShouldPersistTaps="handled"
	ListHeaderComponent={ListHeaderComponent}
	ListEmptyComponent={ListEmptyComponent}
	{...restListProps}

):

import useScrollEnabled from '`@hooks`/useScrollEnabled';
// inside TableBody:
const scrollEnabled = useScrollEnabled();
// on the FlashList (after {...restListProps}):
scrollEnabled={scrollEnabled}

When the hosting screen loses navigation focus (an RHP is pushed on top), scrollEnabled becomes false, react-native-web sets overflow: hidden on the scroller, and the browser can no longer keyboard-scroll it; when the screen regains focus it re-enables with scroll offset preserved. Regression safety in one sentence: while the screen is focused the prop is true (today's behavior, so mouse/keyboard scrolling is untouched), and on native the hook returns undefined (

App/src/hooks/useScrollEnabled/index.native.ts

Line 3 in a4b6ddf

const useScrollEnabled: UseScrollEnabled = () => undefined;

), leaving native platforms exactly as they are.

Why the obvious spot fixes do NOT work: any focus-management fix ("blur the row when the RHP opens") is defeated because the row is already blurred — FocusTrapForScreen's onActivate does that today (L50-L55) — yet Chrome still scrolls via its last-mouse-press-node fallback, which no JS API can clear; the only levers are making the background list itself unscrollable (this fix) or force-focusing into the RHP, which would revert the deliberate initialFocus: false design that PR #56435-era trap work put in place. And a patch on WorkspaceCategoriesPage/CategorySettingsPage alone fixes one page while Tags, Members, Taxes-with-many-rates, and every other Table screen keep the identical bug.

What alternative solutions did you explore? (Optional)

1. Per-page fix on the Categories page only — incomplete: the same mechanism reproduces on every other Table-backed workspace screen; reviewers would get this bug re-filed per page.
2. Focus the RHP container on trap activation instead of blurring — moves Chromium's scroll anchor into the RHP, but changes focus behavior on every screen in the app and reverts the intentional no-initial-focus design; over-scoped and a11y-risky.
3. Global keydown listener that preventDefaults arrow keys while a focus trap is active — adds per-keypress runtime work app-wide to mask what a declarative one-prop scroll lock solves at the source.

[MobileMage]

Proposal

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

On web, after clicking a category row on the workspace Categories page to open its settings RHP, pressing the up/down arrow keys scrolls the categories list behind the RHP. Expected behavior (per the regression test, and as observed on the Taxes page) is that arrow keys do nothing while an RHP is open.

What is the root cause of that problem?

The scrolling is native browser keyboard scrolling, not app code — since the workspace pages migrated to the shared Table component, neither WorkspaceCategoriesPage nor WorkspaceTaxesPage subscribes to arrow keys at all (there is no useArrowKeyFocusManager/useKeyboardShortcut anywhere in Table, unlike the old BaseSelectionList which consumed them via useSelectionListKeyboardFocus). Two pieces of code combine to hand the arrow keys to the browser with the wrong scroll target. First, TableRow deliberately calls e.preventDefault() in its onMouseDown handler, so clicking a category row never moves DOM focus into the row:

App/src/components/Table/TableRow.tsx

Lines 211 to 215 in a4b6ddf

	e.preventDefault();
	return;
	}
	e.preventDefault();

Second, when the RHP screen mounts, FocusTrapForScreen's onActivate blurs whatever is focused, and because the trap is configured with initialFocus: false it never moves focus into the RHP either, so document.activeElement ends up on <body>:

App/src/components/FocusTrap/FocusTrapForScreen/index.web.tsx

Lines 51 to 55 in a4b6ddf

	const activeElement = document?.activeElement as HTMLElement;
	if (activeElement?.nodeName === CONST.ELEMENT_NAME.INPUT || activeElement?.nodeName === CONST.ELEMENT_NAME.TEXTAREA) {
	return;
	}
	activeElement?.blur();

When no element has focus, Chrome routes keyboard scrolling to the scrollable region under the most recent mouse click — which is the categories FlashList the user just clicked a row in — so ArrowUp/ArrowDown scroll the list behind the RHP. I confirmed this in a minimal harness replicating these exact conditions (scrollable list, rows with mousedown preventDefault, blur on trap activation): with document.activeElement === <body>, ArrowDown scrolled the background list (scrollTop 0 → 190), and moving focus onto a tabindex="-1" container in the right pane stopped the background scrolling completely. The Taxes page only appears to behave correctly because the identical Table/TableRow/ScreenWrapper stack renders both pages: a default workspace has only a couple of tax rates so the taxes list never overflows and there is simply nothing to scroll, while the ~20 default categories do overflow. With enough tax rates the same bug reproduces on Taxes (and on tags, members, distance rates, etc.), which is why the fix belongs in the shared focus-trap layer rather than in the Categories page.

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

In FocusTrapForScreen/index.web.tsx, onActivate should move focus onto the activating screen's container instead of leaving it stranded on <body>. The target already exists: ScreenWrapperContainer's root View is programmatically focusable (tabIndex={-1}), and ScreenWrapper already holds a ref to it (screenWrapperRef), so we thread that ref into FocusTrapForScreen as a new optional containerRef prop (added to FocusTrapProps; the native index.tsx passthrough ignores it) and use it after the existing INPUT/TEXTAREA early return:

const container = containerRef?.current;
if (container instanceof HTMLElement) {
    container.focus({preventScroll: true});
} else {
    activeElement?.blur();
}

App/src/components/ScreenWrapper/ScreenWrapperContainer.tsx

Lines 220 to 224 in a4b6ddf

	style={[styles.flex1, styles.appBG, styles.screenWrapperContainerMinHeight(minHeight)]}
	{...panResponder.panHandlers}
	testID={testID}
	fsClass={forwardedFSClass}
	tabIndex={-1}

Focusing the container implicitly blurs the clicked row (so it strictly strengthens what the existing blur() already does) and puts document.activeElement inside the RHP, so the browser retargets keyboard scrolling to the RHP pane — which has no scrollable ancestor, so arrow keys do nothing, exactly matching the expected result. This is safe for other consumers: the INPUT/TEXTAREA guard is untouched so screens with an already-focused text field behave as today, pages that autofocus their own input still win focus after the transition as they do now, preventScroll: true avoids any scroll jump, and tabIndex={-1} keeps the container out of the Tab order so Tab navigation inside the trap is unchanged. To verify, repeat QA steps 6-8 (categories list no longer moves and document.activeElement is the RHP container), re-run steps 2-5 on Taxes, and check an RHP with an autofocused input (e.g. renaming a category) still autofocuses.

What alternative solutions did you explore? (Optional)

Removing the e.preventDefault() from TableRow's onMouseDown doesn't help — my harness confirmed the trap's blur-to-body recreates the broken state regardless of whether the row was focused first. I also considered preventDefault-ing Arrow keydowns that target <body> while a screen trap is active, but that would also kill legitimate arrow-key scrolling of the RHP's own ScrollView (those keydowns target <body> too), and a per-page arrow-key subscription on WorkspaceCategoriesPage would just be whack-a-mole across every Table-based page.

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-23 19:18:35 UTC.

Proposal

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

With a category-settings RHP open over Workspace > Categories (wide layout, without clicking into the RHP), pressing ArrowUp/ArrowDown scrolls the categories list behind the RHP. Expected: arrow keys do nothing while the RHP is open, exactly as on the Taxes page.

What is the root cause of that problem?

The scrolling is the browser's native keyboard scroll landing on a background list that was never made focus-aware — not any arrow-key handling in our code.

Two things put us in the "nothing is focused" state:

1. Clicking a category row never moves DOM focus into it — TableRow.onMouseDown calls preventDefault() (intentional; it keeps the table's search input from losing focus):
   

   App/src/components/Table/TableRow.tsx

   Lines 198 to 216 in a4b6ddf

   	onMouseDown={(e) => {
   	const target = e?.target;
   	if (!(target instanceof HTMLElement)) {
   	e.preventDefault();
   	return;
   	}
   	if (target.tagName === CONST.ELEMENT_NAME.INPUT) {
   	return;
   	}
   	if (target.closest('[role="switch"]') || target.closest('[role="checkbox"]')) {
   	e.preventDefault();
   	return;
   	}
   	e.preventDefault();
   	}}

2. When the RHP mounts, FocusTrapForScreen.onActivate blurs whatever was focused and, with initialFocus: false, focuses nothing itself — so document.activeElement ends up on <body>:
   

   App/src/components/FocusTrap/FocusTrapForScreen/index.web.tsx

   Lines 50 to 66 in a4b6ddf

   	onActivate: () => {
   	const activeElement = document?.activeElement as HTMLElement;
   	if (activeElement?.nodeName === CONST.ELEMENT_NAME.INPUT || activeElement?.nodeName === CONST.ELEMENT_NAME.TEXTAREA) {
   	return;
   	}
   	activeElement?.blur();
   	},
   	trapStack: sharedTrapStack,
   	allowOutsideClick: true,
   	// Clicking outside should break the trap so side panel can remain interactive.
   	clickOutsideDeactivates: true,
   	// Synthetic Escape events dispatched by cancelDndKeyboardDrag are only
   	// meant for the dnd-kit KeyboardSensor. Ignore them so the trap stays active.
   	escapeDeactivates: () => !isCancellingDndKeyboardDrag(),
   	fallbackFocus: document.body,
   	delayInitialFocus: CONST.ANIMATED_TRANSITION,
   	initialFocus: false,

With nothing focused, Blink resolves arrow-key scrolling from the node of the last mouse press — the category row you just clicked — and scrolls its nearest scrollable ancestor: the categories list. That's why the repro insists "do not click on the RHP" (clicking moves the press anchor into the RHP), and why it's Chrome-specific.

The reason nothing stops it: the categories list renders through the shared Table component, whose FlashList has no focus gating at all:

App/src/components/Table/TableBody.tsx

Lines 100 to 118 in a4b6ddf

	<FlashList<DataType>
	ref={listRef}
	data={filteredAndSortedData}
	style={[styles.flex1, styles.mnh0]}
	showsVerticalScrollIndicator={false}
	maintainVisibleContentPosition={{disabled: true}}
	contentContainerStyle={[
	filteredAndSortedData.length === 0 && styles.flexGrow1,
	listContentContainerStyle,
	tableBodyContentContainerStyle,
	contentContainerStyle,
	shouldUseNarrowTableLayout &&
	typeof contentMinHeight === 'number' &&
	typeof tableBodyBottomPadding === 'number' && {minHeight: contentMinHeight + tableBodyBottomPadding},
	]}
	keyboardShouldPersistTaps="handled"
	ListHeaderComponent={ListHeaderComponent}
	ListEmptyComponent={ListEmptyComponent}
	{...restListProps}

The list Table replaced — BaseSelectionList — does gate scrolling on navigation focus via the useScrollEnabled hook (returns useIsFocused() on web, undefined on native):

App/src/components/SelectionList/BaseSelectionList.tsx

Line 107 in a4b6ddf

const scrollEnabled = useScrollEnabled();

→

App/src/components/SelectionList/BaseSelectionList.tsx

Line 514 in a4b6ddf

scrollEnabled={scrollEnabled}

hook:

App/src/hooks/useScrollEnabled/index.ts

Lines 5 to 8 in a4b6ddf

	const useScrollEnabled: UseScrollEnabled = () => {
	const isFocused = useIsFocused();
	return isFocused;
	};

Table never adopted it, so any Table left behind an RHP stays keyboard-scrollable. This is not specific to Categories — Table backs Tags, Members, Taxes, distance rates, per diem, report fields, etc. Taxes only looks correct because a default workspace has a couple of tax rates and the list doesn't overflow; with enough rows it reproduces too. So the fix belongs in the shared Table, once.

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

Restore the focus gating Table dropped — subscribe TableBody to useScrollEnabled and pass it to the FlashList, mirroring what BaseSelectionList has shipped since PR #56435.

In src/components/Table/TableBody.tsx:

import useScrollEnabled from '@hooks/useScrollEnabled';

// inside TableBody:
const scrollEnabled = useScrollEnabled();

// on the FlashList:
scrollEnabled = {scrollEnabled};

While the screen is focused, scrollEnabled is true — today's behavior, so mouse/keyboard scrolling is untouched. When an RHP is pushed on top, useIsFocused() for the background screen turns false, react-native-web sets overflow: hidden, and the browser has nothing to keyboard-scroll; on close, focus returns and scroll re-enables with position preserved. On native the hook returns undefined, so scrollEnabled is not forced off and native is unchanged.

What specific scenarios should we cover in automated tests?

• Open a category-settings RHP over a Categories list tall enough to overflow, dispatch ArrowUp/ArrowDown without clicking the RHP, and assert the background list's scroll offset stays at 0.
• Regression: with the Categories screen focused (no RHP), the list still scrolls normally.
• Native: useScrollEnabled returns undefined, so scrollEnabled is not forced off.

What alternative solutions did you explore? (Optional)

• Claim focus into the RHP on trap activation (focus the screen container in FocusTrapForScreen.onActivate): it works, but it reverses the deliberate initialFocus: false design and changes focus behavior for every screen the trap wraps — a broader surface for a bug that a one-prop scroll lock closes at the source.
• Per-page fix on Categories only: whack-a-mole — every other Table-backed screen keeps the identical bug.
• Global keydown listener that preventDefaults arrow keys while a trap is active: adds per-keypress work app-wide and only patches two keys, while PageDown/Home/End/Space scroll the same background list.

One thing worth flagging for the assignee: Table today has no keyboard row-navigation at all (unlike BaseSelectionList's useSelectionListKeyboardFocus). Scroll-gating is the correct minimal fix for this bug, but if arrow-key row focus is expected on these tables, Table should adopt the full focus model rather than only disabling scroll.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-23 19:58:40 UTC.

Proposal

What is the root cause of that problem?

The category page renders its rows through the shared Table.Body, whose FlashList does not disable scrolling when its navigation screen loses focus. The list therefore stays a native browser scroll target after an RHP covers it.

App/src/components/Tables/WorkspaceCategoriesTable/index.tsx

Lines 148 to 172 in b444723

	return (
	<Table
	ref={ref}
	data={categories}
	initialSortColumn="name"
	selectionEnabled={selectionEnabled}
	title={translate('workspace.common.categories')}
	columns={categoryTableColumns}
	compareItems={compareItems}
	isItemInSearch={isItemInSearch}
	renderItem={renderCategoryItem}
	selectedKeys={selectedKeys}
	keyExtractor={(category) => category.keyForList}
	onRowSelectionChange={onRowSelectionChange}
	>
	<Table.FilterBar label={translate('workspace.categories.findCategory')} />
	<Table.EmptyState
	title={translate('workspace.categories.emptyCategories.title')}
	subtitleText={emptyStateSubtitleText}
	headerStyles={styles.emptyStateCardIllustrationContainer}
	buttons={emptyStateButtons}
	/>
	<Table.NoResultsState />
	<Table.Header />
	<Table.Body />

App/src/components/Table/TableBody.tsx

Lines 95 to 119 in b444723

	return (
	<View
	style={[styles.flex1, styles.mnh0, style]}
	{...props}
	>
	<FlashList<DataType>
	ref={listRef}
	data={filteredAndSortedData}
	style={[styles.flex1, styles.mnh0]}
	showsVerticalScrollIndicator={false}
	maintainVisibleContentPosition={{disabled: true}}
	contentContainerStyle={[
	filteredAndSortedData.length === 0 && styles.flexGrow1,
	listContentContainerStyle,
	tableBodyContentContainerStyle,
	contentContainerStyle,
	shouldUseNarrowTableLayout &&
	typeof contentMinHeight === 'number' &&
	typeof tableBodyBottomPadding === 'number' && {minHeight: contentMinHeight + tableBodyBottomPadding},
	]}
	keyboardShouldPersistTaps="handled"
	ListHeaderComponent={ListHeaderComponent}
	ListEmptyComponent={ListEmptyComponent}
	{...restListProps}
	/>

The pointer flow exposes that missing guard. The category row action opens its settings RHP, while TableRow prevents the normal mousedown focus transfer and the RHP's screen trap blurs a non-input launcher while leaving initialFocus disabled and falling back to document.body. Chrome can then route ArrowUp/ArrowDown to the scrollable region associated with the last pointer press—the background category FlashList.

App/src/pages/workspace/categories/WorkspaceCategoriesPage.tsx

Lines 221 to 229 in b444723

	const navigateToCategory = useCallback(
	(category: PolicyCategories[string]) => {
	const path = isQuickSettingsFlow
	? createDynamicRoute(DYNAMIC_ROUTES.SETTINGS_CATEGORY_SETTINGS.getRoute(category.name))
	: createDynamicRoute(DYNAMIC_ROUTES.WORKSPACE_CATEGORY_SETTINGS.getRoute(category.name));
	Navigation.navigate(path);
	},
	[isQuickSettingsFlow],

App/src/components/Table/TableRow.tsx

Lines 187 to 217 in b444723

	<PressableWithFeedback
	accessible={accessible}
	accessibilityLabel="row"
	id={`table-row-${item.keyForList}`}
	style={tableRowPressableStyles}
	sentryLabel={sentryLabel}
	interactive={interactive}
	disabled={isDisabled}
	hoverStyle={tableRowPressableHoverStyle}
	pressDimmingValue={!interactive ? undefined : 1}
	role={interactive ? CONST.ROLE.BUTTON : CONST.ROLE.PRESENTATION}
	onMouseDown={(e) => {
	const target = e?.target;
	if (!(target instanceof HTMLElement)) {
	e.preventDefault();
	return;
	}
	if (target.tagName === CONST.ELEMENT_NAME.INPUT) {
	return;
	}
	if (target.closest('[role="switch"]') || target.closest('[role="checkbox"]')) {
	e.preventDefault();
	return;
	}
	e.preventDefault();
	}}
	onPress={(event) => handleRowPress(event)}

App/src/components/FocusTrap/FocusTrapForScreen/index.web.tsx

Lines 44 to 68 in b444723

	return (
	<FocusTrap
	active={isActive}
	paused={!isFocused}
	containerElements={focusTrapSettings?.containerElements?.length ? focusTrapSettings.containerElements : undefined}
	focusTrapOptions={{
	onActivate: () => {
	const activeElement = document?.activeElement as HTMLElement;
	if (activeElement?.nodeName === CONST.ELEMENT_NAME.INPUT || activeElement?.nodeName === CONST.ELEMENT_NAME.TEXTAREA) {
	return;
	}
	activeElement?.blur();
	},
	trapStack: sharedTrapStack,
	allowOutsideClick: true,
	// Clicking outside should break the trap so side panel can remain interactive.
	clickOutsideDeactivates: true,
	// Synthetic Escape events dispatched by cancelDndKeyboardDrag are only
	// meant for the dnd-kit KeyboardSensor. Ignore them so the trap stays active.
	escapeDeactivates: () => !isCancellingDndKeyboardDrag(),
	fallbackFocus: document.body,
	delayInitialFocus: CONST.ANIMATED_TRANSITION,
	initialFocus: false,
	setReturnFocus: false,
	...(focusTrapSettings?.focusTrapOptions ?? {}),

This is not category-specific. Taxes uses the same table stack, but the recorded tax list has only five rows and cannot visibly scroll. Other overflowing Table-backed screens can expose the same behavior.

The older SelectionList already avoids this bug class: useScrollEnabled returns the route's focus state on web, is a native no-op, and is passed to its FlashList. The generic Table.Body omitted that established contract.

App/src/hooks/useScrollEnabled/index.ts

Lines 1 to 8 in b444723

	import {useIsFocused} from '@react-navigation/native';
	import type UseScrollEnabled from './types';
	const useScrollEnabled: UseScrollEnabled = () => {
	const isFocused = useIsFocused();
	return isFocused;
	};

App/src/hooks/useScrollEnabled/index.native.ts

Lines 1 to 5 in b444723

	import type UseScrollEnabled from './types';
	const useScrollEnabled: UseScrollEnabled = () => undefined;
	export default useScrollEnabled;

App/src/components/SelectionList/BaseSelectionList.tsx

Lines 103 to 108 in b444723

	setShouldDisableHoverStyle = () => {},
	}: SelectionListProps<ListItem>) {
	const styles = useThemeStyles();
	const isFocused = useIsFocused();
	const scrollEnabled = useScrollEnabled();
	const {singleExecution} = useSingleExecution();

App/src/components/SelectionList/BaseSelectionList.tsx

Lines 507 to 515 in b444723

	data={data}
	renderItem={renderItem}
	ref={listRef}
	keyExtractor={(item) => item.keyForList}
	extraData={extraData}
	ListFooterComponent={listFooterContent}
	ListFooterComponentStyle={style?.listFooterContentStyle}
	scrollEnabled={scrollEnabled}
	indicatorStyle="white"

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

Apply the existing useScrollEnabled hook in TableBody and pass its result to the shared FlashList. Place scrollEnabled={scrollEnabled} after the spread of restListProps so an individual table cannot accidentally re-enable a covered background list.

On web, the hook will make every Table-backed list non-scrollable while its hosting screen is covered by an RHP, then restore scrolling and preserve the offset when that screen regains focus. It does not disable the category RHP's own ScrollView, and native behavior remains unchanged because the native hook returns undefined.

App/src/pages/workspace/categories/CategorySettingsPage.tsx

Lines 267 to 279 in b444723

	<ScreenWrapper
	enableEdgeToEdgeBottomSafeAreaPadding
	style={[styles.defaultModalContainer]}
	testID="CategorySettingsPage"
	>
	<HeaderWithBackButton
	title={decodedCategoryName}
	onBackButtonPress={navigateBack}
	/>
	<ScrollView
	contentContainerStyle={[styles.flexGrow1]}
	addBottomSafeAreaPadding
	>

App/src/components/Table/TableBody.tsx

Lines 52 to 66 in b444723

	function TableBody<DataType extends TableData>({contentContainerStyle, style, ...props}: TableBodyProps) {
	const styles = useThemeStyles();
	const {translate} = useLocalize();
	const {
	processedData: filteredAndSortedData,
	activeSearchString,
	listProps,
	listRef,
	shouldUseNarrowTableLayout,
	hasActiveFilters,
	hasSearchString,
	isEmptyResult,
	originalDataLength,
	} = useTableContext<DataType>();
	const {contentContainerStyle: listContentContainerStyle, ListEmptyComponent, ListHeaderComponent, ...restListProps} = listProps ?? {};

App/src/components/Table/TableBody.tsx

Lines 100 to 119 in b444723

	<FlashList<DataType>
	ref={listRef}
	data={filteredAndSortedData}
	style={[styles.flex1, styles.mnh0]}
	showsVerticalScrollIndicator={false}
	maintainVisibleContentPosition={{disabled: true}}
	contentContainerStyle={[
	filteredAndSortedData.length === 0 && styles.flexGrow1,
	listContentContainerStyle,
	tableBodyContentContainerStyle,
	contentContainerStyle,
	shouldUseNarrowTableLayout &&
	typeof contentMinHeight === 'number' &&
	typeof tableBodyBottomPadding === 'number' && {minHeight: contentMinHeight + tableBodyBottomPadding},
	]}
	keyboardShouldPersistTaps="handled"
	ListHeaderComponent={ListHeaderComponent}
	ListEmptyComponent={ListEmptyComponent}
	{...restListProps}
	/>

Test coverage: add a TableBody test that mocks useScrollEnabled and verifies the value is forwarded after consumer list props. Add web UI coverage with a long category table in both Workspace Categories and the quick-settings route: open a category row by pointer, record the background list offset, press ArrowUp, ArrowDown, Space, and PageDown, and verify the offset is unchanged. Navigate into a nested category screen and verify the RHP's own controls and scrollable content remain usable, then close the RHP and verify normal background scrolling resumes at the preserved offset. Also cover a long tax table or another shared Table screen to prove the fix is not category-specific.

What alternative solutions did you explore? (Optional)

Category-local no-op arrow shortcuts would fix only two keys on one screen and leave every other Table-backed page exposed. A document-level key listener has the same per-key limitation. Moving pointer focus into every RHP could also stop Chrome's fallback, but it changes shared focus behavior. Removing the category RHP's ScrollView would make expanding settings unreachable and targets the stationary layer. Reusing the existing focus-aware scroll contract in the component that creates the background scroll target fixes the full browser-scroll class with the smallest established change.

[melvin-bot]

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