Suggestion List - User is unable to navigate through the suggestion list with arrow key

[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.34-2
Reproducible in staging?: Yes
Reproducible in production?: No
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/64635567/folder/13176723/41237045/1567083031?sort=%2Bidentifier
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Web
App Component: Other

Action Performed:

1. Navigate to ND
2. Go to a room
3. Type @ in the compose box
4. Try to use the up or down arrow key to navigate on the suggestion list

Expected Result:

User should be able to navigate through the suggestion list with the arrow key

Actual Result:

Suggestion list selection remains in the first option when using the arrow keyboard to navigate.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7208181_1784040435439.ExpensifyCantNavigateSuggestList.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7208181

[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/b8434f774a90ad6c9a58675580ca0e99a14ca5327d31ebedbf68b3a21068ae1a

[melvin-bot]

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

[melvin-bot]

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

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Issue Analysis

Root Cause: This is a build-toolchain regression, not an App source bug. Every runtime file in the arrow-key path is byte-for-byte identical between production (v9.4.33-8) and staging (v9.4.34-2) — useArrowKeyFocusManager.ts, SuggestionMention.tsx, SuggestionEmoji.tsx, Suggestions.tsx, and BaseAutoCompleteSuggestions.tsx are all unchanged. What changed is how the web bundle is compiled: #93980 ([No QA] Swap babel-loader + babel-plugin-react-compiler for OXC, merged 2026-07-14 01:15, in this deploy checklist) replaced babel-plugin-react-compiler with a new custom OXC-based React Compiler loader whose own header comment notes the OXC compiler was buggy enough to crash builds. The stuck-on-first-option symptom is the classic signature of a React Compiler memoization bug: the arrow-key handler is an inline callback that the compiler auto-memoizes, and under OXC it appears to capture a stale index, so setFocusedIndexInternal never advances while the recurring setHighlightedMentionIndex(0) re-pins selection to the first row.

Recommended Fix (deploy blocker): Revert #93980 to restore the babel-plugin-react-compiler path that works in production. The Rsbuild/Rspack migration (#95319) can stay — the regression is specifically the React Compiler backend swap, not the bundler swap. If a revert isn't desirable, disabling the OXC React Compiler (reactCompiler: false in config/rsbuild/loaders/oxc-react-compiler-loader.mjs) should confirm and unblock while the OXC codegen bug is fixed upstream.

Quick confirmation: The bug should reproduce on web only (OXC path) and not on native (native still uses Metro/Babel). If native is unaffected, that alone isolates it to the OXC loader.

Investigation details & evidence

Symptom: Type @ in the compose box → suggestion list appears → Up/Down arrow keys don't move the highlight; it stays on the first option. Reproducible in staging (v9.4.34-2), not production.

Arrow-key state machine — logic is correct and unchanged from production:

• App/src/hooks/useArrowKeyFocusManager.ts:73-90 — focusState + setFocusedIndexInternal
• App/src/hooks/useArrowKeyFocusManager.ts:113-191 — inline arrowUp/arrowDown callbacks wired via useKeyboardShortcut. These are defined inline (not useCallback) and capture maxIndex/focusState — exactly what the React Compiler auto-memoizes, and exactly what breaks if the compiler backend mis-memoizes.

Mention wiring — setHighlightedMentionIndex(0) runs on every suggestion recalculation, which is the mechanism that re-pins to index 0 when the arrow write is lost:

• App/src/pages/inbox/report/ReportActionCompose/SuggestionMention.tsx:113-117 (hook use), :544 (setHighlightedMentionIndex(0))

What actually changed (v9.4.33-8 → v9.4.34-2):

• [No QA] Swap babel-loader + babel-plugin-react-compiler for OXC (Rust React Compiler) #93980 — swapped babel-plugin-react-compiler for a custom OXC loader: App/config/rsbuild/loaders/oxc-react-compiler-loader.mjs, wired in App/config/rsbuild/rsbuild.common.ts:43-55 and :265-277 (compiles all app .ts/.tsx).
• App/babel.config.js — the web branch that applied babel-plugin-react-compiler was removed; web now returns an empty babel config.
• Both [No QA] Swap babel-loader + babel-plugin-react-compiler for OXC (Rust React Compiler) #93980 and [No QA] Migrate web builds and Storybook from Webpack to Rspack/Rsbuild #95319 are checked in on the current deploy checklist (Deploy Checklist: New Expensify 2026-07-14 #96044).

Alternatives considered: A source-level regression in the suggestion components — ruled out because the files diff clean against the production branch. A pure Rsbuild/bundler issue — less likely, since #95319 (bundler) merged 2026-07-10 without this report, whereas #93980 (compiler backend) merged the morning of this v9.4.34-2 report.

Confidence: Medium-High. Code evidence is strong (identical source + isolated compiler-backend change + [No QA] label + timing). Not yet confirmed with a compiled-bundle diff or a browser repro toggling reactCompiler: false.

---

This is a build-tooling regression owned outside typical contributor scope — best handled by an internal engineer (the author of #93980) reverting or gating the OXC React Compiler.

Next Steps for Contributor+ team:
To accept: @MelvinBot implement this to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug (build-toolchain regression in Expensify/App)
Causing PR: #93980 - "[No QA] Swap babel-loader + babel-plugin-react-compiler for OXC (Rust React Compiler)" by @roryabraham (High confidence)
Related Issues: #95833 (the issue #93980 fixed), #96044 (StagingDeployCash)

Recommendation: REVERT

Revert #93980 to restore the working babel-plugin-react-compiler web pipeline. It is a [No QA] build-tooling change, it is the only React-Compiler-backend change that is on staging but not yet in production, and reverting cleanly removes the OXC compiler backend that regressed the auto-memoized arrow-key handlers. If a full revert is undesirable, the equivalent narrow fix is to disable the OXC React Compiler pass (drop the reactCompiler option in config/rsbuild/rsbuild.common.ts:49) so web falls back to plain OXC transform without React-Compiler memoization.

Assigned: @roryabraham (PR author), @chuckdries (approving reviewer) from the single highest-confidence causing PR (#93980)
Labels: No changes. DeployBlockerCash is kept — this is a frontend/App bug fixed by reverting an App PR, and the App deploy remains blocked.

📋 Detailed Analysis

Evidence

• Staging-only, not production — matches the deploy diff exactly. [No QA] Swap babel-loader + babel-plugin-react-compiler for OXC (Rust React Compiler) #93980's merge commit be7b63c is present in production...staging, while [No QA] Migrate web builds and Storybook from Webpack to Rspack/Rsbuild #95319's merge commit 609f15f is absent (already in production). So the only build-tooling change that can cause a staging-only regression is [No QA] Swap babel-loader + babel-plugin-react-compiler for OXC (Rust React Compiler) #93980, not the earlier Rspack/Rsbuild bundler migration [No QA] Migrate web builds and Storybook from Webpack to Rspack/Rsbuild #95319 (merged 2026-07-10, already shipped to production without this report).
• Timing — [No QA] Swap babel-loader + babel-plugin-react-compiler for OXC (Rust React Compiler) #93980 merged 2026-07-14 01:15, the morning of the v9.4.34-2 build that this bug was first reported against.
• Platform — reported on Web (Windows Chrome) only. On web, Rsbuild does not call babel.config.js at all (see the comment and return ... : {} at the bottom of babel.config.js); the React Compiler runs via the new OXC loader. Native still uses Metro + babel-plugin-react-compiler. So the React Compiler backend now differs by platform, which is exactly why this is web-only.
• The App source files in the arrow-key path (src/hooks/useArrowKeyFocusManager.ts, src/pages/inbox/report/ReportActionCompose/SuggestionMention.tsx, SuggestionEmoji.tsx, Suggestions.tsx, BaseAutoCompleteSuggestions.tsx) were confirmed byte-identical to production — no runtime source change. What changed is only how the web bundle is compiled.

Verification

• Affected feature files: mention/emoji suggestion arrow-key navigation, driven by src/hooks/useArrowKeyFocusManager.ts (arrow callbacks at lines 113-191) and wired into mentions in src/pages/inbox/report/ReportActionCompose/SuggestionMention.tsx.
• The PR compiles these files: config/rsbuild/rsbuild.common.ts:265-277 routes all app .ts/.tsx through getOxcAndWorkletsLoaders, i.e. config/rsbuild/loaders/oxc-react-compiler-loader.mjs, with reactCompiler enabled (rsbuild.common.ts:49). So useArrowKeyFocusManager.ts is compiled by the new OXC React Compiler on web.
• Files [No QA] Swap babel-loader + babel-plugin-react-compiler for OXC (Rust React Compiler) #93980 changed include babel.config.js, config/rsbuild/rsbuild.common.ts, and the new config/rsbuild/loaders/oxc-react-compiler-loader.mjs — the exact compile path for the affected hook.

Root Cause

The suggestion list stays pinned to the first row because arrow-key presses no longer advance the focused index. useArrowKeyFocusManager relies on React-Compiler auto-memoization of the inline arrowUp/arrowDown callbacks (they are plain inline functions, not useCallback) plus a useEffectEvent wrapper (useArrowKeyFocusManager.ts:104). Under the new OXC React Compiler backend (#93980), these auto-memoized callbacks/effect-events are mis-compiled so the index write is effectively lost, while setHighlightedMentionIndex(0) in SuggestionMention.tsx re-pins selection to index 0 on each suggestion recalculation. The loader's own header comment notes it works around OXC React Compiler bugs (oxc-project/oxc#23587) and pins oxc-transform to 0.136.0 specifically to keep reactCompiler working — a fragile, newly-introduced compiler backend. The Babel-based React Compiler (used in production web and still used on native) does not exhibit this, which is why the bug is a staging-web-only regression.

#93980 vs #95319

• [No QA] Migrate web builds and Storybook from Webpack to Rspack/Rsbuild #95319 (Webpack → Rspack/Rsbuild bundler swap, merged 2026-07-10) still ran the React Compiler via Babel (@rsbuild/plugin-babel). It is already in production and did not trigger this report. Ruled out.
• [No QA] Swap babel-loader + babel-plugin-react-compiler for OXC (Rust React Compiler) #93980 (swap Babel React Compiler → OXC Rust React Compiler, merged 2026-07-14) replaced the compiler backend itself and is staging-only. This is the culprit.

Quick confirmation

Reproduce on web only vs native: native uses Metro/Babel React Compiler and should NOT reproduce. If native is unaffected while web is broken, that isolates it to the OXC loader. A build-side confirmation is to set the OXC loader's reactCompiler off (or revert to the Babel React Compiler) and re-test the arrow keys.

[MariaHCD]

Seems it might be due to the swap to OXC. I am not sure if that PR will be reverted but this UX bug doesn't need to block the app deploy, imo