[Due for payment 2026-07-08] [$250] Expense- Search field is not highlighted when auto focused after switching from Scan to Manual

[applause-bot]

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.4.17-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #94134
Email or phone of affected tester (no customers): joisjdnosjdoijso@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Account does not have workspace.

1. Go to staging.new.expensify.com
2. Open FAB > Create expense > Scan.
3. Go to Manual tab.

Expected Result:

Search field will be highlighted when auto focused.

Actual Result:

Search field is not highlighted when auto focused.
The cursor overlaps with field title.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7188070_1782170668330.2.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7188070

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022070747167021174735
• Upwork Job ID: 2070747167021174735
• Last Price Increase: 2026-06-27
• Automatic offers:
• thelullabyy | Reviewer | 111844341

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/69b5d5b52e65d8e8f7cba26cbd07a7f31e6c15e9b06ccee30c904dfdb15d43f2

[melvin-bot]

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

[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.

[MelvinBot]

Proposal

Root Cause: This is a regression from #94134 ("remove isNewManualExpenseFlowEnabled beta flag"), which is why it reproduces on staging but not production (the beta gated the new flow). With the flag gone, the Manual tab now always mounts IOURequestStepConfirmation instead of the old amount screen. For an account with no workspace and no default participant, that screen auto-opens the participant picker (shouldAutoOpenParticipantPicker), and the "Name, email, or phone number" search field is what the reporter sees auto‑focused.

The field gets the caret (DOM .focus() lands) but shows no focus border and the label never floats because both of those visuals are gated entirely on the React isFocused state, which is set only by the onFocus handler:

• highlight border → isFocused && styles.borderColorFocus
• label float → activateLabel/deactivateLabel driven by isFocused
• setIsFocused(true) only fires in onFocus

On the Scan → Manual transition the field is focused imperatively (SelectionList's setTimeout(focusTextInput, 300ms)) while the start page is mid–remount (FullScreenLoadingIndicator → confirmation → docked modal). The .focus() call lands on the input, but the React onFocus event isn't delivered, so isFocused stays false → no highlight, label doesn't float, caret overlaps the title. Opening the Manual tab fresh works because there's no intervening loader→confirmation→modal remount race.

Why the caret is there but the styling isn't (evidence)

• The mount‑only autofocus effect calls input.current.focus() but never setIsFocused(true): BaseTextInput implementation/index.tsx:131-140.
• The participant search field is focused imperatively (not via the React autoFocus prop) through SelectionList/components/TextInput.tsx → useSelectionListTextInput.ts, so the visual state relies on the DOM focus event reaching onFocus.
• Symptoms ("not highlighted", "cursor overlaps field title") map exactly to isFocused === false while the element is the active element.

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

Make BaseTextInput's isFocused authoritative instead of trusting that the onFocus event always arrives: after a programmatic focus lands (e.g. on layout, or by comparing the input against the document's active element), set isFocused to true so the border and label-float reconcile even when the DOM focus event is missed during the remount. This fixes the visual symptom regardless of which focus path (autoFocus prop vs. imperative .focus()) was used. Because BaseTextInput is a widely‑used core component, the change must be regression‑tested broadly.

What alternative solutions did you explore? (Optional)

• Fix the timing instead of the state: trigger the participant search focus off the docked modal's "shown" callback rather than a fixed 300 ms timer, so a real onFocus is reliably delivered after the open animation settles. More targeted to this flow but doesn't harden other focus-during-remount cases.
• Deploy-blocker fast path: if a code fix can't land quickly, revert #94134 to re-gate the new manual flow behind the beta. Heavier, but immediately unblocks the deploy.

---

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

[m-natarajan]

Chrome / v9.4.17-1
Not repro

REC-20260623175758.mp4