FAB - Create expense item is highlighted after opening Manual expense flow

[jponikarchuk]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.74-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #87920
Email or phone of affected tester (no customers): sdsdjoijdoisnjodis@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Run Onyx.merge('betas', ['newManualExpenseFlow']); in console.

1. Go to staging.new.expensify.com
2. Open FAB > Create expense.
3. Go to Manual tab.
4. Close the RHP.
5. Open FAB > Create expense.
6. Close the RHP.
7. Open FAB.

Expected Result:

Create expense item will not be highlighted after opening Manual expense flow.

Actual Result:

Create expense item is highlighted after opening Manual expense flow.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #87920

[melvin-bot]

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

[github-actions]

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

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

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #87920 - "Feat: Manual expense flow UI refactor - r3" by @ChavdaSachin (High confidence)
Related Issues: #82586 (original issue this PR fixed)

Recommendation: REVERT

PR #87920 introduced the new Manual expense flow UI refactor (under the newManualExpenseFlow beta), and the melvin-bot also identified this as the causing PR. The bug is staging-only (new feature, not in production), so reverting is the cleanest path to unblock the deploy.

Assigned: @ChavdaSachin (PR author), @ShridharGoel and @puneetlath (approving reviewers) from PR #87920
Labels: DeployBlockerCash kept (Frontend bug in App repo). No label changes made.

📋 Detailed Analysis

Evidence

• The melvin-bot automatically identified PR Feat: Manual expense flow UI refactor - r3 #87920 as the causing PR for this deploy blocker.
• The issue is reproducible only on staging and only when the newManualExpenseFlow beta is enabled — this is a new feature introduced by PR Feat: Manual expense flow UI refactor - r3 #87920.
• PR Feat: Manual expense flow UI refactor - r3 #87920 is listed in the current StagingDeployCash checklist (item Rather than creating RegExp when triggering callbacks, create the RegExp when subscribing. #17 chronologically) and was merged on 2026-05-13, aligning with when the bug appeared.
• The bug specifically involves the new Manual expense flow UI (IOURequestStepConfirmation rendered inline within IOURequestStartPage) introduced by this PR.

Verification

• Affected files: src/pages/iou/request/IOURequestStartPage.tsx, src/pages/iou/request/step/IOURequestStepConfirmation.tsx, src/components/MoneyRequestConfirmationList.tsx, src/components/ParticipantPicker.tsx
• PR Feat: Manual expense flow UI refactor - r3 #87920 directly modifies all of these files. Confirmed via gh pr view 87920 --json files.
• The bug only manifests when CONST.BETAS.NEW_MANUAL_EXPENSE_FLOW beta is active, which is exactly the feature gating added by this PR via isBetaEnabled(CONST.BETAS.NEW_MANUAL_EXPENSE_FLOW) in IOURequestStartPage.

Root Cause

PR #87920 changed the Manual tab in IOURequestStartPage to render IOURequestStepConfirmation inline (instead of IOURequestStepAmountWithTransactionOnly). This is wrapped in a TabScreenWithFocusTrapWrapper, which interacts with the FABPopoverMenu's focus management.

When the user opens the FAB, presses "Create expense", and navigates to the Manual tab:

1. startMoneyRequest is called with isFromFloatingActionButton: true, which sets this flag in the TRANSACTION_DRAFT Onyx key.
2. IOURequestStepConfirmation renders inline with focusable inputs inside the FocusTrap.
3. When the RHP is closed, the transaction draft is not fully cleared — the OPTIMISTIC_TRANSACTION_ID draft retains its isFromFloatingActionButton: true state (only draftTransactionIDs entries are nullified by clearMoneyRequest, not the optimistic transaction draft itself).
4. On the second FAB open, the "Create expense" item receives focus (via the onFocus={() => setFocusedIndex(itemIndex)} handler on the FABFocusableMenuItem), which highlights it. Because the new inline confirmation screen affects navigation/focus restoration, the focusedIndex is not reset to -1 as expected, leaving the item visually highlighted.

The bug is staging-only and requires the newManualExpenseFlow beta to reproduce, confirming it was introduced by PR #87920.