Report - Report title box is not scrolled to the bottom after pasting several lines of text

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.63-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: #97489
Email or phone of affected tester (no customers): ibellicotest+2766@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11 / Chrome
App Component: Money Requests

Action Performed:

Prerequisite: Account has a workspace.
Prerequisite 2: Copy several lines of text from a chat or document. (More than 5 lines)

1. Open the staging.new.expensify.com website.
2. Open any workspace chat.
3. Create a manual expense.
4. Open the just created expense and click on the title to edit it.
5. Delete the original title and paste the copied text on the title box.
6. Note that title box is not autoscrolled to the bottom and user has to scroll manually to the end of the title.

Expected Result:

After pasting several lines of text on a report title box, user should be autoscrolled to the bottom and the end of the title should be visible.

Actual Result:

Report title box is not autoscrolled to the bottom after pasting text with several lines in it.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7244689_1787875387843.Title_6.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @apeyada

[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/61dfaf20b66ed2c50242071d2d68337c198ae90b5358c1d0a64f1e8a9e936dec

[melvin-bot]

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

[melvin-bot]

@chuckdries @mkhutornyi you have been assigned to this deploy blocker because you reviewed the offending PR: #97489

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

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #97489 - "Let single-field edit input grow to reduce wasted white space" by @MelvinBot (High confidence)
Related Issues: #96905 (the issue #97489 was fixing)

Recommendation: ROLL FORWARD

PR #97489 is the true cause — it introduced the growing/scrollable title editor (autoGrowSingleLine), which is why this is N/A in production. Reverting would reintroduce the "wasted white space" bug that #97489 fixed for every title/text-field editor; the regression here is a minor, self-correcting edit-time edge case (the saved value is squashed to a single line anyway), so a small targeted follow-up is preferable to a revert.

Assigned: @chuckdries and @mkhutornyi (approving reviewers of #97489) are already assigned. PR author is a bot, so no additional assignee added.
Labels: No change. DeployBlockerCash is kept (App-side fix required); no DeployBlocker was present.

📋 Detailed Analysis

Evidence

• PR Let single-field edit input grow to reduce wasted white space #97489 (merged 2026-08-27, first shipped in 9.4.63-0 — matches the reported version) added a new autoGrowSingleLine capability and enabled it on the report title / text report-field editor.
• The prop autoGrowSingleLine is used in exactly one place in the codebase — src/pages/EditReportFieldText.tsx — which is precisely the "click the title to edit it" screen in the repro steps. This is the only consumer of the new behavior.
• Before this PR the title input was a fixed single-line box, so "paste multi-line text → autoscroll to bottom" could not occur. The bug is therefore a brand-new edge case that this PR created, consistent with "Reproducible in production?: N/A - new feature."
• The PR wires the caret-to-end behavior only for the initial autofocus path, not for later content changes like paste (see Root Cause), so pasting a multi-line block leaves the viewport scrolled to the top of the grown/capped box.

Verification

• Affected editor page: src/pages/EditReportFieldText.tsx — enables the feature at line 103 (autoGrowSingleLine) with autofocus at line 47 (useAutoFocusInput(true)).
• Feature wrapper: src/components/TextInput/BaseTextInput/index.tsx — lines 39-49 maps autoGrowSingleLine onto autoGrowHeight + maxAutoGrowHeight (115px cap) and wires Shift+Enter submit, but adds no scroll-to-end on content change.
• git log confirms these files were last touched by Let single-field edit input grow to reduce wasted white space #97489 and the prop exists nowhere else, ruling out a false attribution.

Root Cause

The autoGrowSingleLine input grows to variables.textInputAutoGrowMaxHeight (~115px) and then scrolls internally. The only code that moves the caret/scroll to the end of the value is in useAutoFocusInput:

• on autofocus it calls moveSelectionToEnd(input) — src/hooks/useAutoFocusInput.ts line 75
• a scrollToBottom(ref) helper already exists (src/libs/InputUtils/index.ts, sets scrollTop = scrollHeight) and is used only on the side-panel focus path — line 159.

There is no handler that scrolls the input to the bottom when its content changes after focus (e.g. a paste). Once the box is at its capped height, react-native-web does not auto-scroll the grown container to the caret, so the end of the pasted text stays below the fold until the user scrolls manually.

Suggested targeted fix (App-side, small): in the autoGrowSingleLine branch of src/components/TextInput/BaseTextInput/index.tsx (lines 39-49), wrap onChangeText so that after the value changes it calls the existing scrollToBottom from @libs/InputUtils on the input DOM node (guarded to web / when scrollTop exists), mirroring how useAutoFocusInput already reuses that helper. This scrolls the caret/end into view on paste and on typing past the cap without affecting native or the saved single-line value.

Note: severity is low — the title is saved as a single line regardless (line breaks are squashed to spaces on submit), so this only affects the transient edit view for pasted multi-line content.