Report field & Taxes - Name field auto throws error

[lanitochka17]

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.41-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: #79834
Email or phone of affected tester (no customers): sijnisojnsiojdosjjo2@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• Enable Report fields in workspace settings > Reports.

1. Go to staging.new.expensify.com
2. Go to workspace settings > Reports.
3. Click Add field.
4. Click Name.

Expected Result:

Name field will not throw error.

Actual Result:

Name field auto throws error.
If user enters text on Name field before error shows up, "Name" header is highlighted instead.
Similar issue is observed in Taxes > Add rate > Name.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7107652_1773951312264.2.mp4

View all open jobs on GitHub

[melvin-bot]

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

[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: #79834 - "fix: [Web] Focus restoration mechanism on back navigation (#76921)" by @mavrickdeveloper (High confidence)
Related Issues: None identified

Recommendation: REVERT

The PR introduced a race condition between NavigationFocusManager focus restoration and intentional auto-focus behavior in modals. This affects Report Fields Name input and Taxes Name input, causing premature validation errors.

Labels: This is a frontend bug affecting the App. DeployBlockerCash label will be kept as the causing PR is in the App repository and requires an App fix (revert or patch).

📋 Detailed Analysis

Evidence

• Issue is reproducible on staging (where PR fix: [Web] Focus restoration mechanism on back navigation (#76921) #79834 is deployed) but NOT on production
• PR fix: [Web] Focus restoration mechanism on back navigation (#76921) #79834 was merged on March 19, 2026 at 11:44 AM UTC, and this issue was reported the same day
• The issue affects Report Fields > Add field > Name and Taxes > Add rate > Name - both use the TextPicker component

Root Cause

PR #79834 modified useAutoFocusInput hook to add a shouldPreserveExistingFocus() function that prevents auto-focusing inputs if any element is already focused in the document.

The bug flow:

1. User navigates to Report Fields > Add field > clicks Name field
2. TextSelectorModal opens with a TextInput that should auto-focus
3. TextSelectorModal uses useFocusEffect to focus the input after transition
4. At the same time, NavigationFocusManager (introduced by PR fix: [Web] Focus restoration mechanism on back navigation (#76921) #79834) attempts to restore focus from the previous screen
5. The shouldPreserveExistingFocus() function detects an active element and prevents the input from focusing
6. However, form validation still runs (checking if Name is filled)
7. Since the field is empty and required, validation error appears immediately - even though the user hasnt interacted with the field yet

Key code location: src/hooks/useAutoFocusInput.ts lines 22-33 and 62-64, 71-73

The shouldPreserveExistingFocus function is too aggressive - it prevents legitimate auto-focus behavior in modals/forms that are intentionally designed to focus inputs on mount.

Affected Components

• /home/runner/_work/App/App/src/pages/workspace/reports/CreateReportFieldsPage.tsx - Report Fields Name input
• /home/runner/_work/App/App/src/pages/workspace/taxes/NamePage.tsx - Taxes Name input
• Both use TextPicker → TextSelectorModal which relies on auto-focus behavior

Verification

✅ PR #79834 modifies src/hooks/useAutoFocusInput.ts (introduces shouldPreserveExistingFocus)
✅ PR #79834 modifies src/components/FocusTrap/FocusTrapForScreen/index.web.tsx (adds NavigationFocusManager)
✅ PR merged March 19, 2026 - same day as issue report
✅ Issue states "Reproducible in staging: Yes" and "Reproducible in production: No"
✅ Issue clearly shows the Name field throwing error without user interaction (see video in issue)

[MelvinBot]

Proposal

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

When navigating to workspace settings > Reports > Add field > Name (or Taxes > Add rate > Name), the Name field inside the TextSelectorModal auto-throws a validation error before the user has interacted with it. If the user types before the error appears, the "Name" header gets highlighted instead. This is reproducible on staging but not production, traced to PR Expensify/App#79834.

What is the root cause of that problem?

PR #79834 introduced a new FocusTrapForScreen implementation (src/components/FocusTrap/FocusTrapForScreen/index.web.tsx) with focus capture/restore logic via NavigationFocusManager. This creates a race condition with the TextSelectorModal's auto-focus mechanism.

Both affected pages (CreateReportFieldsPage and WorkspaceCreateTaxPage) use TextPicker, which opens TextSelectorModal as a right-docked modal. Inside the modal:

1. ScreenWrapper wraps content in FocusTrapForScreen, which activates a focus-trap with delayInitialFocus: 300ms
2. TextSelectorModal uses useFocusEffect to focus the TextInput after CONST.ANIMATED_TRANSITION (also 300ms)
3. The modal's FormProvider has shouldValidateOnBlur={!isClosing} (defaults to true)

The race condition:

• When the modal opens, the focus-trap's onActivate blurs the active element (the button the user clicked)
• The focus-trap registers a focusin DOM listener (checkFocusIn) to enforce focus containment
• At ~300ms, useFocusEffect fires and focuses the TextInput
• The focus-trap's delayed initial focus also tries to resolve at ~300ms
• This timing conflict causes the TextInput to receive focus and then immediately lose it when the focus-trap's focus management interferes
• The blur event triggers FormProvider.onBlur → setTouchedInput(inputID) + onValidate(inputValues) (see src/components/Form/FormProvider.tsx:423-445)
• Since the Name field is empty and required={true}, validation returns an error, displaying it before user interaction

The key code locations:

• src/components/FocusTrap/FocusTrapForScreen/index.web.tsx:158-171 — onActivate blurs active element, delayInitialFocus: CONST.ANIMATED_TRANSITION
• src/components/TextPicker/TextSelectorModal.tsx:100-119 — useFocusEffect focuses input after same 300ms delay
• src/components/TextPicker/TextSelectorModal.tsx:169 — shouldValidateOnBlur={!isClosing} enables blur validation
• src/components/Form/FormProvider.tsx:423-445 — onBlur handler that calls setTouchedInput + onValidate

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

Since this is a deploy blocker, the safest and fastest option is to revert PR #79834. The focus restoration feature can be re-introduced in a follow-up PR with proper handling for modal-based focus flows.

If a targeted fix is preferred instead of a full revert, the fix should ensure the focus-trap activation inside modals doesn't interfere with intentional useFocusEffect-based auto-focus. Possible approaches:

• Pass focusTrapSettings to ScreenWrapper inside TextSelectorModal to disable or customize the focus trap behavior for modal contexts
• Adjust the delayInitialFocus timing or initialFocus callback in FocusTrapForScreen to yield to existing focus intents inside modals

What alternative solutions did you explore? (Optional)

• Adding shouldValidateOnBlur={false} to TextSelectorModal's FormProvider — this would mask the symptom but disable legitimate blur validation for all TextPicker modals
• Modifying useAutoFocusInput's shouldPreserveExistingFocus — this is only relevant for the Taxes NamePage (which uses useAutoFocusInput), not for the TextSelectorModal flow which uses its own useFocusEffect

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.