TextInputs (keyboard) within list items are totally broken on Android

[mefjuu]

Keyboard opened from within TextInput put in a list item causes the list to jump to (almost) top.
Tested on Android 16. No problem on iOS.

legendlist-keyboard.mov

[jmeistrich]

It looks like you added that as into our example app? Could you share the repo so I can test it?

[mefjuu]

@jmeistrich Here it is: https://github.com/mefjuu/legend-list

[sirus-max]

Hey @jmeistrich ,
I was facing the same, i tried debugging it (opus 4.6 found it honestly),
It fixes the issue and provides the following explanation,
I am not 100% sure about this but hope it helps you ,

`---

Summary

Root Cause

All LegendList containers use position: absolute with top: 0 and are visually positioned via transform: [{ translateY: position }].

The Fix Applied

Changed PositionView to use top/left instead of translateY/translateX for both new-arch (PositionViewState) and old-arch (PositionViewAnimated) variants. This makes each container's Yoga layout frame match its visual position, so iOS auto-scroll to the first responder works correctly.

Note: PositionViewSticky (sticky headers) still uses transform because it relies on Animated.interpolate with useNativeDriver: true for real-time scroll tracking. Sticky headers typically don't contain TextInputs, so this should be fine.

Detailed explanation:

1. How LegendList Positions Items

Unlike FlatList which lays items out in normal top-to-bottom flow (like a column of blocks stacked naturally), LegendList uses a virtualization strategy with absolute positioning.

Every item container has this base style:

            : {
                  left: otherAxisPos,
                  position: "absolute",
                  right: numColumns > 1 ? null : 0,
                  top: 0,
                  width: otherAxisSize,

Notice: every container has top: 0. They all start at the same position — the very top of the list's content area.

Then, in PositionView, each container is visually moved to its correct position. Before the fix, this was done with translateY:

// BEFORE (old code)
style={[
    style,  // contains { top: 0, position: "absolute" }
    { transform: [{ translateY: position }] }  // e.g. translateY: 500
]}

So an item that should appear 500px down the list was:

• Layout position: top: 0 (as far as the layout system is concerned, it's at the top)
• Visual position: shifted 500px down via translateY

The user sees it at 500px. But the Android system thinks it's at 0px.

---

2. The Difference Between top and translateY on Android

This is the core of the issue. In Android's native view system, every View has two separate concepts of position:

Layout Position (View.getTop())

This is where the layout engine (Yoga, in React Native's case) places the view. When you set top: 0 in React Native, Yoga tells Android: "this view's layout position is y=0." Android stores this and returns it from View.getTop().

Translation (View.getTranslationY())

When you set transform: [{ translateY: 500 }] in React Native, it calls Android's View.setTranslationY(500). This is a visual-only offset — it shifts where the view is drawn on screen, but it does not change View.getTop(). The layout system still thinks the view is at y=0.

Think of it like this:

• top = "where the view lives in the layout tree"
• translateY = "draw it shifted from where it lives"

┌─── ScrollView content ───────────────────┐
│                                          │
│  [Container] ← getTop() returns 0       │
│  (layout position is y=0)               │
│                                          │
│                                          │
│                                          │
│           ┌──────────────┐               │
│           │  TextInput   │ ← visually    │
│           │  (item #5)   │   at y=500    │
│           └──────────────┘   because of  │
│                              translateY  │
│                                          │
└──────────────────────────────────────────┘

Android sees the view at y=0. The user sees it at y=500.

---

3. What Happens When You Tap a TextInput on Android

When you tap a TextInput, React Native's native EditText (the Android backing view) becomes focused. Android's focus system then does this automatically, at the native level:

1. The EditText calls requestRectangleOnScreen()
2. This walks up the view hierarchy, calling requestChildRectangleOnScreen() on each parent
3. When it reaches the ScrollView, the ScrollView computes where the focused view is using child.getTop()
4. Since getTop() returns 0 (the layout position, ignoring translationY), the ScrollView thinks: "the focused view is at y=0, let me scroll there to make it visible"
5. The ScrollView scrolls to the top

This entire chain happens synchronously in the native Android layer, before any JavaScript code runs. That's why:

• Your onTouchStart debugger couldn't catch it — JS events haven't fired yet
• It feels "instant" — there's no async delay, no bridge crossing
• You can't intercept it from JavaScript

---

4. Why FlatList Doesn't Have This Issue

FlatList uses normal flow layout (flexbox). Items are stacked naturally:

┌─── FlatList ScrollView ──────────────────┐
│  ┌──────────────┐  ← getTop() = 0       │
│  │   Item 0     │                        │
│  └──────────────┘                        │
│  ┌──────────────┐  ← getTop() = 100     │
│  │   Item 1     │                        │
│  └──────────────┘                        │
│  ┌──────────────┐  ← getTop() = 200     │
│  │   Item 2     │                        │
│  └──────────────┘                        │
│         ...                              │
└──────────────────────────────────────────┘

Each item's getTop() returns its actual position in the list. When Android's focus system calls requestChildRectangleOnScreen(), the ScrollView sees the correct y-coordinate and either doesn't scroll (already visible) or scrolls to the right place.

No transforms involved, no mismatch between layout and visual position.

---

5. What the Fix Does

The fix changes PositionView from using translateY to using top directly:

            style={[
                style,
                horizontal ? { left: position } : { top: position },
            ]}

Now the style array is [{ top: 0, position: "absolute", ... }, { top: 500 }]. React Native merges these left-to-right, so the final computed style is { top: 500, position: "absolute", ... }.

Yoga then tells Android: "this view's layout position is y=500." Now:

• View.getTop() = 500 (correct!)
• View.getTranslationY() = 0 (no transform)
• When the focus system asks "where is this view?", the ScrollView sees y=500
• It scrolls to the correct position (or doesn't scroll at all if already visible)

┌─── LegendList ScrollView (AFTER FIX) ───┐
│                                          │
│                                          │
│                                          │
│           ┌──────────────┐               │
│           │  TextInput   │ ← getTop()    │
│           │  (item #5)   │   returns 500 │
│           └──────────────┘   (correct!)  │
│                                          │
└──────────────────────────────────────────┘

---

6. Why Was translateY Used in the First Place?

translateY is generally preferred for moving views because:

• It's a GPU-composited operation — the GPU just shifts the rendered pixels
• It doesn't trigger a layout recalculation — siblings and parents don't need to re-measure

top triggers Yoga to recalculate the view's layout. However, since these views are position: absolute, the layout cost is minimal — absolute-positioned views don't affect their siblings' layout.

Interestingly, the codebase already used top/left for macOS because transforms didn't work well there (the old line 67-68 comment said "react-native-macos seems to not work well with transform here"). The same class of issue — just manifesting differently on each platform.

---

7. Why PositionViewSticky Still Uses translateY

You'll notice the sticky header variant still uses transforms:

            return horizontal ? [{ translateX: stickyPosition }] : [{ translateY: stickyPosition }];

This is because sticky headers use Animated.interpolate driven by animatedScrollY with useNativeDriver: true. The native animation driver on Android only supports transform properties (not top/left). Since sticky headers typically don't contain TextInputs, this shouldn't be a problem in practice.

---

TL;DR

	translateY (before)	top (after)
Android View.getTop()	0 (wrong)	position (correct)
What Android focus system sees	"View is at y=0"	"View is at y=position"
Result on TextInput focus	Scrolls to top	Stays in place / scrolls correctly
Visual position	Correct	Correct

The mismatch between "where Android thinks the view is" and "where the user sees the view" was the entire problem. The fix eliminates that mismatch.`

[jmeistrich]

I believe this is fixed in 3.0.0-beta.47. Can you please give that a try and let me know if it's working better?

I changed it to use position instead of transform on all platforms, and only use transform for sticky elements so they animate better. Transform was causing a lot of other problems and wasn't clearly even having better performance anyway.