fix: keyboard focus lost after Back on Enter-activated rows by TaduJR · Pull Request #97306 · Expensify/App

TaduJR · 2026-07-29T04:43:15Z

Explanation of Change

Keyboard users on pages like Settings → Profile (Legal name, Phone, Address, and similar rows) lost focus to <body> after pressing Back instead of returning to the row they activated.

Root cause: the tracker recorded the "trigger" element when React Navigation fired its state event, but by then the destination screen's text input had already synchronously autofocused. So it captured the wrong element, and on Back that element was detached and focus fell through.

Fix: latch the activation target at Enter/Space keydown — before any destination can steal focus. On Back, focus returns to the row the user actually activated.

Fixed Issues

$ #96970
PROPOSAL:

Tests

Sign in and open https://new.expensify.com/settings/profile
Press Tab until focus lands on the Legal name row.
Press Enter to open the page.
Press Tab to the Back button and press Enter.
Verify focus returns to the Legal name row — the focus ring should re-appear on that exact row
Repeat steps 2–5 for Phone number and Address.

Verify that no errors appear in the JS console

Offline tests

Same as tests

QA Steps

// TODO: These must be filled out, or the issue title must include "[No QA]."
Same as tests

Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

Mac-Chrome.mp4

melvin-bot · 2026-07-29T04:43:22Z

@mkhutornyi Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

codecov · 2026-07-29T04:47:17Z

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines	Coverage Δ
src/libs/focusReturnTimings.ts	`100.00% <100.00%> (ø)`
src/libs/NavigationFocusReturn/index.ts	`95.06% <97.19%> (+1.45%)`	⬆️
... and 10 files with indirect coverage changes

…d-Navigation-Many-Pages-The-focus-is-lost-and-does-not-return-to-triggering-element

…rgets, and background nav

TaduJR · 2026-07-29T11:49:17Z

@codex review

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a5c2ad2215

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

TaduJR · 2026-07-29T12:17:33Z

@codex review

chatgpt-codex-connector · 2026-07-29T12:25:32Z

Codex Review: Didn't find any major issues. Already looking forward to the next diff.

Reviewed commit: 038fbd9c92

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

rushatgabhane · 2026-07-29T12:58:35Z

@mkhutornyi discussion here https://expensify.slack.com/archives/C01GTK53T8Q/p1785186823036229

mkhutornyi · 2026-07-29T14:09:28Z

Root cause: the tracker recorded the "trigger" element when React Navigation fired its state event, but by then the destination screen's text input had already synchronously autofocused. So it captured the wrong element, and on Back that element was detached and focus fell through.

@TaduJR I am not sure about your RCA. Why does this issue happen only on Personal details page?
Pronouns page also has auto focused input but the issue doesn't happen.

Screen.Recording.2026-07-29.at.3.08.24.PM.mov

cc: @MelvinBot

MelvinBot · 2026-07-29T14:20:44Z

The distinguishing factor isn't whether the destination has an autofocused input — both pages do — it's when that autofocus fires relative to the trigger capture. TaduJR's RCA holds; the missing detail is "immediate autofocus vs. deferred autofocus."

Personal details (the destination is PrivatePersonalDetailsPage) focuses via the plain autoFocus prop, and BaseTextInput runs that focus in a bare mount useEffect with no timer. So the input grabs focus immediately on mount — inside the keydown→capture window — which is exactly what poisons lastInteractiveElement before the trigger is captured.
Pronouns uses SelectionList, and its search input is not focused via autoFocus. It's deferred ~300ms — setTimeout(focusTextInput, CONST.ANIMATED_TRANSITION) inside a useFocusEffect (ANIMATED_TRANSITION = 300ms). That focus lands long after the synchronous forward-capture has already run, so it can never overwrite the captured trigger — which is why Pronouns never exhibited the bug and needs no fix.

So "also has an auto focused input" is true, but the Pronouns focus is pushed 300ms past the capture window, while the personal-details focus fires right inside it. Latching the trigger at keydown fixes both cases uniformly regardless of when (or whether) the destination steals focus.

Note on the RCA wording

