Summary:
Though the `ReactHost.destroy()` is not being used from OSS code, we use it at Expo for expo-dev-client to change loading apps from different dev servers. Without cleanup the `mAttachedSurfaces`, it will have dangling or duplicated attached surfaces that cause duplicated react trees.
<img src="https://github.com/facebook/react-native/assets/46429/f84d274e-aaad-4352-9e3c-6262571a5625">
This PR tries to cleanup the `mAttachedSurfaces` from destroying.
## Changelog:
[ANDROID] [FIXED] - Fixed dangling `mAttachedSurfaces` after `ReactHost.destroy()`
Pull Request resolved: https://github.com/facebook/react-native/pull/44393
Test Plan: have to manually call `ReactHost.destroy()` and recreate the MainActivity without killing the process. then reload the app will startSurface for the same attached surfaces.
Reviewed By: RSNara
Differential Revision: D56901863
Pulled By: javache
fbshipit-source-id: c7f822501d971810ac6aa7262b15da69ec41355e
Summary:
`pod install` and CocoaPods are actually not macOS specific.
Still, the pod lifecycle scripts of `react-native` depend on macOS-only utilities and will fail on Linux.
This is an attempt to make the scripts portable and make the pod install cleanly on Linux as well as macOS.
## Changelog:
[INTERNAL] [FIXED] - Skip XCode patching when not run on macOS
[INTERNAL] [FIXED] - Fall back to `which gcc`/`which g++` to identify C/C++ compiler when `xcrun` not available
[INTERNAL] [FEAT] - Recognize CC and CXX env vars supplied to the script and prefer them over autodetection
Pull Request resolved: https://github.com/facebook/react-native/pull/44417
Reviewed By: NickGerleman
Differential Revision: D57055928
Pulled By: cipolleschi
fbshipit-source-id: 1c49f70c52b4667abf0a215cbee52ee6aa6dd052
Summary:
This PR updates `typescript-eslint/eslint-plugin` and `typescript-eslint/parser` to `v7` and `eslint-plugin-jest` to `v27`, removing any dependencies on `typescript-eslint` `v6`, allowing projects using `react-native/eslint-config` to safely update to `typescript-eslint` `v7` without having to worry about duplicate major versions installed
## Changelog:
- [General] [Changed]: Updated `eslint-plugin-jest` to `v27`
- [General] [Changed]: Updated `typescript-eslint` monorepo to `v7`
Pull Request resolved: https://github.com/facebook/react-native/pull/43406
Test Plan: `yarn run lint` executed locally successfully
Reviewed By: robhogan
Differential Revision: D54749676
Pulled By: tdn120
fbshipit-source-id: f6fae92fc95333e28b36a3d2bd8470c8869d38bc
# Conflicts:
# package.json
# packages/eslint-config-react-native/package.json
# yarn.lock
Co-authored-by: Lluís <lluis@skrit.es>
Summary:
XCode privacy files might not contain a `NSPrivacyAccessedAPITypes` key, which causes the following error:
```
[!] An error occurred while processing the post-install hook of the Podfile.
undefined method `each' for nil
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:111:in `block (4 levels) in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:106:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:106:in `block (3 levels) in get_used_required_reason_apis'
```
<!-- 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
-->
[IOS] [FIXED] - Privacy Manifest aggregation failing due to no `NSPrivacyAccessedAPITypes` key
Pull Request resolved: https://github.com/facebook/react-native/pull/44628
Test Plan: I tested this patch on our own app and it solved the issue.
Reviewed By: christophpurrer
Differential Revision: D57618425
Pulled By: cipolleschi
fbshipit-source-id: 1a36ab5a1bb45b8507d3663b782c95258d97c8a4
Summary:
In https://github.com/facebook/react-native/pull/37510, a check was introduced to check if user is using `latest` version of `npx`, but right now it checks for every command executed, but it should only ensure that `latest` is included when creating a new project.
In this Pull Request I've added a condition to only warn if `init` was fired.
[GENERAL] [FIXED] - Warn only in `init` command when CLI uses cached `npx` version
Pull Request resolved: https://github.com/facebook/react-native/pull/44644
Test Plan: Warning about using `latest` version CLI should only be presented when running `init` command.
Reviewed By: arushikesarwani94
Differential Revision: D57681864
Pulled By: blakef
fbshipit-source-id: 5c81b9a08141396efcd24539b2560cea16028dd9
Summary:
The new cocoapod post install script includes aggregation and generation of privacy manifests for iOS, which is great. However, the script doesn't consider the case where the file reference doesn't have a path.
Example, for a project setup like the screenshot:
<img width="249" alt="image" src="https://github.com/facebook/react-native/assets/22592111/45dd1cf4-c2f6-4abb-940f-136a4d502966">
The code
https://github.com/facebook/react-native/blob/05a4232dd591e2d43f192d69ca14a04f4a3fb6a1/packages/react-native/scripts/cocoapods/privacy_manifest_utils.rb#L80-L81
prints `file_refs`:
```
[
<PBXFileReference name=`LaunchScreen.storyboard` path=`learnX/LaunchScreen.storyboard` UUID=`81AB9BB72411601600AC10FF`>,
<PBXVariantGroup name=`InfoPlist.strings` UUID=`D40B9F832B248EF5004BC08C`>,
<PBXFileReference path=`AppCenter-Config.plist` UUID=`D40B9F802B248EC2004BC08C`>,
<PBXFileReference name=`PrivacyInfo.xcprivacy` path=`learnX/PrivacyInfo.xcprivacy` UUID=`D403DD362BCA2BCF00E5295C`>,
<PBXFileReference name=`Assets.xcassets` path=`learnX/Assets.xcassets` UUID=`D40B9F652B248AEB004BC08C`>
]
```
where a `PBXVariantGroup` exists and it doesn't have `path`. The error `undefined method 'end_with?' for nil` occurs as a result.
## 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] - In privacy manifest post install script, handle the case where the file reference doesn't have a path
Pull Request resolved: https://github.com/facebook/react-native/pull/44410
Test Plan:
1. Add a new "Strings File (Legacy)" in Xcode to the project.
2. Run `pod install` for iOS.
3. See the error `undefined method 'end_with?' for nil`.
4. Apply the fix and rerun `pod install`.
5. The script runs successfully.
Reviewed By: javache
Differential Revision: D57056159
Pulled By: cipolleschi
fbshipit-source-id: 42caaf1a98efb9111f6ff1014a5c8b7703b042f2
Summary:
This pull request fixes an issue where the `selectionColor` prop was not applied to the `TextInput` component on iOS, starting from React Native version 0.74.x.
This issue was introduced in PR [1e68e485](https://github.com/facebook/react-native/commit/1e68e48534aedf1533327bf65f26e5cf5b80127b#diff-b6634353ea5b10a91de24605dc51bdfb50e8ddb652ccd5b9dab194168a69d4b1) which relocated `selectionColor` along with `selectionHandleColor` and `cursorColor` out of `otherProps`. This modification inadvertently prevented `selectionColor` from being passed to the iOS native component.
This change ensures that the `selectionColor` prop is explicitly included in the `RCTTextInputView` component's properties, fixing the regression.
Note: `selectionHandleColor` and `cursorColor` are Android-specific and do not require explicit passing on iOS.
## 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
-->
[IOS] [FIXED] - Fixed an issue where the `selectionColor` prop was not being applied on the `TextInput` component.
Pull Request resolved: https://github.com/facebook/react-native/pull/44420
Test Plan:
**Environment:** iOS Simulator, React Native 0.74.0.
**Steps to reproduce:**
- Implement a `TextInput` component with the `selectionColor` prop set.
- Run the application on an iOS device or simulator.
- Focus on the TextInput component, write some text and select it.
**Expected Result:** the selection color should match the color provided to the `selectionColor` prop.
**Actual result before fix:** the selection color did not reflect the specified `selectionColor` prop and fell back to the default iOS selection color (blue).
**Screenshots:**
- Before fix:
<img width="1710" alt="before_fix" src="https://github.com/facebook/react-native/assets/17989553/8660068c-55c9-4f55-a788-f96eb681fb70">
- After fix:
<img width="1710" alt="after_fix" src="https://github.com/facebook/react-native/assets/17989553/93c9eb26-7da0-4957-b54f-8444aff7e374">
Reviewed By: javache
Differential Revision: D57017836
Pulled By: NickGerleman
fbshipit-source-id: 263ce22168e09c15cdfdb4eb4300a2605d8af032
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44398
**Problem:**
`selection` prop is not being set on component creation.
Not quite sure which RN version this issue was introduced but fixing it on latest code.
Use playground for testing (refer to following diff)
**Proposed Solution:**
Added notes in comments but `viewCommands.setTextAndSelection()` is called only on text or selection update which relies on comparing data with `lastNativeSelection`. Problem is that `lastNativeSelection` is initially set to the props value that is passed in so does not send the command on component creation.
So assign a default selection value of `{start: -1, end: -1}` so it can be set on component creation.
**Changelog:**
[General][Fixed] - `selection` prop in `TextInput` was not being applied at component creation
Reviewed By: cipolleschi
Differential Revision: D56911712
fbshipit-source-id: 7774b246383f85216536040688b0a8ea85b3478a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44155
Add ReactSoftException in ReactHostImpl only when `onActivityResult`, `onNewIntent`and `onWindowFocusChange` do not have the context
Changelog:
[Android][Fixed] ReactSoftExceptions in ReactHostImpl only when Context is null
Reviewed By: cortinico
Differential Revision: D56325407
fbshipit-source-id: a9f8fd5772fc05d39e72236fb8edfe5f8a9d6a43
Summary:
As of now, Apple does not respect privacy manifests added as cocoapods resource bundles. This forces react-native developers to manually copy `.xcprivacy` files content for each native dependency that accesses restricted reason APIs to the root file.
This PR adds an aggregation step that crawls through pod dependencies to collect all reasons into the root privacy info file.
[IOS][ADDED] – Add privacy manifest aggregation.
Pull Request resolved: https://github.com/facebook/react-native/pull/44214
Test Plan:
When run on RNTester, it appends aggregated entries (while keeping existing ones) to existing .xcprivacy file without modifing .pbxproj:
When run on RNTester with the xcprivacy file removed from xcode beforehand, it creates a new .xcprivacy file, and adds it to Compile Bundle Resources in the same way as in the new template:
When run on RNTester with an empty .xcprivacy file, it appends aggregated entries from pods AND reasons for react-native core.
When run with `privacy_file_aggregation_enabled: false` in `use_react_native`, it falls back to existing behavior:
Reviewed By: cipolleschi
Differential Revision: D56481045
Pulled By: philIip
fbshipit-source-id: 1841bad821511c734d0cc0fcff5065ed92af76d8
Summary:
We [received an issue](https://github.com/react-native-maps/react-native-maps/issues/5042) in OSS where a ViewManager was configured to be initialized on the main queue, but it wasn't.
This was creating a soft crash and showing a RedBox to the user.
The library was going through the Interop Layer.
This change makes sure that, if the ViewManager is configured to be setup in the main queue, we retrieve the constants from the Main Queue
## Changelog
[iOS][Fixed] - Extract the constants from ViewManagers in the UI Thread if needed.
Reviewed By: sammy-SC
Differential Revision: D56762253
fbshipit-source-id: ca807b34d6e61418da9fd6a639a05f3394879f7c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44294
**Problem:**
It was discovered while testing 3 party library, generated member variables in a C++ `struct` in `Props.h` is not initialized.
Also `WithDefault` would not work as well.
(For the problematic case it was a `boolean` but would also apply to other primitive types.)
If there is no default initialization and the component prop is optional and the user of the native component does not set the prop then the variable is never initialized and this is problematic for primitive types in C++ where no initialization results in an undefined behavior.
**Proposed solution:**
(Following C++Core Guideline of [always initialize](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-always).)
Reusing `generatePropsString()` used by `ClassTemplate` to generate props for `StructTemplate` as well.
updated relevant test snapshots.
This change is only concerning the `Props.h` file.
**Changelog:**
[General][Fixed] - fixed `Props.h` created from codegen missing default initializers in C++ `struct`
Reviewed By: cipolleschi
Differential Revision: D56659457
fbshipit-source-id: 0d21ad20c0491a7e8bb718cd3156da65def72f23
Summary:
`RCTComposedViewRegistry` extends `NSMutableDictionary` which is a clustered class in iOS.
NSMutableDictionary is techncially an abstract class, but when instantiated by `[NSMutableDictionary new];` the system will return one of concrete classes that inherit from `NSMutableDictionary`, opaquely from the perspective of the caller.
By calling `super`, we are actually calling the not implemented method for the abstract class. If this happen, this can crash the app.
Given that the `RCTComposedViewRegistry` is extending the dictionary only for its interface but is using other mechanisms as storage, is it fair to return `NULL`if the storages don't have the requested view.
## Changelog
[iOS][Fixed] - Avoid calling abstract methods in RCTComposedViewRegistry
Reviewed By: cortinico
Differential Revision: D56755427
fbshipit-source-id: f5c56dc59ccc6b30c00199b4196c42eb9b021e2b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44256
[iOS] [Fixed] - Preserve content offset in ScrollView when the component is suspended
On iOS, components are recycled. For ScrollView, its content offset has to be reset back to original position. When we call `[UIScrollView setContentOffset:]`, it triggers all of its delegate methods and triggers `scrollViewDidScroll` where we set native state.
So when user scrolls to position 100 and scroll view suspends. it is removed from view hierarchy and recycled. Once the suspense boundary is resolved, scroll view will be inserted back into view hierarchy. But when it was recycled, we set back its original content offset (the default is 0, 0) but this was accidentally propagated through to shadow tree.
To avoid this, we simply need to invalidate `_state` before calling `[UIScrollView setContentOffset:]`.
Reviewed By: cipolleschi
Differential Revision: D56573370
fbshipit-source-id: c03d7d2d403af2e1649b4cf189072baeb4c286c8
Summary:
Set the proper build flags for debugging in Bridgeless mode.
This fixes [#44240](https://github.com/facebook/react-native/issues/44240)
## Changelog:
[iOS][Fixed] - Add `HERMES_ENABLE_DEBUGGER=1` flag to React-RuntimeApple
Reviewed By: cortinico
Differential Revision: D56575647
fbshipit-source-id: a0613a5d46caeb1d3e636e54ecd43428fbaf46e8
Summary:
Defines module for `React-jsinspector` that for swift modules to integrate with.
to fix https://github.com/expo/expo/issues/28209, any podspec depends on HermesExecutorFactory should use ` add_dependency(s, "React-jsinspector", :framework_name => 'jsinspector_modern')` to add dependency. otherwise it will encounter the header not found issue because use_frameworks will change "jsinspector-modern" to "jsinspector_modern".
to depend on React-jsinspector from expo-modules-core, we need it to define as a module.
otherwise, it will have the error
```
The Swift pod `ExpoModulesCore` depends upon `React-jsinspector`, which does not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies.
```
## Changelog:
[IOS] [CHANGED] - Add `DEFINES_MODULE` for React-jsinspector.podspec
Pull Request resolved: https://github.com/facebook/react-native/pull/44252
Test Plan: ci passed
Reviewed By: cortinico
Differential Revision: D56575102
Pulled By: cipolleschi
fbshipit-source-id: 9b7b4568a3e499f0a741a79a846263118ff2d112
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44167
We received an issue for OSS where, when the main window is inactive and the system tries to present a dialog, the dialog is not presented in the right position on the screen.
This change introduce a fallback to the first inactive window (which is still visible on screen) and it fixes the issues.
[iOS][Changed] - Fallback to the first `foregroundInactive` window when there are no `foregroundActive` windows in RCTKeyWindow
Reviewed By: dmytrorykun
Differential Revision: D56354741
fbshipit-source-id: fa23131ecd40f6d91c705879a72890506ee21486
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44182
## Changelog:
[iOS] [Fixed] - Fixed stale state on TouchableOpacity and TouchableBounce
When TouchableOpacity and TouchableBounce are unmounted, we need to reset their state. This includes animation state. If we don't do that, view is unmounted on the mounting layer and animation will not be applied. This leaves view in undefined state. In TouchableOpacity, it is view with reduced opacity. TouchableBounce that is view with applied transform.
This was reported in https://github.com/facebook/react-native/issues/44044
Reviewed By: rubennorte, cipolleschi
Differential Revision: D56416571
fbshipit-source-id: 01214ec8a5e07c80a609e082b955a30305ad8396
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44185
This change will fix a symbol not found for JSC Runtime.
The `if` check was not a compile time check, therefore the symbol ended up in the binary even if it is not available.
Following this post on [Apple forum](https://forums.developer.apple.com/forums/thread/749534), this changes should do the trick.
## Changelog
[iOS][Fixed] - Fix Symbol not found: (_JSGlobalContextSetInspectable)
Reviewed By: hash3r
Differential Revision: D56425834
fbshipit-source-id: a37af51b078bd47a938e6b65d9d8e0f7506e746f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43327
<!-- Thanks for submitting a pull request! We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory. -->
## Summary
Swift Pods require the use of [modular headers](https://blog.cocoapods.org/CocoaPods-1.5.0/) to be statically linked. To interop with Objective-C modules, you need to make the Objective-C module "define a Module", that is modular header export.
This is already the case for a few podspecs so they can be consumed in Swift libraries, but `ReactCommon` and `RCT-Folly` don't do this yet and therefore this breaks in a few libraries of mine, for example see this issue: https://github.com/mrousavy/react-native-vision-camera/issues/195.
If I were to include `ReactCommon` or `RCT-Folly` in my Swift library's podspec, the following error arises:
```
[!] The following Swift pods cannot yet be integrated as static libraries:
The Swift pod `VisionCamera` depends upon `RCT-Folly`, which does not define modules.
To opt into those targets generating module maps (which is necessary to import them from Swift
when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or
specify `:modular_headers => true` for particular dependencies.
```
So this PR fixes this issue by allowing Swift libraries to consume the `ReactCommon` and `RCT-Folly` podspecs since they now export modular headers.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Fixed] - Expose Modular Headers for `ReactCommon` podspec
[General] [Fixed] - Expose Modular Headers for `RCT-Folly` podspec
Pull Request resolved: https://github.com/facebook/react-native/pull/31858
Test Plan: * Add s.dependency "ReactCommon" or RCT-Folly to a Swift pod and see what happens. (See https://github.com/mrousavy/react-native-vision-camera/pull/273)
Reviewed By: dmytrorykun
Differential Revision: D54539127
Pulled By: cipolleschi
fbshipit-source-id: 2291cc0c8d6675521b220b02ef0c3c6a3e73be38
Summary:
This change fixes a couple of issues within the RCTUIManager:
* it calls the right method in the `super` branches (although they should neve be executed)
* it invert the call order between the `_registry` and the `uiManager` to avoid extra calls into the `viewForReactTag`.
## Changelog:
[Internal] - Use the right method in super and invert the order of where we search for views.
## Facebook:
See S397861 and T180527210 for more information.
Reviewed By: javache
Differential Revision: D54246220
fbshipit-source-id: 1c7503ad3e80cf50ecc016a984ca180a19b73cc0
Summary:
We might want to publish some new versions of React Native with experimental feature to allow some partners to test whether those versions fixes some reported issues, before creating a proper stable version for the whole ecosystem.
The infra is mostly [setup for this](https://www.internalfb.com/code/fbsource/[496a64d180faab501b8598aa0ec26d47454fb961]/xplat/js/react-native-github/scripts/releases/utils/version-utils.js?lines=149), already. The only detail we need to take care of is not to move the `next` tag.
[Internal]
Reviewed By: cortinico, huntie
Differential Revision: D56578456
fbshipit-source-id: 8dcc674aab5f85077c1b3e6580c5aeb99226eff8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44188
The current approach used for `batchRenderingUpdatesInEventLoop` is not compatible with Android due to limitations in its props processing model. The raw props changeset is passed through to Android, and must be available for the Android mounting layer to correctly apply changes.
We have some logic to merge these payloads when multiple ShadowNode clones take place but were previously assuming that a ShadowTree commit was a safe state to synchronize.
In the current implementation this means that two commits driven from layout effects (triggering states A → B → C) may cause Android to observe only the B → C props change, and miss out on any props changed in A → B.
Changelog: [Android][Fixed] Cascading renders were not mounting correctly when `batchRenderingUpdatesInEventLoop` is enabled.
Reviewed By: rubennorte
Differential Revision: D56414689
fbshipit-source-id: 7c74d81620db0f8b7bd67e640168afc795c7a1d7
Summary:
Supports the removal of Flipper from the template in 0.74, paried with additional blog post messaging: https://reactnative.dev/blog/2024/04/22/release-0.74#removal-of-flipper-react-native-plugin.
Changelog:
[General][Changed] - Update "Open Debugger" action to print extended Flipper guidance
Reviewed By: cipolleschi
Differential Revision: D56705236
fbshipit-source-id: d7e869625262ebb02bc2454c924f832cccfbcd31
Distiller
Kudo Chien
legobt
Alex Hunt
Riccardo Cipolleschi
Szymon Rybczak
Renaud Chaput
zhongwuzw
Rui Ying
Robin Shin
Alan Lee
Arushi Kesarwani
Riccardo Cipolleschi
Distiller
Nicola Corti
aleqsio
Pieter De Baets
Samuel Susla
Marc Rousavy
Distiller
Rubén Norte
Alex Hunt