[$250] Up/Down arrow keys on the Reports > Reports page do not focus the top/bottom items correctly.

[m-natarajan]

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: 9.3.54-1
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @dmkt9
Slack conversation (hyperlinked to channel name): #Open Source

Action Performed:

Prerequisite: The user has several reports.

1. Open the application in a web browser
2. Navigate to Reports > Reports
3. Use the up/down arrow keys to navigate focus

Expected Result:

When at the top or bottom of the list, pressing the up or down arrow key should immediately focus the item at the opposite end of the list.

Actual Result:

The up/down arrow keys must be pressed multiple times before the focus returns to the top or bottom of the list.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

Recording.2662.mp4

untitled.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @marcochavezf

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022041863440172893172
• Upwork Job ID: 2041863440172893172
• Last Price Increase: 2026-04-08

[MelvinBot]

Proposal

What is the root cause of that problem?

In BaseSearchList, the useArrowKeyFocusManager hook is initialized with maxIndex: flattenedItemsLength - 1 (BaseSearchList/index.tsx:51). flattenedItemsLength is the total count of individual transactions across all report groups, computed in SearchList/index.tsx:225-233. However, the FlashList only renders data.length items (the report group rows, not individual transactions).

This creates a mismatch: the arrow key focus manager cycles through indices 0 to flattenedItemsLength - 1, but only indices 0 to data.length - 1 correspond to rendered items. When focus wraps (e.g., pressing ArrowDown past the last visible item), it traverses all the "ghost" indices one key press at a time — none of which match any rendered item — before reaching a visible item at the opposite end.

For example, 5 report groups containing 20 total transactions means maxIndex = 19 but only indices 0–4 are visible. Pressing ArrowDown at index 4 requires 16 presses (4→5→6→…→19→0) to wrap back to the top.

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

Change maxIndex in BaseSearchList/index.tsx:51 from flattenedItemsLength - 1 to data.length - 1 for the arrow key focus manager, so that keyboard navigation only cycles through actually rendered list items.

flattenedItemsLength should continue to be used where it's needed for select-all/checkbox counting logic, but it should not govern keyboard navigation bounds.

What alternative solutions did you explore? (Optional)

An alternative would be to pass disabledIndexes to useArrowKeyFocusManager for all indices >= data.length, but this is unnecessarily complex when simply correcting maxIndex achieves the same result more cleanly.

---

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.

[MobileMage]

Proposal

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

On the Reports > Reports page, pressing the Up or Down arrow key does not immediately wrap focus to the opposite end of the list when the first or last item is already focused. Instead, several extra keypresses are required before the cyclic wrap occurs.

What is the root cause of that problem?

SearchList passes flattenedItemsLength={flattenedItems.length} to BaseSearchList, which in turn uses that value as maxIndex in useArrowKeyFocusManager. For the EXPENSE_REPORT data type (the Reports > Reports page), flattenedItems is computed by calling .flatMap((item) => item.transactions) on the raw data array — it is a flat list of individual transactions, not report-level rows. However, the data prop given to the underlying FlashList is the raw data array (one entry per report group), not the flattened transactions. This means maxIndex equals the total number of transactions across all reports, which is far larger than the actual number of rendered list rows. The arrow-key focus manager therefore increments/decrements through many out-of-range phantom indexes before reaching the boundary and triggering the cyclic wrap to the opposite end.

App/src/components/Search/SearchList/index.tsx

Line 536 in 946de58

flattenedItemsLength={flattenedItems.length}

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

The flattenedItemsLength prop should reflect the count of items that are actually rendered in the FlashList — that is, data.length (the raw prop), not flattenedItems.length. The flattenedItems computation is used for selection-counting logic and can stay as-is; only the value forwarded to BaseSearchList needs to change.

App/src/components/Search/SearchList/index.tsx

Lines 526 to 546 in 946de58

	<BaseSearchList
	data={data}
	renderItem={renderItem}
	onSelectRow={onSelectRow}
	keyExtractor={keyExtractor}
	onScroll={onScroll}
	showsVerticalScrollIndicator={false}
	ref={listRef}
	columns={columns}
	scrollToIndex={scrollToIndex}
	flattenedItemsLength={flattenedItems.length}
	onEndReached={onEndReached}
	onEndReachedThreshold={onEndReachedThreshold}
	ListFooterComponent={ListFooterComponent}
	onViewableItemsChanged={onViewableItemsChanged}
	onLayout={onLayout}
	contentContainerStyle={contentContainerStyle}
	newTransactions={newTransactions}
	selectedTransactions={selectedTransactions}
	customCardNames={customCardNames}
	/>

- flattenedItemsLength={flattenedItems.length}
+ flattenedItemsLength={data.length}

