Summary:
Fixes https://github.com/facebook/react-native/issues/47725
Calling Appearance.setColorScheme(null) or Appearance.setColorScheme(undefined) no longer resets the color scheme useColorScheme returns like on previous rn versions.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [FIXED] - Fix `Appearance.setColorScheme(null)` not resetting color scheme value
Pull Request resolved: https://github.com/facebook/react-native/pull/47739
Test Plan: Repo with a patch ready to test: https://github.com/sangonz193/react-native-color-scheme-patch
Reviewed By: yungsters
Differential Revision: D66230236
Pulled By: cipolleschi
fbshipit-source-id: cc668acb1fde6d30f2706fc0ab7dee5cea1c3b14
Summary:
I noticed that `AppDelegate` subscribers listening for `applicationDidEnterBackground` events in Expo projects (as documented [here](https://github.com/expo/expo/blob/238b6f57e459dd2c0b13ee158f0af709fe922460/docs/pages/modules/appdelegate-subscribers.mdx?plain=1#L56) aren't working as expected anymore.
While investigating, I discovered that the events aren't reaching the `ExpoAppDelegate` implementation ([source](https://github.com/expo/expo/blob/71f2c55ff3f11e43ab43761bb5cece2e48eae0bf/packages/expo-modules-core/ios/AppDelegates/ExpoAppDelegate.swift#L61)) because the `RCTAppDelegate` implementation of `applicationDidEnterBackground` interrupts the event chain. This appears to be affecting some legitimate use cases.
I believe we could improve this by removing the current implementation, but I'd love to hear your thoughts on this approach. I might be missing some context about why this implementation was originally needed, so any insights would be greatly appreciated!
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - Fix applicationDidEnterBackground not being called
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [FIXED] - Fix applicationDidEnterBackground not being called
Pull Request resolved: https://github.com/facebook/react-native/pull/48376
Test Plan: Ran a local test after change
Reviewed By: javache
Differential Revision: D67621557
Pulled By: cipolleschi
fbshipit-source-id: 2d73711372deba867bd616c79ef4d00c79aa86d5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48525
Fixes https://github.com/facebook/react-native/issues/48249
`TextMeasureCacheKey` hash and equality functions only incorporates the maximum width constraint. I'm guessing this was an attempt at an optimization, but it can lead to incorrect results in pretty trivial cases. E.g. if Yoga knows a definite size of `Text` in one dimension, and measures via `YGMeasureModeExactly`, we can have a minimum size corresponding specific to the style in which the text was laid out.
Changelog:
[General][Fixed] - Fix TextMeasureCacheKey Throwing Out Some LayoutConstraints
Reviewed By: christophpurrer
Differential Revision: D67922414
fbshipit-source-id: 0ee0220059fc4e4645b1684c42a0587fe728bedd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46629
If we clipped and had no border or corner radius we would end up hitting this path every time. We can optimize this a bit to avoid that.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D63299597
fbshipit-source-id: 90031f964b7669049a4a2efe00a553c888d28cd7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48225
Fixes https://github.com/facebook/react-native/issues/47762
The weak event emitter in AttributedString attributes is causing a serialization error when typing into a TextInput in a Mac Catalyst build. We can resolve this by not putting the event emitters in the attributed string, but this is likely to cause other issues with event handling for nested <Text> components.
## Changelog
[iOS][Fixed] - Workaround for Mac Catalyst TextInput crash due to serialization attempt of WeakEventEmitter
Reviewed By: NickGerleman
Differential Revision: D66664583
fbshipit-source-id: efdfbcb0db4d5e6b9bf7c14f9bbb221faae2d724
Summary:
Fixes an [issue](https://github.com/facebook/react-native/issues/48168) where only iOS configurations with "Debug" in the name are configured to use the hermes debugger.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [FIXED] - Enable hermes debugger by configuration type instead of configuration name
Pull Request resolved: https://github.com/facebook/react-native/pull/48174
Test Plan:
Added new test scenarios that all pass:
```
ruby -Itest packages/react-native/scripts/cocoapods/__tests__/utils-test.rb
Loaded suite packages/react-native/scripts/cocoapods/__tests__/utils-test
Started
Finished in 0.336047 seconds.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
56 tests, 149 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
166.64 tests/s, 443.39 assertions/s
```
In a personal project with the following configurations:
```
project 'ReactNativeProject', {
'Local' => :debug,
'Development' => :release,
'Staging' => :release,
'Production' => :release,
}
```
I added the following to my Podfile:
```
installer.pods_project.targets.each do |target|
target.build_configurations.each do |config|
puts "#{config.name} is debug? #{config.type == :debug}"
end
end
```
To confirm that my logic is correct:
```
Local is debug? true
Development is debug? false
Staging is debug? false
Production is debug? false
```
Reviewed By: robhogan
Differential Revision: D66962860
Pulled By: cipolleschi
fbshipit-source-id: 7bd920e123c9064c8a1b5d45df546ff5d2a7d8be
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48124
Fixes https://github.com/facebook/react-native/issues/47592
The logic in HeadlessJsTaskService is broken. We should not check whether `getReactContext` is null or not.
Instead we should use the `enableBridgelessArchitecture` feature flag to understand if New Architecture was enabled or not.
The problem we were having is that `HeadlessJsTaskService` was attempting to load the New Architecture even if the user would have it turned off. The Service would then die attempting to load `libappmodules.so` which was correctly missing.
Changelog:
[Android] [Fixed] - Fix crash on HeadlessJsTaskService on old architecture
Reviewed By: javache
Differential Revision: D66826271
fbshipit-source-id: 2b8418e0b01b65014cdbfd0ec2f843420a15f9db
Summary:
GHA to build HermesC for windows are failing because the machines comes with a different CMake version already.
Let's try not to install Cmake and use the one provided by the machine.
## Changelog:
[Internal] -
Pull Request resolved: https://github.com/facebook/react-native/pull/48122
Test Plan: GHA {F1973187648}
Reviewed By: alanleedev
Differential Revision: D66825216
Pulled By: cipolleschi
fbshipit-source-id: 9a9376a5409e192195a6b6cc25b4d58cb47f15da
Summary:
A NPE can occur when a user touches the screen before the `SurfaceMountingManager` is initialized. Below is an example of the error log from our production service. This issue can also be reproduced using RNTester. To prevent invalid touch events during init time of rn app from causing an NPE, add a null check for SurfaceMountingManager before calling mark/sweepActiveTouchForTag.
```
Fatal Exception: java.lang.NullPointerException: Attempt to invoke virtual method 'void com.facebook.react.fabric.mounting.SurfaceMountingManager.markActiveTouchForTag(int)' on a null object reference
at com.facebook.react.fabric.FabricUIManager.markActiveTouchForTag(FabricUIManager.java)
at com.facebook.react.uimanager.JSTouchDispatcher.markActiveTouchForTag(JSTouchDispatcher.java)
at com.facebook.react.uimanager.JSTouchDispatcher.handleTouchEvent(JSTouchDispatcher.java)
at com.facebook.react.runtime.ReactSurfaceView.dispatchJSTouchEvent(ReactSurfaceView.java)
at com.facebook.react.ReactRootView.onInterceptTouchEvent(ReactRootView.java)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2870)
at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3352)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2963)
at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3352)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2963)
at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3352)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2963)
at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3352)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2963)
at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3352)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2963)
at com.android.internal.policy.DecorView.superDispatchTouchEvent(DecorView.java:794)
at com.android.internal.policy.PhoneWindow.superDispatchTouchEvent(PhoneWindow.java:1967)
at android.app.Activity.dispatchTouchEvent(Activity.java:4571)
at com.rainist.banksalad2.feature.common.BaseActivity.dispatchTouchEvent(BaseActivity.java)
at androidx.appcompat.view.WindowCallbackWrapper.dispatchTouchEvent(WindowCallbackWrapper.java:70)
at com.android.internal.policy.DecorView.dispatchTouchEvent(DecorView.java:752)
at android.view.View.dispatchPointerEvent(View.java:16498)
at android.view.ViewRootImpl$ViewPostImeInputStage.processPointerEvent(ViewRootImpl.java:8676)
at android.view.ViewRootImpl$ViewPostImeInputStage.onProcess(ViewRootImpl.java:8423)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:7752)
at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:7809)
at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:7775)
at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:7978)
at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:7783)
at android.view.ViewRootImpl$AsyncInputStage.apply(ViewRootImpl.java:8035)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:7756)
at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:7809)
at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:7775)
at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:7783)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:7756)
at android.view.ViewRootImpl.deliverInputEvent(ViewRootImpl.java:11343)
at android.view.ViewRootImpl.doProcessInputEvents(ViewRootImpl.java:11212)
at android.view.ViewRootImpl.enqueueInputEvent(ViewRootImpl.java:11168)
at android.view.ViewRootImpl$WindowInputEventReceiver.onInputEvent(ViewRootImpl.java:11477)
at android.view.InputEventReceiver.dispatchInputEvent(InputEventReceiver.java:337)
at android.os.MessageQueue.nativePollOnce(MessageQueue.java)
at android.os.MessageQueue.next(MessageQueue.java:335)
at android.os.Looper.loopOnce(Looper.java:187)
at android.os.Looper.loop(Looper.java:319)
at android.app.ActivityThread.main(ActivityThread.java:9063)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:588)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1103)
```
https://github.com/user-attachments/assets/e9c6ff84-c94d-4392-9042-8e635197202e
## Changelog:
[Android] [Fixed] - Avoid NPE when touch event is triggered before SurfaceManager is initiated
Pull Request resolved: https://github.com/facebook/react-native/pull/48007
Test Plan:
I checked the crashed being fixed on RNTester.
https://github.com/user-attachments/assets/71f7e359-707a-494c-ae34-fef8d432e612
Reviewed By: cortinico
Differential Revision: D66594576
Pulled By: javache
fbshipit-source-id: b1559d94866bdb021e0374f1953684849603033c
Summary:
currently running jest test, it shows an error:
```
ReferenceError: You are trying to `import` a file after the Jest environment has been torn down. From __tests__/App.test.tsx.
at getState (node_modules/react-native/Libraries/Utilities/Appearance.js:18:26)
at addChangeListener (node_modules/react-native/Libraries/Utilities/Appearance.js:71:19)
at subscribe (node_modules/react-native/Libraries/Utilities/useColorScheme.js:10:66)
at subscribeToStore (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:6232:10)
at commitHookEffectListMount (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:13038:26)
at commitPassiveMountOnFiber (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:14461:11)
at commitPassiveMountEffects_complete (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:14421:9)
at commitPassiveMountEffects_begin (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:14408:7)
at commitPassiveMountEffects (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:14396:3)
at flushPassiveEffectsImpl (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:16287:3)
at flushPassiveEffects (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:16236:14)
at node_modules/react-test-renderer/cjs/react-test-renderer.development.js:16051:9
at workLoop (node_modules/scheduler/cjs/scheduler.development.js:266:34)
at flushWork (node_modules/scheduler/cjs/scheduler.development.js:239:14)
at Immediate.performWorkUntilDeadline [as _onImmediate] (node_modules/scheduler/cjs/scheduler.development.js:533:21)
```
it is a regression from https://github.com/facebook/react-native/issues/46123 that to have a lazy require.
this pr tries to mock `useColorScheme` to return `light`. i think we don't necessarily test the color scheme changes in jest runtime. originally `useColorScheme` also returns `light` because of [this statement](https://github.com/facebook/react-native/blob/9a60038a40e16925ea1adeb3e3c937c22a615485/packages/react-native/Libraries/Utilities/Appearance.js#L77-L83)
## Changelog:
[GENERAL] [FIXED] - Fixed jest error from Appearance.js
Pull Request resolved: https://github.com/facebook/react-native/pull/47629
Test Plan:
```sh
$ npx react-native-community/cli init RN0762 --pm bun --version 0.76.2
$ cd RN0762
$ bun test run
```
Reviewed By: cipolleschi
Differential Revision: D66297456
Pulled By: huntie
fbshipit-source-id: 80d1460532e76bd1815c66964547b50d7f7b3558
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47875
The old architecture looks broken because in the OnLoad.cpp file we try to include the autolinking.h header which is only generated when the New Architecture is enabled.
This fix guards the include and the usage of the function provided by the autolinking so that the old architecture should work as well.
## Changelog
[Internal] - Include autolinkin.h in OnLoad.cpp only if it exists
Reviewed By: blakef
Differential Revision: D66295318
fbshipit-source-id: 18461e6b70ac92af57b805bef51c0df49db02283
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47670
Now that we have `babel-plugin-syntax-hermes-parser` in `react-native/babel-preset` (since D63535216), it's no longer necessary to use `hermes-parser` directly in Metro in order to use newer Flow syntax.
Babel with `babel-plugin-syntax-hermes-parser` is generally preferable, because it intelligently falls back to parsing with Babel for any non-`flow` files.
See https://github.com/facebook/hermes/issues/1549 for context.
Changelog:
[General][Fixed] metro-config: Don't use `hermes-parser` by default, prefer `babel-plugin-syntax-hermes-parser`, which supports other syntax plugins.
Reviewed By: huntie
Differential Revision: D66002056
fbshipit-source-id: cf48acec347e2c0791872f8ca4b53f5f8af1c783
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47737
We may see an NSRangeException when setting new AttributedString content, where setting the AttributedString itself changes selection (before we mutate it later).
It seems like the selection here is not in a good state yet in regards to the AttributedString backing exposed (since we are reading it while modifying it). So let's fold the logic for updating typing attributes into the collection of ignored work from non-user-selection updates, since programatically setting an AttributedString will already trigger updating typing attributes.
I also added a nil check here, which is unrelated to the crash, but it seems like we should have it for safety...
Changelog:
[iOS][Fixed] - Fix possible NSRangeException when updating typing attributes in response to new text content
Reviewed By: cipolleschi
Differential Revision: D66202986
fbshipit-source-id: fded492b5022c5fef5b9563f93a57549d06a7020
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47669
When investigating [#47476](https://github.com/facebook/react-native/issues/47476), I found that the `secureTextInput` prop was not changing in the Mounting layer when changing it in JS.
I track down the problem to the `UIManager::cloneNode` method.
When we clone the node, we first merge the patch that arrives from React into the props controlled by setNativeProps, ignoring the patch's props that are controlled by React.
But then, we forgot to merge back the React's controlled property into the final props, effectively losing them.
This change adds an extra merging step, merging the props controlled with setNativeProps back into the patch of props controlled by React, and then using this new set of props as source of truth.
## Changelog:
[General][Fixed] - do not discard props in the patch when they are not null while using `useNativeProps`
Reviewed By: sammy-SC
Differential Revision: D65948574
fbshipit-source-id: db4f2b793f4a6348456933c95a151012252b8ebc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47333
Motivated by https://github.com/facebook/hermes/issues/1549. This was originally changed in https://github.com/facebook/react-native/pull/46696, as our internal Flow support had diverged from `babel/eslint-parser` (https://github.com/facebook/react-native/issues/46601).
We effectively have three flavours of JavaScript in support:
- Flow@latest for the `react-native` package, shipped as source — uses `hermes-parser`.
- TypeScript for product code (community template, Expo) — uses `babel/plugin-syntax-typescript`.
- Plain JavaScript or Flow in product code, *which may be extended with additional user Babel plugins and needs lenient parsing* — uses `babel/plugin-syntax-flow` via `babel/eslint-parser` (**this change**).
I'd love to simplify this 😅.
Switching to `hermes-eslint` for the RN monorepo codebase (D63541483) is unchanged.
Changelog: [Internal]
Reviewed By: robhogan, cipolleschi
Differential Revision: D65272156
fbshipit-source-id: 3a2bbe3fcf8ed6057f6d994a0be4985e6bf46fa9
Summary:
CI is failing to build HermesC on windows due to a version mismatch of the CMake already installed
## Changelog:
[Internal] - Fix Windows CI for HermesC
Pull Request resolved: https://github.com/facebook/react-native/pull/47867
Test Plan: GHA
Reviewed By: robhogan
Differential Revision: D66292617
Pulled By: cipolleschi
fbshipit-source-id: 5e8f4f45e33fbdd9ff163b4e8a09cb98d4366dc7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47874
We should be searching for the .bat file on Windows to remain compatible with some user setups.
Changelog: [Android][Fixed] look for sdkmanager.bat
Reviewed By: cipolleschi
Differential Revision: D66295240
fbshipit-source-id: 6b79a9aa40f77ed9c5b3d6ad92b1a62e78159223
Summary:
This pull request addresses a CMake configuration issue where an invalid escape character in file paths caused the build process to fail. Specifically, it resolves the issue in the React Native CMake configuration file where the path separator was incorrectly handled, leading to an error in the build system.
the issue is in [This Issue](https://github.com/expo/expo/issues/32955) and [This](https://github.com/expo/expo/issues/32957)
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [FIXED] - Corrected invalid escape character in CMake path handling
Pull Request resolved: https://github.com/facebook/react-native/pull/47641
Test Plan:
To test the changes, I performed the following steps:
1. Cloned the repository and checked out the `fix-cmake-invalid-escape-character` branch.
2. Ran the CMake build on a Windows environment where the issue was previously occurring.
3. Verified that the build process completed successfully without the "invalid character escape" error.
4. Ensured that the path handling now works correctly in CMake on Windows platforms.
Reviewed By: rshest
Differential Revision: D66073896
Pulled By: cipolleschi
fbshipit-source-id: bd2a71bb00ce5c5509ed403842c995c32f58f91d
