Fix keyboard focus not returning to FAB and composer + after Back by Krishna2323 · Pull Request #97678 · Expensify/App

Krishna2323 · 2026-08-03T11:02:20Z

Explanation of Change

Fixed Issues

$ #96972
PROPOSAL:

Tests

Flow 1 — FAB Create Menu (Track Distance)

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

Flow 2 — Chat Composer Create Menu

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

Regression Checks

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.
Open the FAB menu with the mouse, click Track distance, then go back using the Back button.
- Verify focus returns to the FAB.
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.
Resize the window to mobile width and repeat Flow 1 and Flow 2.
- Verify focus still returns to the correct trigger.
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

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

web_chrome_mac.mp4

web_chrome.mp4

Signed-off-by: krishna2323 <belivethatkg@gmail.com>

Krishna2323 · 2026-08-03T11:04:26Z

@MelvinBot review

MelvinBot · 2026-08-03T11:13:36Z

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.

Signed-off-by: krishna2323 <belivethatkg@gmail.com>

Krishna2323 · 2026-08-03T11:33:34Z

@MelvinBot review

MelvinBot · 2026-08-03T11:37:06Z

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 · 2026-08-03T11:37:48Z

@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 · 2026-08-03T11:51:10Z

+                                // launcher later.
+                                const launcher = resolvePopoverLauncherElement(actionButtonRef);
+                                if (launcher) {
+                                    markActivePopoverLauncherDeactivated(launcher);


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.

mkhutornyi · 2026-08-05T14:39:09Z

Flow 2 — Chat Composer Create Menu

Verify focus returns to the composer + button.

This happens but briefly. Then automatically focuses on composer.

I think it's expected.
For screen reader, it's quite easy to navigate to + button using Shift + TAB.

mkhutornyi · 2026-08-05T14:41:44Z

Is this out of scope?

Esc on popover menu doesn't return to FAB

Screen.Recording.2026-08-05.at.3.41.01.PM.mov

mkhutornyi · 2026-08-05T14:47:55Z

This is web-only fix.
Still not working on native but out of scope as it requires native-specific solution which is completely different from web.

mkhutornyi · 2026-08-05T14:48:27Z

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

Android: mWeb Chrome

iOS: HybridApp

iOS: mWeb Safari

MacOS: Chrome / Safari

Screen.Recording.2026-08-05.at.3.49.53.PM.mov

mkhutornyi · 2026-08-05T14:54:05Z

Similar to Esc on popover menu, "Create report" case not working.
We might need holistic solution for popover dismiss case.

Screen.Recording.2026-08-05.at.3.50.43.PM.mov

Krishna2323 · 2026-08-05T22:07:10Z

Is this out of scope?

Esc on popover menu doesn't return to FAB

Similar to Esc on popover menu, "Create report" case not working. We might need holistic solution for popover dismiss case.

@rushatgabhane, should we cover these in this PR or handle them in a follow-up? The original issue was specifically about fixing the Track Distance and Chat flows.

rushatgabhane · 2026-08-07T03:52:24Z

https://expensify.slack.com/archives/C01GTK53T8Q/p1786074733511159?thread_ts=1785186829.007719&cid=C01GTK53T8Q

… trap Signed-off-by: krishna2323 <belivethatkg@gmail.com>

codecov · 2026-08-10T00:43:20Z

Codecov Report

❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.

Files with missing lines	Coverage Δ
...mponents/FocusTrap/FocusTrapForModal/index.web.tsx	`100.00% <100.00%> (ø)`
src/components/Modal/BaseModal.tsx	`96.92% <ø> (ø)`
src/components/Popover/index.tsx	`0.00% <ø> (ø)`
src/components/PopoverMenu/index.tsx	`91.48% <ø> (ø)`
.../components/PopoverMenu/v2/content/BaseContent.tsx	`100.00% <100.00%> (ø)`
...rc/components/PopoverWithMeasuredContent/index.tsx	`100.00% <ø> (ø)`
src/libs/LauncherStack.ts	`85.96% <100.00%> (+0.51%)`	⬆️
...inbox/sidebar/FABPopoverContent/FABPopoverMenu.tsx	`75.67% <ø> (ø)`
src/components/Modal/ReanimatedModal/index.tsx	`76.54% <33.33%> (-1.67%)`	⬇️
... and 55 files with indirect coverage changes

Krishna2323 · 2026-08-10T00:48:24Z

@MelvinBot review

MelvinBot · 2026-08-10T00:57:38Z

Review

Two CI checks are red — both come entirely from the new test file and block merge. Fix those first; the implementation itself looks correct (details below).

🔴 Blocking — failing checks (`tests/unit/FocusTrapForModalTest.tsx`)

1. ESLint check — the file now has 11 @typescript-eslint/no-unsafe-type-assertion errors but eslint-seatbelt only allows 3 (this PR added 8), plus two no-unsafe-return.

Swap the (x as jest.Mock) casts for jest.mocked(x) — e.g. jest.mocked(hasLauncher), jest.mocked(pickLauncher), jest.mocked(setActivePopoverLauncher), jest.mocked(markActivePopoverLauncherDeactivated). That's the lint-safe typed-mock pattern and removes the assertions.
The two no-unsafe-return are the lastTrapFocusReturn mock arrows at L32-L33 returning the jest.fn() result (any). Give them a : void return type (or a block body): setLastTrapFocusReturn: (element: HTMLElement): void => { mockSetLastTrapFocusReturn(element); }.

2. spellcheck — two unknown words: autofocused (L217) and anchorless (L300). Reword the comments or add both to the cspell dictionary.

✅ Implementation — looks correct

Moving the return from FAB-specific launcher registration to centralizing it in FocusTrapForModal is the right call, and it directly answers mkhutornyi's "holistic solution for popover dismiss" ask (the Esc and "Create report" cases). I traced the new logic:

What I verified

Launcher resolution order in onActivate — focused element → launcherRef (anchor) → pickLauncher() (LauncherStack) — is coherent. The anchor fallback only kicks in when activeElement === body (the FAB / composer "+" blur themselves before opening), so ordinary modals that hold focus are unaffected.
wasClaimedByNavigation = !hasLauncher(launcher) (L60) correctly hands the restore off to NavigationFocusReturn on a forward nav — the launcher is consumed by captureTriggerForRoute → consumeLauncher, so returning here too would trample the destination screen's autofocus.
isCoveredByNewerTrap (L64) via sharedTrapStack.length > trapDepthAtActivateRef.current correctly distinguishes an ancestor trap from one opened on top, given focus-trap pushes after onActivate and removes before onPostDeactivate. This is the "Create report → confirm modal" case.
The lastTrapFocusReturn shield in blurActiveElement correctly handles the Escape ordering (trap returns focus before the modal's hide-time blur runs), and is narrowly scoped: it only suppresses a blur when activeElement is the just-returned element, and it's cleared at the next trap's onActivate.
Native is a no-op (index.tsx returns children; launcherRef ignored) — consistent with this being web-only, which matches mkhutornyi's out-of-scope note for native.
New unit tests cover every added branch (anchor fallback, native no-op path, nav hand-off, shield set/clear, anchorless LauncherStack fallback, covered-by-newer-trap).

Minor (non-blocking)

This now touches the shared FocusTrapForModal used by every modal, and the two new skip-guards apply app-wide. They're narrowly triggered, but worth a spot-check that ordinary modals (RHP confirm dialogs, etc.) still return focus on a plain Esc/Cancel — the all-platform reviewer checklist should catch it.
The lastTrapFocusReturn shield is module-global and only cleared on the next trap activation. In the window between a return and the next trap opening, a blurActiveElement() call that legitimately targets the returned element would be silently skipped. Callers are limited (EmojiPicker, ContactMethodDetailsPage, TestToolsModalNavigator, ReanimatedModal) and it only matters when activeElement is exactly that element — practically benign, just flagging it.

Verification note

I couldn't auto-verify the end-to-end keyboard focus-return here — the web test tooling can't dispatch raw Tab/Enter/Esc/Arrow keys or read document.activeElement, which is exactly what this flow hinges on. The unit tests pass and the logic checks out, so please confirm the manual Tests / Regression Checks on Windows + Chrome — especially Regression Check #3 (Esc-close FAB menu → open an LHN chat → Back returns to the LHN chat, not the FAB).

Signed-off-by: krishna2323 <belivethatkg@gmail.com>

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 53399ebbaa

ℹ️ 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".

chatgpt-codex-connector · 2026-08-13T00:39:42Z

+                    // out to the FAB behind that modal, and leave the user nothing to return to when it closes.
+                    const isCoveredByNewerTrap = sharedTrapStack.length > trapDepthAtActivateRef.current;
                    // Mark first so a throw in restoreFocusWithModality can't leak the LauncherStack entry; the deferred clear keeps the post-hide capture window.
                    markActivePopoverLauncherDeactivated(launcher);


Preserve launcher entries while a newer trap owns them

When an anchorless confirm opens from a popover (for example FAB/composer Create report when the empty-report confirmation is shown), its activation falls back to the popover launcher and setActivePopoverLauncher dedupes the stack entry by element. The closing popover then still runs this deactivation even though isCoveredByNewerTrap is true, so the newer confirm's only launcher entry becomes deactivated and expires after LAUNCHER_CLEAR_DELAY_MS; if the user spends more than a second in the confirm before pressing Create report or the Reports link, the forward navigation can't capture the FAB/composer fallback and Back won't restore focus to the launcher.

Useful? React with 👍 / 👎.

Tested this case and works fine

Screen.Recording.2026-08-13.at.5.37.33.PM.mov

MelvinBot · 2026-08-13T00:46:56Z

🤖 Regression testing: runtime keyboard checks could not be run; one code-level regression surface worth a second look.

Heads up on verification: I couldn't execute this PR's actual regression checks at runtime. Every assertion here is keyboard-driven (Tab / Arrow / Enter / Esc → focus returns to the FAB / composer +), and the web test harness available to me can't dispatch raw key events or read back DOM focus state. So I can't confirm or refute the focus-restoration behavior the PR fixes — a human still needs to run the Tests and Regression Checks steps manually.

What did pass (mouse-driven smoke only — proves routes don't break, not focus return):

FAB → Track distance → Back → returns cleanly to Home, no crash.
Chat composer + → Create expense → Back → returns cleanly to the composer, no crash.

Code-level regression surface worth confirming (⚠️ review-only, low confidence — not runtime-verified):

The new focus "shield" is an app-wide singleton, not scoped to the trap that set it. blurActiveElement/index.ts:14 now skips the blur whenever document.activeElement === getLastTrapFocusReturn(), and that value (lastTrapFocusReturn.ts) stays armed from when a trap restores focus until the next trap activates and clears it (index.web.tsx:37 / :70).

blurActiveElement has four other callers that are not focus traps and don't clear the shield — EmojiPicker, ReanimatedModal, ContactMethodDetailsPage (mWeb keyboard dismiss), TestToolsModalNavigator. Worth double-checking that in the window after a menu closes (focus back on the FAB/composer, shield armed) none of these paths need to blur that exact element and now silently no-op. Likely narrow, but it's a shared global touched by every modal/popover, so the blast radius is the whole app.

Testing environment details

Tested on the PR branch krishna2323/issue/96972 (53399eb) via the web driver.
Blockers on --platform web: no key-dispatch primitive (Tab/Arrow/Enter/Esc can't be sent as key events), is focused/is editable return non-functional stubs, and there's no JS console-error capture path — so "no focus-ring flash" and "no console errors" also couldn't be verified.
Native (FocusTrapForModal/index.tsx) is untouched by the new web-only lastTrapFocusReturn import, so no native regression from that.

Evidence

Reply with @MelvinBot <feedback> to refine.

mkhutornyi · 2026-08-13T16:38:46Z

Please pull main

MelvinBot · 2026-08-13T16:42:51Z

Review — LGTM, all checks green

Re-reviewed at 53399eb. The two blocking CI failures from my last pass are fixed: the ESLint errors are gone (the test now uses jest.mocked(...) instead of as jest.Mock casts, and the lastTrapFocusReturn mock arrows are typed : void), and spellcheck passes (anchorless / autofocused added to cspell.json). Every required check is now passing.

The implementation is unchanged from what I traced before and still holds up — the anchor→pickLauncher() launcher-resolution chain, the wasClaimedByNavigation nav hand-off, the isCoveredByNewerTrap guard, and the Escape-ordering lastTrapFocusReturn shield all line up with the branches the new unit tests exercise. mkhutornyi has approved and confirmed this is a correct web-only fix (native focus-return stays out of scope).

Two standing non-blocking notes (unchanged — for the manual checklist)

This centralizes launcher handling in the shared FocusTrapForModal, so pickLauncher() is now consulted by every modal whose activation happens with document.activeElement === body and no anchor. Blast radius is app-wide even though the trigger is narrow — worth a spot-check that ordinary RHP confirm/cancel dialogs still return focus correctly on a plain Esc/Cancel.
The lastTrapFocusReturn shield is a module-global cleared only on the next trap's onActivate. In the window between a return and the next trap opening, a blurActiveElement() call that legitimately targets the just-returned element (callers: EmojiPicker, ReanimatedModal, ContactMethodDetailsPage, TestToolsModalNavigator) would silently no-op. Practically benign since it only matters when activeElement is that exact element.

Verification note: I still can't auto-verify the end-to-end keyboard focus-return — the web test harness here can't dispatch raw Tab/Enter/Esc/Arrow keys or read document.activeElement, which is exactly what this flow hinges on. Since mkhutornyi has run and approved the manual flows, that's covered — the one I'd re-confirm is Regression Check #3 (Esc-close FAB menu → open an LHN chat → Back returns to the LHN chat, not the FAB).

Merge status: MERGEABLE, no conflicts, but currently BLOCKED on REVIEW_REQUIRED — it still needs the independent (internal Expensify) approval, and mkhutornyi asked you to pull main before merge.

chatgpt-codex-connector · 2026-08-13T16:47:25Z

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

Reviewed commit: 53399ebbaa

ℹ️ 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".

melvin-bot · 2026-08-14T02:28:04Z

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

Signed-off-by: krishna2323 <belivethatkg@gmail.com>

…'s focus return Signed-off-by: krishna2323 <belivethatkg@gmail.com>

JS00001 · 2026-08-14T15:47:21Z

lmk when this is ready again

Krishna2323 · 2026-08-14T15:48:25Z

It's ready 🙂

mkhutornyi · 2026-08-14T15:48:53Z

Latest changes seems require quick retest

Krishna2323 · 2026-08-14T15:49:48Z

Works well on my end

JS00001 · 2026-08-14T15:51:11Z

@mkhutornyi would you mind retesting & reapproving please?

mkhutornyi

Retested

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

d26c71b

Signed-off-by: krishna2323 <belivethatkg@gmail.com>

melvin-bot Bot assigned Krishna2323 Aug 3, 2026

Gate FAB launcher registration on the menu actually opening

24e43a7

Signed-off-by: krishna2323 <belivethatkg@gmail.com>

Krishna2323 marked this pull request as ready for review August 3, 2026 11:37

Krishna2323 requested review from a team as code owners August 3, 2026 11:37

melvin-bot Bot requested review from mkhutornyi and removed request for a team August 3, 2026 11:37

melvin-bot Bot requested review from joekaufmanexpensify and removed request for a team August 3, 2026 11:37

Krishna2323 mentioned this pull request Aug 3, 2026

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

Open

chatgpt-codex-connector Bot reviewed Aug 3, 2026

View reviewed changes

joekaufmanexpensify previously approved these changes Aug 3, 2026

View reviewed changes

Return keyboard focus to the popover trigger centrally, via the focus…

832dfc9

… trap Signed-off-by: krishna2323 <belivethatkg@gmail.com>

Krishna2323 dismissed joekaufmanexpensify’s stale review via 832dfc9 August 10, 2026 00:37

Krishna2323 added 2 commits August 10, 2026 06:30

fix test file lint issue.

6a1128e

Signed-off-by: krishna2323 <belivethatkg@gmail.com>

fix cspell failed check.

53399eb

Signed-off-by: krishna2323 <belivethatkg@gmail.com>

chatgpt-codex-connector Bot reviewed Aug 13, 2026

View reviewed changes

mkhutornyi approved these changes Aug 13, 2026

View reviewed changes

mkhutornyi mentioned this pull request Aug 13, 2026

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

Open

54 tasks

Merge branch 'Expensify:main' into krishna2323/issue/96972

ef7ed6c

mkhutornyi approved these changes Aug 14, 2026

View reviewed changes

melvin-bot Bot requested a review from JS00001 August 14, 2026 02:28

JS00001 requested changes Aug 14, 2026

View reviewed changes

Comment thread src/components/FocusTrap/FocusTrapForModal/index.web.tsx Outdated

Comment thread src/libs/lastTrapFocusReturn.ts Outdated

Krishna2323 added 2 commits August 14, 2026 21:00

move method to component.

244455b

Signed-off-by: krishna2323 <belivethatkg@gmail.com>

Blur only focus inside the closing modal instead of tracking the trap…

8104136

…'s focus return Signed-off-by: krishna2323 <belivethatkg@gmail.com>

mkhutornyi approved these changes Aug 14, 2026

View reviewed changes

melvin-bot Bot requested a review from JS00001 August 14, 2026 16:01

Uh oh!

Conversation

Krishna2323 commented Aug 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Explanation of Change

Fixed Issues

Tests

Flow 1 — FAB Create Menu (Track Distance)

Flow 2 — Chat Composer Create Menu

Regression Checks

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

Uh oh!

Krishna2323 commented Aug 3, 2026

Uh oh!

MelvinBot commented Aug 3, 2026

Review — LGTM with one minor nit

Nit (low severity, non-blocking)

Testing note

Uh oh!

Krishna2323 commented Aug 3, 2026

Uh oh!

MelvinBot commented Aug 3, 2026

Re-review — nit resolved, LGTM

Uh oh!

melvin-bot Bot commented Aug 3, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot Aug 3, 2026

Choose a reason for hiding this comment

Uh oh!

joekaufmanexpensify left a comment

Choose a reason for hiding this comment

Uh oh!

mkhutornyi commented Aug 5, 2026

Uh oh!

mkhutornyi commented Aug 5, 2026

Uh oh!

mkhutornyi commented Aug 5, 2026

Uh oh!

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

Uh oh!

Reviewer Checklist

Screenshots/Videos

Uh oh!

mkhutornyi commented Aug 5, 2026

Uh oh!

Krishna2323 commented Aug 5, 2026

Uh oh!

rushatgabhane commented Aug 7, 2026

Uh oh!

codecov Bot commented Aug 10, 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!

Krishna2323 commented Aug 10, 2026

Uh oh!

MelvinBot commented Aug 10, 2026

Review

🔴 Blocking — failing checks (tests/unit/FocusTrapForModalTest.tsx)

✅ Implementation — looks correct

Minor (non-blocking)

Verification note

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot Aug 13, 2026

Choose a reason for hiding this comment

Uh oh!

mkhutornyi Aug 13, 2026

Choose a reason for hiding this comment

Uh oh!

MelvinBot commented Aug 13, 2026

Krishna2323 commented Aug 3, 2026 •

edited

Loading

mkhutornyi commented Aug 5, 2026 •

edited

Loading

codecov Bot commented Aug 10, 2026 •

edited by github-actions Bot

Loading

🔴 Blocking — failing checks (`tests/unit/FocusTrapForModalTest.tsx`)

JS00001 commented Aug 14, 2026 •

edited

Loading