With this change, maxIndex in useArrowKeyFocusManager matches the real number of rendered rows, so pressing Down on the last row immediately wraps to the top, and pressing Up on the first row immediately wraps to the bottom, as expected.

What alternative solutions did you explore? (Optional)

N/A

[melvin-bot]

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

[melvin-bot]

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

[abbasifaizan70]

Proposal

What is the root cause of that problem?

The keyboard focus manager in the search reports list uses a maxIndex derived from flattenedItemsLength, but the list that actually receives focus is rendered from data. In grouped report views, flattenedItemsLength can be much larger than data.length (for example, group rows vs. all child transactions), so arrow navigation steps through non-rendered indexes before it wraps. That is why users need multiple up/down presses before focus appears again at the opposite end.

App/src/components/Search/SearchList/index.tsx

Lines 225 to 233 in 24db80a

	const flattenedItems = useMemo(() => {
	if (groupBy || type === CONST.SEARCH.DATA_TYPES.EXPENSE_REPORT) {
	if (!isTransactionGroupListItemArray(data)) {
	return data;
	}
	return data.flatMap((item) => item.transactions);
	}
	return data;
	}, [data, groupBy, type]);

App/src/components/Search/SearchList/index.tsx

Lines 526 to 537 in 24db80a

	<BaseSearchList
	data={data}
	renderItem={renderItem}
	onSelectRow={onSelectRow}
	keyExtractor={keyExtractor}
	onScroll={onScroll}
	showsVerticalScrollIndicator={false}
	ref={listRef}
	columns={columns}
	scrollToIndex={scrollToIndex}
	flattenedItemsLength={flattenedItems.length}
	onEndReached={onEndReached}

App/src/components/Search/SearchList/BaseSearchList/index.tsx

Lines 49 to 53 in 24db80a

	const [focusedIndex, setFocusedIndex] = useArrowKeyFocusManager({
	initialFocusedIndex: -1,
	maxIndex: flattenedItemsLength - 1,
	isActive: isFocused,
	onFocusedIndexChange: (index: number) => {

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

App/src/components/Search/SearchList/index.tsx

Lines 526 to 537 in 24db80a

	<BaseSearchList
	data={data}
	renderItem={renderItem}
	onSelectRow={onSelectRow}
	keyExtractor={keyExtractor}
	onScroll={onScroll}
	showsVerticalScrollIndicator={false}
	ref={listRef}
	columns={columns}
	scrollToIndex={scrollToIndex}
	flattenedItemsLength={flattenedItems.length}
	onEndReached={onEndReached}

<BaseSearchList
    flattenedItemsLength={data.length}
/>

App/src/components/Search/SearchList/BaseSearchList/types.ts

Line 34 in 24db80a

flattenedItemsLength: number;

focusableItemsLength: number;

App/src/components/Search/SearchList/BaseSearchList/index.tsx

Lines 49 to 53 in 24db80a

	const [focusedIndex, setFocusedIndex] = useArrowKeyFocusManager({
	initialFocusedIndex: -1,
	maxIndex: flattenedItemsLength - 1,
	isActive: isFocused,
	onFocusedIndexChange: (index: number) => {

const [focusedIndex, setFocusedIndex] = useArrowKeyFocusManager({
    initialFocusedIndex: -1,
    maxIndex: focusableItemsLength - 1,
    isActive: isFocused,
    onFocusedIndexChange: (index: number) => {

[github-actions]

⚠️ @abbasifaizan70 Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[abbasifaizan70]

@ZhenjaHorbach, I added the proposal after the External and Help wanted labels. Please take this while reviewing proposals. Thanks

[hamza-nafasat]

Proposal

Problem

Arrow key navigation requires multiple presses to wrap focus from the last item to the first (and vice versa) in Reports > Reports.

Root Cause

The focus manager (useArrowKeyFocusManager) is using flattenedItemsLength as maxIndex, while the UI only renders data.length items.

This creates a mismatch:

• Focus logic iterates over all flattened transaction indices
• UI only has grouped report rows

Result:
Focus traverses non-rendered “virtual” indices before reaching a valid item.

Solution

Decouple focusable item count from flattened data count.

Implementation

1. Introduce a dedicated prop for focus logic:

focusableItemsLength = data.length

2. Pass it explicitly to BaseSearchList:

<BaseSearchList
  ...
  focusableItemsLength={data.length}
/>

3. Update focus manager usage:

maxIndex: focusableItemsLength - 1

4. Keep flattenedItemsLength unchanged for selection/count logic.

Why this approach

• Fixes bug (correct wrap behavior)
• Avoids breaking existing logic using flattened items
• Makes intent explicit (rendered vs logical data)
• Prevents similar bugs in future

Validation

• Press ↓ on last item → jumps to first ✅
• Press ↑ on first item → jumps to last ✅
• Works with grouped reports ✅
• No regression in selection/count logic ✅