fix: wrong offset for KeyboardAwareScrollView when keyboard resizes

[kirillzyusko]

📜 Description

Fixed an issue when resizing keyboard constantly pushes content up.

💡 Motivation and Context

When a user switches between keyboard types (e.g. text keyboard → emoji keyboard and back), KeyboardAwareScrollView was accumulating scroll offset instead of converging to a stable position. Each toggle would push the scroll further, even though the input's actual on-screen position hadn't changed. It's caused by 2 bugs:

1️⃣ Stale absoluteY during keyboard resize

maybeScroll uses layout.value.absoluteY to determine how much to scroll. This value is populated by the native FocusedInputLayoutChanged event. On iOS, the native observer uses KVO on the input's center relative to its superview (the scroll view's content area). When the scroll view scrolls, the input's center relative to the content doesn't change — only the scroll view's bounds.origin shifts — so KVO never fires and absoluteY is never updated.

As a result, when the emoji keyboard opens and the component scrolls (say) +76px, the stored absoluteY still reflects the pre-scroll position. When switching back to the text keyboard, maybeScroll computes an overshoot based on that stale value, producing a cumulative drift on every toggle.

On Android the native side does report updated absoluteY on scroll, so only iOS is affected — but the stale-value case is latent everywhere.

2️⃣ scrollBeforeKeyboardMovement was clobbered on every keyboard resize

This value is used as the interpolation base when the keyboard hides: we scroll back to it. It was being overwritten on every onStart event, including keyboard-size-only changes (emoji ↔ text). That meant after one toggle, the "home position" shifted, and hiding the keyboard would scroll to the wrong place.

---

The fix consist from two parts.

For 1️⃣ problem - when onStart fires for a keyboard-size change on the same input (keyboardWillChangeSize && !actualFocusChanged), we recompute absoluteY from first principles:

absoluteY = layout.y - position.value + scrollViewPageY

layout.y is the input's Y offset relative to the scroll view's content — this is stable and never stale. Subtracting the current scroll offset and adding the scroll view's on-screen origin gives the true current position on screen, regardless of what the native side reported.

For 2️⃣ problem - we gate the scrollBeforeKeyboardMovement update behind actualFocusChanged. Keyboard-size-only changes (same target, different height) no longer disturb this value, so the scroll-back-on-hide always returns to the position captured at the original focus event.

Closes #1318

📢 Changelog

JS

• added actualFocusChanged variable inside onStart handler;
• update scrollBeforeKeyboardMovement only if actualFocusChanged===true (not focusWasChanged);
• covered new code with unit tests;
• update layout.value.absoluteY when keyboard gets resized;

🤔 How Has This Been Tested?

Tested paper arch on:

• Pixel 9 Pro (API 35)
• iPhone 17 Pro (iOS 26.2)

📸 Screenshots (if appropriate):

iOS	Android
Simulator.Screen.Recording.-.iPhone.17.Pro.-.2026-03-31.at.15.44.27.mov	Screen.Recording.2026-03-31.at.15.46.18.mov

📝 Checklist

• CI successfully passed
• I added new mocks and corresponding unit-tests if library API was changed

[github-actions]

📊 Package size report

Current size	Target Size	Difference
310446 bytes	309372 bytes	1074 bytes 📈

[kirillzyusko]

Closing in favour of #1417