Fix keyboard focus not returning to FAB and composer + after Back

[Krishna2323]

Explanation of Change

Fixed Issues

$ #96972
PROPOSAL:

Tests

Flow 1 — FAB Create Menu (Track Distance)

1. Sign in on Windows + Chrome at https://new.expensify.com/ (wide window, not narrow layout).
2. Press Tab until the + floating action button (FAB) is focused.
3. Press Enter to open the create menu.
4. Use ↓ to highlight Track distance, then press Enter.
5. Press Tab to focus the Back button, then press Enter.
6. Verify focus returns to the + FAB.
7. Verify pressing Tab once moves to the next control after the FAB (not the first element on the page).
8. Repeat steps 2–6 for:
   • Create expense
   • Start chat
   • Send invoice

---

Flow 2 — Chat Composer Create Menu

1. Open any chat.
2. Press Tab until the + button next to the composer is focused.
3. Press Enter to open the menu.
4. Use ↓ to highlight Create expense, then press Enter.
5. Press Tab to the Back button and press Enter.
6. Verify focus returns to the composer + button.
7. Repeat steps 2–6 for:
   • Track distance
   • Split expense
   • Assign task
   • Add attachment

---

Regression Checks

1. Open the FAB menu with Enter, then close it with Esc.
   • Verify no blue focus ring flashes on the FAB while opening.
   • Verify there are no JS console errors.
2. Open the FAB menu with the mouse, click Track distance, then go back using the Back button.
   • Verify focus returns to the FAB.
3. Open the FAB menu with Enter, close it with Esc, then open any chat from the LHN.
   • Go back using the Back button.
   • Verify focus returns to the same LHN chat, not the FAB.
   • Repeat the same test with the composer + menu.
4. Resize the window to mobile width and repeat Flow 1 and Flow 2.
   • Verify focus still returns to the correct trigger.
5. Open the composer + menu and close it with Esc.
   • Verify the composer regains focus as before (no regression).

• Verify that no errors appear in the JS console

Offline tests

• Same as tests

QA Steps

• Same as tests

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover 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 tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
  • MacOS: Desktop
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I verified there are no new alerts related to the canBeMissing param for useOnyx
• I followed proper code patterns (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 shown in the product is localized by adding it to src/languages/* files and using the translation method
    • If any non-english text was added/modified, I used JaimeGPT to get English > Spanish translation. I then posted it in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:
  • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
  • 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)
  • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
  • I verified the JSDocs style guidelines (in STYLE.md) were followed
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
• I verified any variables that can be defined as constants (ie. in CONST.ts or at the top of the file that uses the constant) are defined as such
• I verified that if a function's arguments changed that all usages have also been updated correctly
• 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 new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• 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.
• If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user 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.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

web_chrome_mac.mp4

web_chrome.mp4

[Krishna2323]

@MelvinBot review

[MelvinBot]

Review — LGTM with one minor nit

The approach is correct and the diff is clean. Root cause is accurately identified: the create-menu triggers blur() before the popover's focus trap activates, so FocusTrapForModal.onActivate reads document.activeElement === body and registers nothing — leaving NavigationFocusReturn with no launcher to restore on Back. Pre-registering the trigger on the LauncherStack in the press handler (before the blur) is the right fix, and deactivating it in onModalHide correctly handles the close-without-navigation case so the entry can't linger as a stale launcher.

Verified the wiring holds together:

• The FAB registers its own fabPressable and deactivates via anchorRef in FABPopoverMenu. These resolve to the same DOM node — fabRef is forwarded to the FAB's ref, whose ref callback assigns the same element to both — so the deactivation targets the correct entry. ✅
• onModalHide is properly plumbed through PopoverMenu (not dead code). ✅
• resolvePopoverLauncherElement is native-safe (typeof document, instanceof HTMLElement, document.contains), so this is a no-op off web. ✅
• No double-registration/deactivation with FocusTrapForModal: since the trigger is blurred before onActivate, that trap's cachedLauncherRef stays null and its onPostDeactivate does nothing for these menus. ✅

Nit (low severity, non-blocking)

In showCreateMenu there's an early-return path (!isFocused && shouldUseNarrowLayout) where toggleFabAction has already registered the FAB as an active launcher, but the menu never opens — so no onModalHide fires to deactivate it, and the entry lingers active.

In practice this is benign: captureTriggerForRoute prefers the in-trap inner element over the launcher and consumeLauncher removes whatever gets picked, so the stale entry gets cleaned up (and shadowed by newer entries) on the next forward nav. The only way it mis-restores is a forward nav with no focused trigger element while that stale FAB entry is top-of-stack — unlikely. If you want to close the gap tidily, gate the registration on the same condition the menu actually opens under.

Testing note

The three new unit tests are well-targeted (registration-before-open ordering, native no-op path, deactivate-on-hide). They mock LauncherStack wholesale, so they assert the components call the right functions but don't exercise the real FAB→navigate→Back→restore integration — reasonable given LauncherStack has its own coverage.

I couldn't validate the end-to-end keyboard focus-return behavior automatically — the web test tooling here can't dispatch raw Tab/Enter/Arrow keys or read document.activeElement, which is exactly what this flow hinges on. Worth confirming the manual Tests/Regression Checks steps pass on Windows + Chrome as written, particularly Regression Check #3 (Esc-close FAB menu → open LHN chat → Back returns to the LHN chat, not the FAB), since that's the scenario the onModalHide deactivation exists to protect.

[Krishna2323]

@MelvinBot review

[MelvinBot]

Re-review — nit resolved, LGTM

24e43a71 cleanly addresses the lingering-launcher nit from my last review. The registration moved out of FloatingActionButton.toggleFabAction and into showCreateMenu, placed after the !isFocused && shouldUseNarrowLayout early-return and right before setIsCreateMenuActive(true) — so the FAB is only registered as a launcher when the menu actually opens, and there's no code path that registers an entry that onModalHide would never deactivate.

Nice side benefit: registration and deactivation now both key off fabRef (showCreateMenu registers it, FABPopoverMenu.onModalHide deactivates it), so it's the same node on both ends — a bit tidier than the previous split between fabPressable and fabRef.

Test coverage followed the move correctly: the old FloatingActionButtonLauncherTest was replaced by FloatingActionButtonAndPopoverLauncherTest, which adds an explicit case for the exact edge I flagged — "does not register a launcher when showCreateMenu bails out on an unfocused narrow layout."

No new concerns. Same caveat as before: I can't auto-verify the end-to-end keyboard focus-return in CI (the web tooling can't dispatch raw Tab/Enter/Arrow keys or read document.activeElement), so please confirm the manual Tests / Regression Checks pass on Windows + Chrome — especially Regression Check #3.

[melvin-bot]

@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]

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 24e43a7105

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Keep the composer launcher alive through file picking

When the user chooses Add attachment, triggerAttachmentPicker only calls onAttachmentPicked after the OS file picker returns, and that handler navigates to REPORT_ADD_ATTACHMENT; marking the composer + launcher deactivated as soon as the menu hides means LauncherStack prunes it after the 1s clear delay. If the user takes more than a second to pick a file, the forward navigation has no launcher to capture, so Back from the attachment preview will not restore focus to the composer + despite this flow being covered by the fix. Re-register or otherwise preserve the launcher when the picker returns before navigating.

Useful? React with 👍 / 👎.

[joekaufmanexpensify]

Good for product.