[$250] Keyboard Navigation: Expense & Chat flows: focus is lost and does not return to triggering element after Back

[rushatgabhane]

Action Performed:

Prerequisite:

• The user is logged in

1. Using Windows + Chrome, open https://new.expensify.com
2. Navigate using TAB and press enter to open one of the flows below:
   • Track Distance (expense creation → Distance)
   • A flow opened from within a Chat (e.g. the '+' / create menu in a report)
3. Navigate to the 'Back' button using TAB, press enter to activate
4. Observe the focus behavior

Affected locations (Expense / Chat flows):

• Track Distance (occurrence #41 in parent issue)
• Chat flow (occurrence #48 in parent issue)

Expected Result:

When the user activates the 'Back' button, focus should return to the element that triggered the navigation, ensuring a predictable and logical focus order. Since these flows are opened from expanded content, focus should return to the control that opened that content.

Actual Result:

When the user activates the 'Back' button, focus is lost and does not return to the triggering element. Users must hit TAB again to regain focus, which is set to the first element of the page, forcing them to re-navigate through the content.

Failed WCAG checkpoints

WCAG 2.4.3 Focus Order
https://www.w3.org/WAI/WCAG22/Understanding/focus-order

User impact:

People with mobility impairments who rely on keyboard access benefit from a logical, usable focus order. People with vision impairments can become disoriented when tabbing takes focus somewhere unexpected or when they cannot easily find the content surrounding an interactive element.

Suggested resolution:

Programmatically set focus back to the triggering element after the user returns to the previous view using the Back button. For flows opened from expanded content, restore focus to the control that opened that content.

Environment(s)

Windows 10 - Chrome

Notes

Split out from parent issue #76921 (still reproducible occurrences, grouped by location).

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022080658418200834635
• Upwork Job ID: 2080658418200834635
• Last Price Increase: 2026-07-24

Issue Owner

Current Issue Owner: @Krishna2323

[MelvinBot]

Proposal

Analysis by MelvinBot 🤖 — confidence: high on the root cause, medium on whether the "Expense" flow is distinct from "Track Distance" (see note).

What is the root cause of that problem?

The FAB "+" create menu (where Track Distance lives) and the chat composer "+" menu both call .blur() on their trigger button before opening the popover. By the time the popover's focus trap activates, document.activeElement is already document.body, so the custom focus-return system never captures the triggering element — and Back has nothing to restore focus to.

Context: FocusTrapForScreen deliberately sets setReturnFocus: false, so the focus-trap-react library's built-in return-focus is disabled. A custom system (added in #87852) is solely responsible for restoring focus on Back. It captures the launcher inside FocusTrapForModal.onActivate — but only if (launcher !== document.body). Pre-blurring the trigger defeats exactly that guard.

Evidence (file:line)

The capture guard that gets skipped: FocusTrapForModal/index.web.tsx:22-23 captures document.activeElement and only pushes it onto the launcher stack when it is a real element (!== document.body) → LauncherStack.ts:59-78.

The two pre-blur call sites:

• Chat "+" menu: AttachmentPickerWithMenuItems.tsx:463-472 — actionButtonRef.current?.blur() runs before setMenuVisibility(...).
• FAB "+" menu (Track Distance): FloatingActionButton.tsx:83-86 — fabPressable.current?.blur() runs before onPress(event) opens the popover.

Why the fallback channel also fails: the system also tracks the last mouse/keyboard trigger, but when a menu item is chosen the menu unmounts (hideCreateMenu()) before/at navigation, so the clicked element is no longer in the DOM and the DOM-presence check drops it — leaving nothing to restore.

Corroboration: the unit test spells out this exact contract — "The clicked menu item unmounts on close — without the launcher on the stack, nav-back has nothing to restore" and "skips launcher capture when activeElement is document.body" (tests/unit/FocusTrapForModalTest.tsx:70-89, 114-117).

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

Make the trigger element survive as the launcher when the trap activates. Two options, smallest first:

• Option A (localized): Remove the premature .blur() at the two trigger sites (AttachmentPickerWithMenuItems.tsx:471 and FloatingActionButton.tsx:84). The trap's own onActivate already blurs the active element on activation, so the "blue focus ring" the code comments guard against should still be removed — just slightly later. Needs a quick visual check for a ring flash.

• Option B (robust): Pass the anchor explicitly. Add an optional launcherRef to FocusTrapForModal and, in onActivate, fall back to launcherRef.current when document.activeElement === document.body. Wire the FAB popover (fabRef) and the chat PopoverMenu (actionButtonRef) to pass it. This survives any pre-blur and is the more defensive fix.

Recommend starting with Option A; fall back to B if the focus-ring regression is unacceptable.

What alternative solutions did you explore? (Optional)

Flipping setReturnFocus back on in FocusTrapForScreen is not the fix — it was set to false on purpose (#49240, to kill the blue frame on the "+" button when opening a URL in a new tab), and the custom launcher-stack system replaced it. The correct layer to fix is trigger capture, not the trap's return-focus flag.

Related issues

Sibling split-outs from parent #76921 that share the same "focus lost after Back" root system:

• [$250] Keyboard Navigation: Settings → Profile: focus is lost and does not return to triggering element after Back #96970 — Settings → Profile
• [$250] Keyboard Navigation: Workspaces: focus is lost and does not return to triggering element after Back #96971 — Workspaces

⚠️ Note (medium confidence): the issue lists "Track Distance" and the "Chat flow" separately, but at the FAB layer Track Distance and the regular Expense option run identical code (both FABFocusableMenuItem → same onItemPress), so both should fail to register a launcher for the same reason. If Expense appears to restore focus today, that's the destination screen's own focus behavior, not launcher restore.

---

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

[dilshodmackbook-sketch]

Proposal

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

When a keyboard user opens the Track Distance flow or a report + create flow, then activates Back, focus is not returned to the control that opened the flow. It lands on document.body, so the next TAB restarts from the top of the page (WCAG 2.4.3 Focus Order).

What is the root cause of that problem?

The parent fix (#76921 / PR #91752) already restores focus on Back. The mechanism, on web, is: when a popover/modal focus trap activates it records the element that opened it as the launcher, and on backward navigation that launcher is used to restore focus if the element inside the trap has since unmounted.

The launcher is read straight from document.activeElement at trap-activation time:

src/components/FocusTrap/FocusTrapForModal/index.web.tsx (L19-L27):

onActivate: () => {
    const launcher = document.activeElement;
    blurActiveElement();
    if (launcher instanceof HTMLElement && launcher !== document.body) {
        cachedLauncherRef.current = launcher;
        setActivePopoverLauncher(launcher);
    }
},

Both failing flows open their menu from a control that blurs itself before opening the popover, so document.activeElement is already document.body by the time the trap activates:

• FAB — toggleFabAction calls fabPressable.current?.blur() before onPress opens the menu: FloatingActionButton.tsx L82-L86
• Report + — the create button calls actionButtonRef.current?.blur() before showing the menu: AttachmentPickerWithMenuItems.tsx L462-L472

Because launcher === document.body, the launcher !== document.body guard rejects it and no launcher is registered. On the forward navigation, the capture step therefore has no launcher to fall back to — it records only the highlighted popover menu item as primary with no fallback:

src/libs/NavigationFocusReturn/index.ts (L52-L72) — launcher = pickLauncher() returns null, so the if (launcher) fallback branch is skipped.

The menu item unmounts when the popover closes during navigation, so on Back there is no live element left to restore, and focus stays on the body. The same-screen path in the other ~46 occurrences works because those triggers are ordinary rows that stay focused and mounted; these two are popover-launched and blur their trigger, which is exactly the combination the launcher capture doesn't survive.

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

Stop inferring the launcher from document.activeElement, which is unreliable by design here — callers blur the trigger to suppress the focus ring, and a mouse user never focuses it at all. The popover already knows its trigger: PopoverMenu receives an anchorRef, and for both flows that ref points at the focusable trigger itself (fabRef for the FAB, actionButtonRef for the + button). Use it as the launcher when the active element isn't usable.

Pass the existing anchorRef down to the trap in PopoverMenu:

<FocusTrapForModal
    active={isVisible}
    shouldReturnFocus={!shouldEnableNewFocusManagement}
    anchorRef={anchorRef}
>

And prefer a real active element, else fall back to the anchor, in FocusTrapForModal.onActivate:

onActivate: () => {
    const active = document.activeElement;
    // anchorRef.current is the host DOM node on web (the control that opened this popover)
    const launcher = active instanceof HTMLElement && active !== document.body ? active : (anchorRef?.current ?? null);
    blurActiveElement();
    if (launcher instanceof HTMLElement && launcher !== document.body) {
        cachedLauncherRef.current = launcher;
        setActivePopoverLauncher(launcher);
    }
},

This keeps the intentional pre-open blur (no focus-ring regression), needs no new prop wiring at the two call sites since anchorRef already exists on every popover, and fixes the whole class of popover-launched flows at once rather than just these two. If a particular anchor is a non-focusable wrapper, pickRestoreCandidates already filters on hasFocusableAttributes, so it degrades gracefully to today's behavior.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. NavigationFocusReturn unit test: with document.activeElement === document.body but a valid launcher registered from an anchor, a forward-then-backward navigation restores focus to that launcher (guards the fallback path).
2. FocusTrapForModal component test: blur the active element, then activate the trap with an anchorRef provided, and assert setActivePopoverLauncher is called with the anchor element (not skipped).
3. Regression: when document.activeElement is a valid focusable trigger at activation, that element — not the anchor — is registered, so existing non-blurring flows are unchanged.

What alternative solutions did you explore? (Optional)

• Remove the .blur() calls from the FAB and the composer + so the trigger stays focused at activation. This is the smallest change, but the blur is intentional (it suppresses the blue focus ring) and FocusTrapForModal.onActivate already re-blurs via blurActiveElement() right after capture — so dropping the call-site blur can leave a one-frame ring on the trigger, and it only patches these two menus. Any future popover that blurs before opening, or is opened by mouse, would fall back into the same gap. Sourcing the launcher from anchorRef addresses the class without touching the blur behavior.
• Capture the trigger per flow and restore it in each screen's Back handler — precise, but it has to be repeated at every call site (the parent issue lists dozens) and drifts over time; the central anchor-based capture covers them in one place.

[melvin-bot]

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

[melvin-bot]

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

[godzillaxbox19982014-lgtm]

Proposal

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

Keyboard Navigation: Expense & Chat flows: focus is lost and does not return to triggering element after Back

What is the root cause of that problem?

I traced this to the path that handles expense report, TAB, #41:

• src/libs/Navigation/AppNavigator/KeyboardShortcutsHandler/ExpenseReportSearchHandler.tsx:24 (if): if (Navigation.isOnboardingFlow() || shouldShowRequire2FAPage) {
• src/libs/Navigation/AppNavigator/KeyboardShortcutsHandler/NewChatHandler.tsx:22 (if): if (Navigation.isOnboardingFlow() || shouldShowRequire2FAPage) {
• src/libs/NavigationFocusReturn/index.ts:153 (if): if (!hasFocusableAttributes(document.activeElement)) {
• src/pages/iou/request/step/IOURequestStepHours.tsx:148 (setNavigationActionToMicrotaskQueue): return Navigation.setNavigationActionToMicrotaskQueue(() => navigateToConfirmationPage(iouType, transactionID, policyExpenseChat.reportID, backToReport));
• src/libs/Navigation/AppNavigator/KeyboardShortcutsHandler/ExpenseReportSearchHandler.tsx:24 is the first concrete decision that matches expense report, TAB, #41, and src/libs/Navigation/AppNavigator/KeyboardShortcutsHandler/NewChatHandler.tsx:22 is the next matching consumer/mutation. The failing behavior is introduced at this handoff: the second path does not preserve the condition/state established by the first path for the repro case.

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

• Change the issue-matching decision at src/libs/Navigation/AppNavigator/KeyboardShortcutsHandler/ExpenseReportSearchHandler.tsx:24 so the expense report, TAB, #41 repro state is represented before src/libs/Navigation/AppNavigator/KeyboardShortcutsHandler/NewChatHandler.tsx:22 consumes it.
• Keep the patch at this first decision/consumer boundary (fix the route builder/consumer pair instead of adding a screen-only redirect) instead of masking the downstream UI symptom.
• Keep the change inside the Navigation, RHP, Not Here, Back Stack surface and avoid changing deep links, auth/onboarding redirects.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Add or update a regression in tests/navigation/**/*.ts for the exact issue flow: Keyboard Navigation: Expense & Chat flows: focus is lost and does not return to triggering element after Back.
2. Cover the counter-case near src/libs/Navigation/AppNavigator/KeyboardShortcutsHandler/ExpenseReportSearchHandler.tsx:24 so valid existing expense report, TAB, #41 behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep expense report, TAB, #41 consistent at the first read/write boundary shown above.