Fix MVCP anchor selection when z-index reorders children - #57959
Open
hsource wants to merge 2 commits into
Open
Conversation
meta-cla
Bot
added
the
CLA Signed
facebook-github-tools
Bot
added
the
Shared with Meta
hsource
commented
Aug 14, 2026
| paddingBottom?: number, | ||
| }; | ||
|
|
||
| function AppendingList(): React.Node { |
Contributor
Author
There was a problem hiding this comment.
This change was made because cloneElement seemed to remove the zIndex, so we instead render items without cloneElement.
While I was at it, I also changed this to a function component.
hsource
added a commit
to wanderlog/react-native
that referenced
this pull request
Aug 14, 2026
This patch should not be needed once react#57959 is merged. When Fabric reorders scroll content children due to z-index, the old computeTargetView logic picked the first child in hierarchy order whose end position exceeded the scroll offset. That could anchor to the wrong item, so height changes kept the bottom edge fixed instead of the top. Scan all children and select the topmost visible anchor instead. Extend the RNTester AppendingList example with negative z-index values and a "Change height at id" control to reproduce the bug. Test plan (Android): 1. Open RNTester → ScrollView → "smooth bi-directional content loading" 2. Add a few items and scroll so there are items above and below the current item 3. Use "Change height at id" to change the height of an item in the middle 4. Verify the top edge of that item stays in place, rather than the bottom edge jumping Co-authored-by: Cursor <cursoragent@cursor.com>
Contributor
Author
|
Note that I realized this is an issue on iOS too! I have an idea for a more universal fix that also ensures minIndexForVisible works correctly too (it currently doesn't) |
hsource
changed the title
Contributor
Author
|
I just updated the PR to also cover iOS and added more automated testing. I then manually retested on both Android and iOS. @janicduplessis I know you wrote the previous PR. Let me know what you think of this one! This is also ready for a review by someone from Meta! @Abbondanzo - it looks like you've reviewed some related logic recently (#57294) - would you maybe be able to review this? I appreciate it! |
hsource
commented
Aug 20, 2026
| })), | ||
| ); | ||
|
|
||
| const renderItem = (item: ItemInfo, horizontal: boolean) => ( |
Contributor
Author
There was a problem hiding this comment.
Here's an easier to review diff of the component rendering changes:
When Fabric reorders scroll content children due to z-index, the old computeTargetView logic picked the first child in hierarchy order whose end position exceeded the scroll offset. That could anchor to the wrong item, so height changes kept the bottom edge fixed instead of the top. Scan all children and select the topmost visible anchor instead. Extend the RNTester AppendingList example with negative z-index values and a "Change height at id" control to reproduce the bug. Test plan (Android): 1. Open RNTester → ScrollView → "smooth bi-directional content loading" 2. Add a few items and scroll so there are items above and below the current item 3. Use "Change height at id" to change the height of an item in the middle 4. Verify the top edge of that item stays in place, rather than the bottom edge jumping Co-authored-by: Cursor <cursoragent@cursor.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary:
Motivation
At Wanderlog, we use a FlatList with negative zIndex so earlier items' bottom shadows can cover later items (by default, later items cover earlier items).
When
maintainVisibleContentPositionis enabled, the native helper selects the scroll anchor by scanning content children and picking the first one whose end position exceeds the current scroll offset. Fabric can reorder native children when views usezIndex, so hierarchy order no longer matches layout order. On both iOS and Android, the helper can then anchor to the wrong item, and scroll corrections keep the bottom edge of the visible content fixed instead of the top.When
minIndexForVisible > 0, skipping early items also needs to follow layout order rather than native hierarchy order.Fix
iOS and Android: Scan all eligible children and select the topmost visible anchor (the smallest end position still below the scroll offset). When
minIndexForVisible > 0, sort children by layout position before applying the skip. Also clear the cached anchor when the helper stops listening.Ported from the approach in #46247, adapted for the current Kotlin helper and Fabric iOS scroll view, and simplified.
Changelog:
[GENERAL] [FIXED] - Fix
maintainVisibleContentPositionanchoring to the wrong child when z-index reorders Fabric childrenTest Plan:
Automated Android tests
Automated Fantom tests
Manual test on iOS and Android using RNTester:
Android
iOS