Expense - RHP scrolls down after changing report and returning from participant list

[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.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: #96228
Email or phone of affected tester (no customers): sjdniosjdoijsojsdoios@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:

• Create workspace A and B.
• Create a report in each workspace chat.

1. Go to staging.new.expensify.com
2. Open FAB > Create expense > Manual.
3. Click Report field.
4. Select report from another workspace.
5. Scroll up and click To field.
6. Click RHP back button.

Expected Result:

RHP will not scroll down after changing report and returning from participant list.

Actual Result:

RHP scrolls down after changing report and returning from participant list.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7213211_1784616811874.15.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7213211

[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/a3e708605f6389d720d1da29ce5ee1bab302171ac82971294da1d5c42d6ccb06

[melvin-bot]

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

[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

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

On desktop web, the manual-expense confirmation RHP scrolls down to the amount field after you open the To (participant) list and then hit the RHP back button — even though nothing was selected. The RHP should stay at its previous scroll position.

What is the root cause of that problem?

This is exposed by #96228 (removed the isNewManualExpenseFlowEnabled beta), which made the new manual flow the default — so the amount field is now an editable inline TextInput in the confirmation list footer, below the To section.

AmountField re-focuses that input whenever the participant picker transitions from visible → hidden, at AmountField.tsx:129-142. The effect's intent (per its comment) is to focus the amount input once the user selects a participant — but it fires on any picker close, including the RHP back button with no selection. Focusing the off-screen amount input makes the browser auto-scroll it into view (downward), which is the reported symptom.

It's desktop-only because autoFocus is gated on !canUseTouchScreen() in TransactionDetailsFields.tsx:70 — on touch devices the effect early-returns.

Evidence & data flow

• Trigger effect — AmountField.tsx:129-142: guard is !autoFocus || isAmountFieldDisabled || isParticipantPickerVisible; when the picker closes (isParticipantPickerVisible → false) it schedules amountInputRef.current?.focus().
• Picker visibility + open/close handlers — IOURequestStepConfirmation.tsx: clicking To sets manuallyOpenedParticipantPickerForTransactionID (→ true); the RHP back button's onClose/onFinish runs closeParticipantPicker (→ false). That true→false toggle re-arms the focus effect.
• Focusable input — in displayAsTextInput mode NumberWithSymbolForm forwards the ref to a real TextInput, so .focus() focuses the actual DOM input and the browser scrolls it into view.
• Flow: open To → isParticipantPickerVisible=true (effect early-returns) → back button → false → effect refocuses amount input → RHP scrolls down.

Confidence: high (code path fully traced; matches desktop-only + new-flow-only repro). Selecting a report "from another workspace" isn't itself the cause — it just ensures the amount field renders as an editable input and is off-screen when you scroll up to To.

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

Only refocus the amount input when a participant was actually selected, not on every picker close:

• In AmountField, track the previous value of isParticipantPickerVisible (e.g. usePrevious) and require prev === true && current === false and that a participant is now present before calling focus(); or
• Move the "focus amount after participant selection" responsibility into IOURequestStepConfirmation's participant-added handler so it fires on selection only, and drop the isParticipantPickerVisible-driven effect in AmountField.

Either preserves the intended "focus amount after picking a participant" behavior while eliminating the unwanted refocus/scroll when the user simply backs out of the To list.

Since this is a deploy blocker, the fastest safe mitigation is the same-author revert path if a scoped fix can't land quickly — but the targeted fix above is small.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement this to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[trjExpensify]

Agree we should just not autoFocus the field on desktop when the picker is opened and closed. Seems minor in the grand scheme of things though.

[yuwenmemon]

The offending PR that caused this deploy blocker was reverted with #96661.

@Expensify/applause please retest this issue on the latest staging build now that the PR has been reverted, and confirm whether it still reproduces.

[puneetlath]

PR reverted.