One precision point: the autoFocus-driven focus technically fires in a post-commit useEffect, not literally "synchronously" during render — but it fires with no delay (before paint, before any timer), so it still lands inside the keydown→capture window. The SelectionList 300ms setTimeout is what moves the Pronouns focus outside that window. If you want the RCA to be airtight, rephrasing "synchronously autofocused" → "autofocuses immediately on mount (vs. SelectionList's 300ms-deferred focus)" would match the code exactly.

Note also that the standalone BaseLegalNamePage form does not set autoFocus; the page that autofocuses the Legal name / Phone / Address fields is PrivatePersonalDetailsPage via its fieldToFocus param.

chatgpt-codex-connector · 2026-07-29T14:27:54Z

Codex Review: Didn't find any major issues. More of your lovely PRs please.

Reviewed commit: 038fbd9c92

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

MelvinBot · 2026-07-29T14:32:13Z

Code review

Verdict: Looks solid — I couldn't construct a confirmed correctness bug. The keydown-latch mechanism is unusually well-guarded: text-input vs button semantics, IME/Safari-Enter, auto-repeat, Cmd+Enter, Escape/Tab, Space-on-checkbox, and the synthetic-click-from-Enter path are all explicitly handled, and the new isActivatableTarget / isActivationKeydown / isFocusMovingKeydown helpers each carry unit coverage. Nothing below blocks; they're author-awareness notes.

Observations (all low-severity / non-blocking)

1. Stale latch could hijack a purely-programmatic forward nav (theoretical). captureTriggerForRoute evaluates keyboardTriggerFresh first, and keyup refreshes the 500ms window. If a user activates a control that does not navigate (e.g. a role="switch"/switch toggle — isActivatableTarget returns true for it) and within 500ms a programmatic forward nav fires with zero intervening mouse/focus-moving/keyboard event (Pusher-driven route change, deep link, auto-redirect), the toggle gets captured as that route's trigger and Back returns focus to it. Requires no intervening input, so it's narrow — and the pre-existing lastMouseTrigger has the same class of issue at a 3000ms TTL. Any real mouse/focus-move/nav event clears the latch first.

2. One detached node can be pinned until the next interaction. lastKeyboardTrigger holds an element ref; the TTL check blocks capture but never nulls the ref. If an activation detaches its own target without navigating, that single node is retained until the next keydown/mouse/focus-move/nav/teardown. Bounded (one node, not growing) and identical to the existing lastMouseTrigger/lastInteractiveElement pattern — just noting it's the same tradeoff.

