Programmatic focus of TextInput in useEffect fails silently in Bridgeless mode on iOS

[QichenZhu]

Description

The focus() method of TextInput in useEffect doesn't work in Bridgeless mode on iOS. The input is not focused, and the soft keyboard doesn’t appear.

Even worse, the isFocused() method returns true regardless, so future calls to focus() are ignored because it considers the input already focused.

Steps to reproduce

1. Build and run the iOS app with New Arch enabled.

cd ReproducerApp
yarn
bundle install
cd ios
RCT_NEW_ARCH_ENABLED=1 pod install
cd ..
yarn ios

2. Check if the TextInput is focused initially. If so, the test passes. If not, proceed to steps 3-5.

3. Click the Focus button.

4. Click the Blur button.

5. Click the Focus button.

Expected result: The TextInput is focused initially.

Actual result: The TextInput is not focused initially and after the first time clicking the Focus button. It is only focused after clicking Blur and then clicking Focus again.

React Native Version

0.76.1

Affected Platforms

Runtime - iOS

Output of npx react-native info

System:
  OS: macOS 14.5
  CPU: (8) x64 Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz
  Memory: 9.90 GB / 24.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 20.18.0
    path: ~/.nvm/versions/node/v20.18.0/bin/node
  Yarn:
    version: 1.22.22
    path: ~/.nvm/versions/node/v20.18.0/bin/yarn
  npm:
    version: 10.8.2
    path: ~/.nvm/versions/node/v20.18.0/bin/npm
  Watchman:
    version: 2024.07.29.00
    path: /usr/local/bin/watchman
Managers:
  CocoaPods:
    version: 1.15.2
    path: /Users/penguin/.rbenv/shims/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 23.4
      - iOS 17.4
      - macOS 14.4
      - tvOS 17.4
      - visionOS 1.1
      - watchOS 10.4
  Android SDK: Not Found
IDEs:
  Android Studio: Not Found
  Xcode:
    version: 15.3/15E204a
    path: /usr/bin/xcodebuild
Languages:
  Java: Not Found
  Ruby:
    version: 3.1.2
    path: /Users/penguin/.rbenv/shims/ruby
npmPackages:
  "@react-native-community/cli":
    installed: 15.0.0
    wanted: 15.0.0
  react:
    installed: 18.3.1
    wanted: 18.3.1
  react-native:
    installed: 0.76.1
    wanted: 0.76.1
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: true
  newArchEnabled: true

Stacktrace or Logs

N/A

Reproducer

https://github.com/QichenZhu/reproducer-react-native-textinput-focus

Screenshots and Videos

Bridgeless Enabled	Bridgeless Disabled
bridgeless-enabled.mp4	bridgeless-disabled.mp4

[shubhamguptadream11]

@QichenZhu
This is specific to New arch only.
I initially tried to delay the calling of .focus() and it somehow worked this way.

setTimeout(() => {
      textInputRef.current?.focus();
    }, 0);

This is weird. I am still finding out what's the exact issue

[s77rt]

Problem

The useEffect is called too early before the mount instructions are executed i.e. before the components are registered in the view registry, due to the mount being async. The focus fails as there is no component view with the given reactTag.

Offending commits and PRs:

• afec07a#diff-74d87b8778f3afdd8af5d227cb1aea00dd473ac220c2a89f4895570c37efeb67
• Implement atomic reporting of UI changes in Runtime Scheduler #41157
• Unify feature flags for event loop (2nd attempt) #47084

cc @sammy-SC @rubennorte

Temporarily solution

Patch packages/react-native/ReactCommon/react/renderer/uimanager/UIManagerBinding.cpp

@@ -483,7 +483,7 @@ jsi::Value UIManagerBinding::get(
           uiManager->completeSurface(
               surfaceId,
               shadowNodeList,
-              {.enableStateReconciliation = true, .mountSynchronously = false});
+              {.enableStateReconciliation = true, .mountSynchronously = true});
 
           return jsi::Value::undefined();
         });

Or set the RN flag disableEventLoopOnBridgeless=true but as far as I can the flag system is meant for internal use only.

[rubennorte]

Thanks for reporting this. This is a known issue we're investigating in #47576.

[QichenZhu]

Close this as the related issue #47576 has been resolved.