[0.83] fix(scrollview): honor programmatic scrollTo when scrollEnabled={false}

[Collin Schneide (FaithfulAudio)]

Problem

On a ScrollView/FlatList with scrollEnabled={false}, imperative scrollTo / scrollToOffset / scrollToIndex do nothing on RNW. On iOS/Android, scrollEnabled blocks only user gestures — programmatic scrolls still apply.

Root cause

ScrollViewComponentView::scrollTo() early-returns when scrollEnabled is false. scrollToIndex/scrollToOffset route through the scrollTo command, so all imperative scrolls are dropped.

Fix

Remove the early-return. User-gesture scrolling remains gated by m_scrollVisual.ScrollEnabled(...) (set from scrollEnabled in updateProps), so this only re-enables programmatic scrolls — matching iOS/Android semantics.

Validation

Bug reproduced in a production RNW 0.83.2 new-arch app (Facilitron FIT, Windows 11 ARM64, Debug, 250% scale): a scrollEnabled={false} ScrollView with 800-DIP content in a 110-DIP viewport ignores scrollTo({y:500, animated:false}) — the call fires, no scroll event is emitted, content stays at Row 0. The probe renders its own status line:

Expected after-state per the diff: TryUpdatePosition applies the offset and onScroll reports y=500. Needs upstream CI + the same probe on a framework source build.

Intentionally not touched: StartBringIntoView() and scrollToEnd()/scrollToStart() carry an analogous gate but also serve keyboard/focus paths — changing those would alter keyboard-scroll semantics, so they're flagged for maintainer discussion instead. Authored against 0.83-stable; happy to re-cut onto main.

Microsoft Reviewers: Open in CodeFlow

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Collin Schneide (FaithfulAudio)]

@microsoft-github-policy-service agree [company="Facilitron"]

[Collin Schneide (FaithfulAudio)]

@microsoft-github-policy-service agree company="Facilitron"

[Collin Schneide (FaithfulAudio)]

Validated end-to-end on a patched framework source build. We compiled this fix into Microsoft.ReactNative from source (yarn-patch, RNW 0.83.2, ARM64 Debug; patched dll verified as the loaded module via GetDeviceCaps/GDI32 import markers vs the stock NuGet dll as negative control) and re-ran the same probe in our production app: scrollTo({y:500}) on a scrollEnabled={false} ScrollView now applies — status line reads "onScroll y: 500" with the y=500 row at viewport top (previously "none", content parked at Row 0).

Before:
After:

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Collin Schneide (FaithfulAudio)]

Andrew Coates (@acoates-ms) — a batch CI request, since this PR is in the best shape of the set and you're already familiar with it from #16303.

Ten Windows PRs from me are open and none has ever had Azure CI run — each shows only license/cla (passing), with the bot's "an authorized user must comment /azp run" notice. I can't start the pipeline myself, so they're all waiting on that one action. Everything below is MERGEABLE with no conflicts.

0.83-stable:

PR
#16304	this one — scrollTo honored when scrollEnabled={false}, matching iOS/Android
#16302	TextInput single-line centering at >100% display scale
#16303	TextInput placeholder px-vs-DIP + no-op NaN fontSize guard — both of your review asks are discharged (the != 0 guard was dropped as you suggested)
#16330	show touch keyboard on TextInput focus/tap (windowless island)
#16333	Fabric touch-input reliability — primary-button labeling, guaranteed touch END/CANCEL, phantom active-touch self-heal
#16334	crash (0xc0000005) when the pointer-capturing component has been unmounted
#16335	backport of #16140 (PointerRoutedAway + ScrollView contentOffset DIP) to 0.83-stable

main twins (following the pattern you asked for on #16303 → #16317):

PR
#16317	placeholder px-vs-DIP, main companion
#16336	scrollTo twin of #16304
#16337	null-guard twin of #16334

If it's easier to batch, /azp run on #16304 and #16333 alone would cover the two biggest behavioural surfaces (ScrollView and the touch pipeline).

Context on where these come from: all of them are running in production in a shipping RNW 0.83.2 new-arch app (Facilitron FIT), compiled from source with UseExperimentalNuget=false, so the patched framework is what the app actually loads. #16333 and #16334 in particular were validated with real PT_TOUCH injection soaks rather than mouse simulation, since the mouse path doesn't exercise the touch pipeline at all. Where I couldn't verify something, the PR bodies say so in plain text rather than implying coverage I don't have.

Happy to split, rebase, or narrow any of these if that makes review easier — and if the main twins should lead instead of the stable ones, say so and I'll reorder.

[Copilot]

Pull request overview

This PR aligns React Native Windows Fabric ScrollView behavior with iOS/Android by ensuring imperative scrolling APIs (scrollTo and the commands that route through it, like scrollToIndex/scrollToOffset) still work when scrollEnabled={false}—while keeping user-gesture scrolling disabled via the existing ScrollEnabled gating.

Changes:

• Removed the scrollEnabled early-return in ScrollViewComponentView::scrollTo, so programmatic scroll requests are no longer dropped.
• Added an explanatory comment documenting the intended cross-platform semantics and why this is safe in RNW.
• Added a change file to record the patch update for react-native-windows.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
vnext/Microsoft.ReactNative/Fabric/Composition/ScrollViewComponentView.cpp	Always honors programmatic scrollTo even when scrollEnabled is false; user gestures remain disabled via m_scrollVisual.ScrollEnabled.
change/react-native-windows-fix-scrollview-programmatic.json	Patch change entry describing the behavior fix.

[Andrew Coates (acoates-ms)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).