3. Minor skip-path inconsistency. notifyPushParamsBackward's skip branch deliberately preserves lastInteractiveElement for a synchronous back→forward follow-up, but the stack backward+skip path in handleStateChange falls through to the unified clearTransientCaptures() and clears everything. I couldn't build a failing flow (a synchronous stack back-then-forward collapses into a single diffNavigationState action, so the two-step clear-then-capture doesn't occur for stack nav — only PUSH_PARAMS, which is handled separately). Worth a sanity check that no real flow dispatches a stack goBack (with skipNextFocusRestore) immediately followed by a separate Navigation.navigate in the same tick.

Not defects: the keydown/keyup isSpace asymmetry is correct (keydown's .code+.key check is only used in the rejected branch; keyup's .code-only check plus the strict e.target !== latch correctly mirror RNW's isActiveElement press-cancellation, since keyboard events target the focused element). The noop exclusion from the unified clear is intentional and bounded by the TTL.

mkhutornyi · 2026-07-29T14:36:37Z

Reviewer Checklist

I have verified the author checklist is complete (all boxes are checked off).
I verified the correct issue is linked in the ### Fixed Issues section above
I verified testing steps are clear and they cover the changes made in this PR
- I verified the steps for local testing are in the Tests section
- I verified the steps for Staging and/or Production testing are in the QA steps section
- I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
- I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
I checked that screenshots or videos are included for tests on all platforms
I included screenshots or videos for tests on all platforms
I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
I verified tests pass on all platforms & I tested again on:
- Android: HybridApp
- Android: mWeb Chrome
- iOS: HybridApp
- iOS: mWeb Safari
- MacOS: Chrome / Safari
If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
I verified proper code patterns were followed (see Reviewing the code)
- I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
- I verified that comments were added to code that is not self explanatory
- I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
- I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
I verified that this PR follows the guidelines as stated in the Review Guidelines
I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
If a new component is created I verified that:
- A similar component doesn't exist in the codebase
- All props are defined accurately and each prop has a /** comment above it */
- The file is named correctly
- The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
- The only data being stored in the state is data necessary for rendering and nothing else
- For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
- Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
- All JSX used for rendering exists in the render method
- The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
If any new file was added I verified that:
- The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
If a new CSS style is added I verified that:
- A similar style doesn't already exist
- The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
- I verified that all the inputs inside a form are aligned with each other.
- I added Design label and/or tagged @Expensify/design so the design team can review the changes.
For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

Screen.Recording.2026-07-29.at.3.40.12.PM.mov

Android: mWeb Chrome

iOS: HybridApp

iOS: mWeb Safari

MacOS: Chrome / Safari

Screen.Recording.2026-07-29.at.3.40.51.PM.mov

MelvinBot · 2026-07-29T14:40:26Z

🤖 Regression sweep — no confirmed regressions found. I ran an adversarial review across the three risk areas of this diff (capture lifecycle changes, the new global keyboard listeners, and platform/test coverage). Everything material checks out. A few low-severity notes are below, none blocking.

What I verified is safe

No native crash. NavigationFocusReturn is platform-split — the PR only touches the web index.ts, and native uses an untouched index.native.ts. All new document.addEventListener / performance.now() calls sit behind the existing typeof document === 'undefined' guard in setupNavigationFocusReturn, so native (no document) never runs them.
No typing/shortcut breakage. Neither keyActivationHandler nor keyReleaseHandler ever calls preventDefault / stopPropagation / mutates the event — they're pure readers (index.ts:441-497). Space-to-scroll and native button activation are untouched.
Chat composer excluded. The report composer is a contentEditable role="textbox", and isActivatableTarget rejects contenteditable/<textarea> before the interactive-role check, so pressing Enter to send never latches or mis-restores focus. IME/composition (CJK, Safari keyCode 229) is correctly rejected on three fronts.
No listener leaks. The new keydown/keyup pair follows the exact add-guard/remove/null pattern as the existing focusin/mouse handlers; teardown removes both with the matching capture flag.
Lifecycle refactor is net-safer. Moving clearTransientCaptures() out of the forward branch into a trailing forward || backward || lateral block extends clearing (base only cleared on forward); the noop exclusion already existed in base and is correct (a noop is a same-route setParams — clearing there would destroy a legitimate trigger). Restores read only triggerMap, so the added PUSH_PARAMS clearing can't blank a restore. focusReturnTimings export rewrite is purely additive.

Low-severity notes (not regressions — worth a glance)

Details

Per-keystroke UA regex (perf, negligible). During normal typing the only work is isActivationKeydown → isEnterWhileComposition, which calls Browser.getBrowser() / isMobileChrome() — uncached navigator.userAgent regexes — on every keydown. Cost is microseconds and dwarfed by the composer's own re-parse, but since this now runs on a global keydown path, memoizing the browser detection would be a cheap hardening. Not required.
Speculative lifecycle edge (unconfirmed). backward/lateral now clear transient captures at the end of handleStateChange. If a single gesture ever emitted a lateral/backward state event immediately followed by a forward one with zero intervening focus/mouse/keydown DOM event, the forward capture could find nothing to record. I could not construct a real App flow that does this, and any lingering element would fail the document.contains/staleness gates anyway — so this is a defensible cleanup, not a demonstrated regression.
Minor test gaps. The teardown test only asserts the new keydown listener is removed, not the keyup one; and there's no explicit case that a plain printable key leaves a fresh latch intact (the "standalone modifier doesn't clear" test exercises the same fall-through). Coverage is otherwise very thorough (~40 new cases covering latch/refresh/focus-mover/IME/click-preservation/noop-exclusion). No existing assertions were deleted or weakened.

Confidence: high — all conclusions are from static analysis of the diff and surrounding code, which is sufficient here. The one thing static analysis can't fully close is note #2's runtime edge; a quick manual pass of Tab→Enter→Back on the pages in the test steps (plus one RHP form-submit-save flow) would confirm it in practice.

melvin-bot · 2026-07-29T14:44:35Z

We did not find an internal engineer to review this PR, trying to assign a random engineer to #96970 as well as to this PR... Please reach out for help on Slack if no one gets assigned!

…d-Navigation-Many-Pages-The-focus-is-lost-and-does-not-return-to-triggering-element

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a8a5d51486

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

…d-Navigation-Many-Pages-The-focus-is-lost-and-does-not-return-to-triggering-element

TaduJR · 2026-08-07T14:27:27Z

@codex review

chatgpt-codex-connector · 2026-08-07T14:35:41Z

Codex Review: Didn't find any major issues. Breezy!

Reviewed commit: 1a9319d8bf

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

MelvinBot · 2026-08-07T14:52:31Z

Code review — commit `1a9319d8bf`

Verdict: ✅ The new commit is a clean, behavior-preserving optimization. Nothing blocking. Combined with the earlier reviews of this diff, I still can't construct a confirmed correctness bug.

What changed since my last pass (`038fbd9c`)

isActivationKeydown now short-circuits on the Enter/Space check before touching the UA regex. This is exactly the per-keystroke isEnterWhileComposition → Browser.getBrowser() cost I flagged in the earlier regression sweep — now the uncached navigator.userAgent regex only runs on Enter/Space keydowns, not on every keystroke in the composer. I verified it's behavior-preserving: for any non-Enter/Space key the old code also fell through to return false (the final return isEnter || isSpace was false, and the isEnterWhileComposition branch only ever returned false for those keys too). The ordering flip (repeat/isComposing and isEnterWhileComposition now evaluated only for real activation keys) doesn't change any outcome.
keyReleaseHandler's isSpace now also requires e.key === ' ', mirroring the keydown definition. Good consistency fix — a remapped Space code that produces a printable char can no longer be treated as a matching Space release. The real physical Space release (code:'Space' + key:' ') still matches, so pendingActivationKey clearing/refresh is unaffected. Covered by the existing remap test.
focusReturnTimings.ts — comment-only clarification of the TTL. No behavior change.

Unit coverage for the changed helpers remains thorough (remapped-Space keydown, mismatched/IME/modifier keyups, non-activation-key keyup no-refresh).

Runtime verification — couldn't complete (harness limitation, not a defect)

I attempted a live Tab→Enter→Back pass on Settings → Profile; it was inconclusive

The prior reviews were static-analysis only and both suggested a manual keyboard pass to close the last runtime edge. I tried it on web, but the automated browser harness has no raw keyboard primitive (no Tab/Enter/Escape key events — only pointer press/click) and no document.activeElement accessor. Pointer-driven focus can't validate a keyboard-only fix because browsers gate the focus ring behind :focus-visible, which suppresses the ring for pointer focus even when the restore logic is working. So the screenshots below neither confirm nor refute the fix — they only show the open→Back navigation renders correctly.

Legal name row → panel opens → Back returns to Profile ✅ (navigation), focus-ring check inconclusive (pointer)
Phone number row → same ✅ / inconclusive
(Minor, unrelated: the panel's Back button occasionally needed a second press to register, and off-screen rows didn't auto-scroll into view — flaky test-harness behavior, not a PR concern.)

The keyboard-focus-return behavior therefore rests on the static analysis above plus the ~40 unit cases in NavigationFocusReturnTest.ts (which do dispatch real keydown/keyup events and assert restore). A human reviewer running the PR's own test steps (Tab → Enter → Back on Legal name / Phone / Address, watching the focus ring) is still the definitive confirmation.

MelvinBot · 2026-08-07T15:07:32Z

🤖 Regression sweep — no confirmed regressions found (commit `1a9319d8bf`)

I ran an adversarial sweep across the three regression-prone areas of this diff — the new global keyboard listeners, the capture-clearing lifecycle change, and test/teardown coverage — plus a runtime sanity check. Everything checks out. One theoretical edge and one cosmetic note below, neither blocking.

What I verified is safe

New global keydown/keyup listeners can't break existing keyboard behavior. keyActivationHandler and keyReleaseHandler never call preventDefault/stopPropagation/stopImmediatePropagation and never mutate the event — pure readers. They run in capture phase but, since they don't stop propagation, the bubble-phase KeyboardShortcut listener, composer Enter-to-send, Space-to-scroll, and form submit-on-Enter all still fire unaffected.
The perf reorder is behavior-preserving. isActivationKeydown now checks Enter/Space before the UA regex. It's a pure conjunction of side-effect-free predicates, so reordering can't change the result for any input (plain Enter/Space, remapped Space, standard + Safari IME-Enter, auto-repeat, arbitrary printable) — only the UA regex is skipped for non-activation keys.
The capture-clearing lifecycle change doesn't drop a needed trigger. Within one handleStateChange, the forward-branch captureTriggerForRoute (L362) provably runs before the trailing clearTransientCaptures() (L377-379) in the same synchronous call — so the mouse-click-forward → keyboard-back cross-modality restore (WCAG 2.4.3) is unchanged. Restore reads only triggerMap, so clearing the module-level scratch fields on backward/lateral can't wipe anything a pending restore needs. The RHP form-submit "save" flow that must preserve lastInteractiveElement runs through the PUSH_PARAMS path (notifyPushParamsBackward, L122-134), which handleStateChange sees as a noop and explicitly excludes from the clear.
No listener leak, idempotent setup, native-safe. teardown removes both new listeners with the matching true capture flag and nulls both refs; setup guards each add behind if (!keyActivationHandler) / if (!keyReleaseHandler); all new performance.now()/document.* calls sit behind the typeof document === 'undefined' guards, so native/SSR never runs them.
Coverage is purely additive. tests/unit/NavigationFocusReturnTest.ts is +892/−0 (no existing assertion edited or weakened), with ~120 document.activeElement assertions dispatching real keydown/keyup events.
Runtime sanity check passed (dev web): typing lands normally in two different text fields (keystrokes not swallowed by the new capture listeners) and screen navigation works cleanly.

Notes (non-blocking)

One theoretical edge + one cosmetic item

Unconfirmed lifecycle edge (same as my earlier note). The new backward/lateral clear would drop lastInteractiveElement if some flow performed a real stack pop (handleStateChange('backward')) and then, in the same JS tick with zero intervening DOM event, dispatched a programmatic forward that relied on that field. I could not construct such a flow — the save→back→forward pattern uses the PUSH_PARAMS/noop path, and all shouldSkipFocusRestore stack pops are terminal go-backs. So it stays theoretical. If you know of a synchronous pop-then-navigate helper that isn't a param revert, that one case is worth a glance.
Cosmetic: the test-only helper setLastMouseTriggerForTests calls performance.now() without a document guard. It's test-only and performance.now() exists in Hermes/Node, so it's not a native/SSR crash vector — just noting the asymmetry.

Couldn't verify via automation: JS console errors during interaction — the web test harness has no console-log capture verb (and no raw Tab/Enter keyboard primitive to drive the actual focus-return path). No error UI was observed, but a human running the PR's test steps while watching the console remains the definitive check.

Runtime evidence

Screenshots (typing + navigation sanity check)

Confidence: high — the correctness conclusions are from static analysis of the diff and surrounding code (definitive here), corroborated by the additive unit suite and a passing typing/navigation runtime check.

arosiclair · 2026-08-07T16:00:41Z

    const launcher = pickLauncher();
    let inner: HTMLElement | null;
-    if (getHadTabNavigation()) {
+    // Re-check focusability. Form-submit spinners can add aria-disabled between keydown and here. We skip ancestors so the outgoing RHP pane (transiently aria-hidden) doesn't false-reject rows inside it.


This still isn't very clear. Can we rewrite this in a way that someone who doesn't have much context can understand? Minimally, can we explain

The precondition that leads to the problem

The problem

What the code below does to fix it

For example a comment a written something like this (doesn't have to be exactly the same)

When the user {precondition}, then {problem} occurs which breaks our logic because {reason}. Here we do {solution} to fix that

I'm asking for this because I think this code is pretty confusing for most people. A good comment can help others contribute and avoid breaking your code. Also the use of a delay to fix a problem is usually a code smell, so it's important to explain why we're taking this approach.

Sure thing rewritten it.

Great job 👍

…d-Navigation-Many-Pages-The-focus-is-lost-and-does-not-return-to-triggering-element

github-actions · 2026-08-10T13:30:40Z

🚧 arosiclair has triggered a test Expensify/App build. You can view the workflow run here.

github-actions · 2026-08-10T13:37:55Z

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #97306.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-ea275394e13-7e8bfd0-a5a8bda8bb2b72f67f33fe548ed16d975f9cf223/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-ea27539-7e8bfd0-3077419cfa767886df1d63bcc1ff29089b823598/index.html

Web 🕸️
https://97306.pr-testing.expensify.com

👀 View the workflow run that generated this build 👀

OSBotify · 2026-08-10T14:25:24Z

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

OSBotify · 2026-08-10T22:07:30Z

🚀 Deployed to staging by https://github.com/arosiclair in version: 9.4.52-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	cancelled 🔪

MelvinBot · 2026-08-10T22:10:17Z

🤖 I reviewed the changes in this PR and no help site changes are required.

Why: This PR is an internal accessibility/keyboard-navigation bug fix. It changes how focus is tracked and restored (latching the activation target at Enter/Space keydown so that pressing Back returns focus to the row the user activated). The changes are confined to internal focus-tracking utilities and their tests:

src/libs/NavigationFocusReturn/index.ts
src/libs/focusReturnTimings.ts
tests/unit/NavigationFocusReturnTest.ts
cspell.json

There is no change to any user-facing feature, workflow, settings label, tab, or button — it simply restores the expected keyboard-focus behavior that was already the intended experience. A search of docs/articles confirms the help site does not document keyboard-navigation or focus-return behavior, so there is nothing to add or update.

No draft help site PR was created because there is no documentation impact.

OSBotify · 2026-08-12T18:17:25Z

🚀 Deployed to production by https://github.com/roryabraham in version: 9.4.52-11 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

Bundle Size Analysis (Sentry):

Android

fix: keyboard focus lost after Back on Enter-activated rows

a592bf8

TaduJR requested review from a team as code owners July 29, 2026 04:43

melvin-bot Bot assigned TaduJR Jul 29, 2026

melvin-bot Bot requested review from mkhutornyi and trjExpensify and removed request for a team July 29, 2026 04:43

melvin-bot Bot removed the request for review from a team July 29, 2026 04:43

TaduJR marked this pull request as draft July 29, 2026 04:43

github-actions Bot reviewed Jul 29, 2026

View reviewed changes

Comment thread src/libs/NavigationFocusReturn/isActivatableTarget.ts Outdated

TaduJR added 2 commits July 29, 2026 13:11

Merge branch 'main' of https://github.com/TaduJR/App into fix-Keyboar…

0b8bdec

…d-Navigation-Many-Pages-The-focus-is-lost-and-does-not-return-to-triggering-element

fix: prevent stale keyboard latch across IME, key remaps, disabled ta…

a5c2ad2

…rgets, and background nav

chatgpt-codex-connector Bot reviewed Jul 29, 2026

View reviewed changes

Comment thread src/libs/NavigationFocusReturn/index.ts Outdated

fix: clear keyboard latch on target-mismatch keyup

038fbd9

TaduJR marked this pull request as ready for review July 29, 2026 12:37

mkhutornyi mentioned this pull request Jul 29, 2026

Fix workspace keyboard focus not returning to 3-dot trigger after Back #97171

Merged

54 tasks done

mkhutornyi approved these changes Jul 29, 2026

View reviewed changes

Merge branch 'main' of https://github.com/TaduJR/App into fix-Keyboar…

a8a5d51

…d-Navigation-Many-Pages-The-focus-is-lost-and-does-not-return-to-triggering-element

TaduJR marked this pull request as ready for review August 7, 2026 06:19

TaduJR requested a review from arosiclair August 7, 2026 06:20

chatgpt-codex-connector Bot reviewed Aug 7, 2026

View reviewed changes

Comment thread src/libs/NavigationFocusReturn/index.ts Outdated

github-actions Bot reviewed Aug 7, 2026

View reviewed changes

Comment thread src/libs/focusReturnTimings.ts Outdated

github-actions Bot reviewed Aug 7, 2026

View reviewed changes

Comment thread tests/unit/NavigationFocusReturnTest.ts Outdated

TaduJR added 3 commits August 7, 2026 16:23

Merge branch 'main' of https://github.com/TaduJR/App into fix-Keyboar…

0ac1a3d

…d-Navigation-Many-Pages-The-focus-is-lost-and-does-not-return-to-triggering-element

fix: latch role=checkbox/radio Pressables used as navigation triggers

5fd7a8e

perf: skip UA regex on non-activation keydowns

1a9319d

arosiclair requested changes Aug 7, 2026

View reviewed changes

TaduJR added 4 commits August 9, 2026 21:37

Merge branch 'main' of https://github.com/TaduJR/App into fix-Keyboar…

3e361c3

…d-Navigation-Many-Pages-The-focus-is-lost-and-does-not-return-to-triggering-element

docs: rewrite captureTriggerForRoute comment

2fabb40

docs: rephrase autofocuses to satisfy cspell

bc41d9f

Merge branch 'main' of https://github.com/TaduJR/App into fix-Keyboar…

c8fa028

…d-Navigation-Many-Pages-The-focus-is-lost-and-does-not-return-to-triggering-element

arosiclair approved these changes Aug 10, 2026

View reviewed changes

arosiclair merged commit ea27539 into Expensify:main Aug 10, 2026
36 of 37 checks passed

github-actions Bot mentioned this pull request Aug 10, 2026

Investigate workflow job failing on main: test / Storybook tests #98138

Closed

OSBotify mentioned this pull request Aug 10, 2026

Deploy Checklist: New Expensify 2026-08-10 #98179

Closed

melvin-bot Bot mentioned this pull request Aug 12, 2026

[Due for payment 2026-08-19] [$250] Keyboard Navigation: Settings → Profile: focus is lost and does not return to triggering element after Back #96970

Closed

TaduJR deleted the fix-Keyboard-Navigation-Many-Pages-The-focus-is-lost-and-does-not-return-to-triggering-element branch September 23, 2026 06:16

Conversation

TaduJR commented Jul 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Explanation of Change

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

Uh oh!

melvin-bot Bot commented Jul 29, 2026

Uh oh!

Uh oh!

codecov Bot commented Jul 29, 2026 • edited by github-actions Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

TaduJR commented Jul 29, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

TaduJR commented Jul 29, 2026

Uh oh!

chatgpt-codex-connector Bot commented Jul 29, 2026

Uh oh!

rushatgabhane commented Jul 29, 2026

Uh oh!

mkhutornyi commented Jul 29, 2026

Uh oh!

MelvinBot commented Jul 29, 2026

Uh oh!

chatgpt-codex-connector Bot commented Jul 29, 2026

Uh oh!

MelvinBot commented Jul 29, 2026

Code review

Uh oh!

mkhutornyi commented Jul 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Reviewer Checklist

Screenshots/Videos

Uh oh!

MelvinBot commented Jul 29, 2026

What I verified is safe

Low-severity notes (not regressions — worth a glance)

Uh oh!

melvin-bot Bot commented Jul 29, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

TaduJR commented Aug 7, 2026

Uh oh!

chatgpt-codex-connector Bot commented Aug 7, 2026

Uh oh!

MelvinBot commented Aug 7, 2026

Code review — commit 1a9319d8bf

What changed since my last pass (038fbd9c)

Runtime verification — couldn't complete (harness limitation, not a defect)

Uh oh!

MelvinBot commented Aug 7, 2026

🤖 Regression sweep — no confirmed regressions found (commit 1a9319d8bf)

What I verified is safe

Notes (non-blocking)

Runtime evidence

Uh oh!

arosiclair Aug 7, 2026

Choose a reason for hiding this comment

Uh oh!

TaduJR Aug 9, 2026

Choose a reason for hiding this comment

Uh oh!

arosiclair Aug 10, 2026

TaduJR commented Jul 29, 2026 •

edited

Loading

codecov Bot commented Jul 29, 2026 •

edited by github-actions Bot

Loading

mkhutornyi commented Jul 29, 2026 •

edited

Loading

Code review — commit `1a9319d8bf`

What changed since my last pass (`038fbd9c`)

🤖 Regression sweep — no confirmed regressions found (commit `1a9319d8bf`)