fix: wrong selection coordinates on focus

[kirillzyusko]

📜 Description

Fixed non-working KeyboardAwareScrollView on iOS.

💡 Motivation and Context

Turns out that selection is not available straight after input focus. To fix this problem I decided to query selection in next frame:

      DispatchQueue.main.async {
        updateSelectionPosition(textInput: textInput, sendEvent: self.onSelectionChange)
      }

And it works, and works pretty well, but it introduces a regression on iOS < 16. The thing is that starting from iOS 16 Apple started to use TextKit 2. And in TextKit 2 all operations are async, so for iOS 16+ we'll get events like layout updated -> selection updated -> onStart -> onMove, but on iOS 15 it will be layout updated -> onStart -> selection updated -> onMove.

The original JS code assumed selection always arrives before onStart. On iOS < 16, onStart now fires first, so updateLayoutFromSelection() reads stale lastSelection.value from the previous focus session - producing a wrong ayout.value used by maybeScroll throughout the keyboard animation.

So I added pendingSelectionForFocus flag - a shared value that tracks whether onStart fired for a focus change but the corresponding selection event hasn't arrived yet.

In onStart - when focus changes, check if lastSelection.value?.target matches the new target:

• matches (iOS 16+ flow — selection arrived first): call updateLayoutFromSelection() as before
• doesn't match (iOS < 16 flow — selection is late): set layout.value = input.value as a safe fallback (full input height instead of cursor-precise height), set the pending flag

The immediate scroll for focus-change-without-keyboard-appearing (focusWasChanged && !keyboardWillAppear) is skipped when pending, since we don't have accurate layout data yet.

In onSelectionChange - when the target changes and the pending flag is set:

• clear the flag
• call updateLayoutFromSelection() with the now-correct selection data
• If keyboard was already visible (no onMove expected), perform the deferred scroll

This ensures layout.value is correct before onMove starts using it for scroll interpolation.

In onEnd — lastSelection.value is cleared to null when the keyboard fully hides (e.height === 0). This prevents a subtle bug: when re-focusing the same input at a different cursor position, lastSelection.value?.target would still match e.target from the previous session, making onStart incorrectly think fresh selection data was available.

Closes #1218

📢 Changelog

JS

• added pendingSelectionForFocus flag;
• added logic for proper selection updates depending on the flag state;

iOS

• dispatch selection in next frame on focus so that it becomes available;

E2E

• re-generated Android 28 test assets;

🤔 How Has This Been Tested?

Tested manually on:

• iPhone 16 Pro (iOS 26.2, simulator);
• e2e_emulator_28 (API 28, emulator);
• iPhone 13 Pro (iOS 15.5, simulator).

📸 Screenshots (if appropriate):

iOS 15	iOS 26
Simulator.Screen.Recording.-.iPhone.13.Pro.-.2026-02-09.at.11.51.59.mov	Simulator.Screen.Recording.-.iPhone.17.Pro.-.2026-02-09.at.11.32.28.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
243687 bytes	241741 bytes	1946 bytes 📈