ScrollView maintainVisibleContentPosition applies the anchor delta to the already-clamped offset when content shrinks (iOS + Android, Fabric)

[muhasabahhub]

Description

When a mount makes a ScrollView's content shorter such that the current contentOffset.y is past the new maximum scroll, both platforms clamp the offset during the mount and then add the anchor's delta to the already-clamped value. The anchor child is not maintained: the offset is driven below zero and clamps to 0, landing at the very top of the list.

The grow direction, using the same anchor and the same prop, is exact to the pixel on both platforms — which is what isolates the clamp ordering as the cause rather than the anchor measurement.

Android — MaintainVisibleScrollPositionHelper.updateScrollPositionInternal() reads scrollView.scrollY fresh after didMountItems, but ReactScrollView.onLayoutChange has already run in the same mount and done if (currentScrollY > maxScrollY) scrollTo(scrollX, maxScrollY).

iOS — RCTScrollViewComponentView._adjustForMaintainVisibleContentPosition() uses _scrollView.contentOffset.y + deltaY after updateState: has set the smaller contentSize, and UIKit clamps contentOffset the moment contentSize drops below it.

Both should apply the delta to the offset captured in the prepare step and clamp afterwards, not before. Both sites are unchanged on main as of filing.

Adjacent, possibly the same root cause: #52757 (maintainVisibleContentPosition scrolls when an item is removed from the head).

Steps to reproduce

Reproducer: https://github.com/muhasabahhub/rn-mvcp-shrink
A single ScrollView, 60 direct View children, no dependencies beyond expo/react/react-native. The on-screen header prints contentOffset.y, contentSize.height, the minIndexForVisible in effect, and the child currently at the top, with the pre-press values frozen beside the live ones.

SHRINK (the defect)

1. Open the app — children start expanded (each carries an 8-line block).
2. Scroll so child 44 is the first child under the header.
3. Press Toggle once (each child loses its 8-line block).
4. Observed: contentOffset.y is 0.0 and the child at top is 0 — about 45 children above the one the anchor named.

GROW (the control)

1. Relaunch. Press Toggle once so the children are collapsed.
2. Scroll so child 44 is the first child under the header.
3. Press Toggle once (each child regains its 8-line block).
4. Observed: child 44 is still at the top, exact.

Full measured numbers, both platforms, are in the repo's README.

Expected

The child at minIndexForVisible keeps its screen position when the content shrinks, as it does when it grows. Where the correct offset is reachable within the new content, the anchor should be maintained; only a target beyond the new maximum should clamp.

Actual

contentOffset.y is driven below zero and clamps to 0.0 — the list lands at the very top, about 45 children above the one the anchor named.

React Native Version

0.86.3

Affected Platforms

Runtime - Android, Runtime - iOS

Output of npx @react-native-community/cli info

OS: Windows 11 10.0.26200
Node: 24.13.1
npm: 11.19.0
expo: 57.0.23 (SDK 57, managed workflow)
react: 19.2.3
react-native: 0.86.3
Architecture: Fabric (new architecture — Expo SDK 57 default)

Devices:
- Samsung Galaxy S25, Android <fill in>, Expo Go
- iPhone 15, iOS 26.6.1, Expo Go

(react-native info is unavailable in this project — @react-native-community/cli is not a dependency of the bare repro. The above is from expo-env-info plus device details.)

Stacktrace or Logs

No crash or error; incorrect scroll position only.

MANDATORY Reproducer

https://github.com/muhasabahhub/rn-mvcp-shrink

Screenshots and Videos

Samsung S25:

Iphone 15:

[muhasabahhub]

Measured numbers, both platforms, from the linked reproducer.

Android — Samsung Galaxy S25, Android 16, Expo Go

	contentOffset.y	contentSize.height	minIndexForVisible	child at top
shrink before	9376.7	12780.0	45	44
shrink after	0.0	2820.0	45	0
grow before	2069.7	2820.0	45	44
grow after	9539.7	12780.0	45	44

iOS — iPhone 15, iOS 26.6.1, Expo Go

	contentOffset.y	contentSize.height	minIndexForVisible	child at top
shrink before	9272.7	12640.0	45	44
shrink after	0.0	2680.0	45	0
grow before	1966.7	2680.0	45	44
grow after	9436.7	12640.0	45	44

What the numbers show:

1. The anchor measurement itself is correct. Content changes by 9960.0 on both platforms across 60 children = 166.0 per child; 45 children above the anchor = 7470.0, which is exactly the observed grow delta on both platforms.

2. The correct shrink landing was reachable. 2069.7 (Android) and 1966.7 (iOS) are offsets the collapsed list demonstrably holds — they are the "grow before" rows above — so this is not the "content shorter than the viewport, position cannot be maintained" case.

3. Those same values are what the clamp alone produces. Subtracting the 7470.0 anchor delta from the already-clamped offset double-counts the shrink, drives contentOffset.y below zero, and it clamps to 0.0.

There is a threshold rather than a gradient: while the pre-press offset still fits under the collapsed list's maximum scroll the anchor holds correctly; past that point every depth lands at 0.0 alike.

Screenshots above, in order: Android shrink before / shrink after / grow before / grow after, then the same four for iOS.

Workaround currently in use: render a trailing spacer child sized to the pre-change content height in the same commit as the shrink, and remove it once the new layout has been measured — the content then never becomes shorter than the current offset during the mount, and the anchor delta applies to an unclamped value. Note that on Android a container-level minHeight on contentContainerStyle achieves the same thing but repaints every text child (a visible flash); a spacer child does not.