fix: intercept input events along with keyboard events

[kirillzyusko]

📜 Description

Fixed a problem when focusDidSet event wasn't emitted/FocusedInputHolder hold a wrong reference/useReanimatedFocusedInput return layout as null when TextInput has a focus, but keyboard is not shown.

💡 Motivation and Context

Before functionality with layout retrieval was toughly coupled with keyboard events. And it worked - if keyboard is shown, then there is 100% probability that input has a focus. However we may have a different situation, when input has a focus but keyboard is not shown (showSoftInputFocus={false}/physical keyboard connected). Of course "focused input" functionality should work independently of keyboard events.

1️⃣ Naive approach - let's rely on didBeginEditing/didEndEditing events

The first native approach was to rely on focus/blur events. It works well for iOS 16, 17, 18. But thanks to our e2e tests they caught a bug on iOS 15. The problem can be shown schematically as:

- iOS 15: keyboardWillShow -> didReceiveFocus, keyboardWillHide (not fired when we switch) -> didReceiveBlur
- iOS 17: didReceiveFocus -> keyboardWillShow, keyboardWillHide (not fired when we switch) -> didReceiveBlur

So basically on iOS 15 keyboardWillShow is emitted before didBeginEditing. As a result onStart event doesn't have a layout and KeyboardAwareScrollView can not perform a scroll into correct position (by specification useReanimatedFocusedInput should provide an information before or along with keyboard events).

Last, but not least - after further investigation I discovered, that when blur/hide happens we may have several chain of events:

• keyboardWillHide -> blur (when keyboard simply gets closed);
• blur (when keyboard stays on screen and you switch between inputs);
• blur -> keyboardWillHide (when you focus to the next input, but next input has showSoftInputFocus={false})

So to sum up: we may have a random order of events, but should handle all of them properly.

So what should we do?

2️⃣ Gateway approach

The second approach I've been thinking of is a creation of a gateway for events. I. e. we will listen for all events simultaneously, but will handle only first "focus"/"blur" events.

How it works:

Focus

iOS 15

• we receive keyboardWillShow event - let's store a reference, setup KVO, emit event;
• we receive didBeginEditing - ignore this event, since it was already handled by keyboardWillShow

iOS 17

• we receive didBeginEditing event - let's store a reference, setup KVO, emit event;
• we receive keyboardWillShow - ignore this event, since it was already handled by didBeginEditing

Note

This order is handled by

   if UIResponder.current == currentResponder {
     // focus was already handled by keyboard event
     return
   }

Blur

keyboardWillHide -> blur (when keyboard simply gets closed)

Similar to focus gateway we added:

    if currentResponder == nil {
      // blur was already handled by keyboard event
      return
    }

blur (when keyboard stays on screen and you switch between inputs)

However we have another small problem - when we switch between inputs blur event is emitted, but keyboardWillHide is not (and we don't need to send noFocusedInput event during a switch). To handle it I added this code:

    DispatchQueue.main.async {
      // check that it wasn't a switch between inputs
      if self.currentResponder == nil {
        self.onBlur()
      }
    }

We schedule event sending asynchronously, and wait. If we receive subsequent "focus" event, then we ignore that event.

blur -> keyboardWillHide (when you focus to the next input, but next input has showSoftInputFocus={false})

Last thing to consider. To fix this basically when we dispatch onBlur we need to check, that we indeed don't have a first responder in chain. To do this I added a check:

    if UIResponder.current is TextInput {
      return
    }

Closes #758

📢 Changelog

iOS

• added listeners for textDidEndEditingNotification and textDidBeginEditingNotification for UITextView/UITextField;
• implemented a gateway approach for managing potentially duplicated events.

🤔 How Has This Been Tested?

Tested on iPhone 16 Pro iOS 18.1 + e2e tests for iOS 17, 16, 15.

📸 Screenshots (if appropriate):

Simulator.Screen.Recording.-.iPhone.15.Pro.-.2025-01-21.at.11.45.20.mp4

📝 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
168038 bytes	167703 bytes	335 bytes 📈