Summary:
We had to disable the envinfo command on test_windows to get the CI back to green.
The reason why it started failing is because they released 7.9.0 which does not seem to have the executable on Windows, so `npx` fails to find what to run.
This fix restore the command in a way that it should display the envinfo using an older version of the package. I also added a task to come back to this periodically.
## Changelog:
[Internal] - Restore envinfo on windows
Pull Request resolved: https://github.com/facebook/react-native/pull/38062
Test Plan: - CircleCI: test_windows stays green
Reviewed By: cortinico
Differential Revision: D47016995
Pulled By: cipolleschi
fbshipit-source-id: 368367caed7ea49d7419475580a39f9406c54757
# Conflicts:
# .circleci/config.yml
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38223
Before this change, the InteropLayer was adding the view to the registry right before invoking a command and right after the command was invoked. This model was too strict as some view commands may have async behaviors that make the lookup in the registry fail.
After this change, we are going to register the view when it's created and we are going to remove it when the view is deallocated.
## Changelog:
[iOS][Changed] - Update logic to add and remove views in the view registry for the interop layer.
Reviewed By: sammy-SC
Differential Revision: D47262664
fbshipit-source-id: 503f4e29e03bfc7ad861c1502129822b383ffcc0
Summary:
Fixes a regression added [on merge of https://github.com/facebook/react-native/issues/37531](https://github.com/facebook/react-native/commit/260bcf7f1bf78022872eb2f40f33fb552a414809#diff-16a358d6a9dea8469bfdb899d0990df1c32b8c3b1149c86685bec81f50bd24beR179) (though oddly I don't see it in [https://github.com/facebook/react-native/issues/37531's diff](https://github.com/facebook/react-native/pull/37531/files#diff-16a358d6a9dea8469bfdb899d0990df1c32b8c3b1149c86685bec81f50bd24beR179), so perhaps added during conflict resolution?) where multiple arguments in `$EXTRA_COMPILER_ARGS` are now incorrectly wrapped in quotes, including RN's own sourcemap support:
```
runner@SeansMacBookGo sampleapp % /Users/runner/builds/y_x6gsp4/0/sampleapp/ios/Pods/hermes-engine/destroot/bin/hermesc -emit-binary -max-diagnostic-width=80 '-O -output-source-map' -out /Users/runner/builds/y_x6gsp4/0/sampleapp/ios/build/derived-data/Build/Intermediates.noindex/ArchiveIntermediates/sampleapp/BuildProductsPath/Release-iphoneos/sampleapp.app/main.jsbundle /Users/runner/builds/y_x6gsp4/0/sampleapp/ios/build/derived-data/Build/Intermediates.noindex/ArchiveIntermediates/sampleapp/BuildProductsPath/Release-iphoneos/main.jsbundle
hermesc: Unknown command line argument '-O -output-source-map'. Try: '/Users/runner/builds/y_x6gsp4/0/sampleapp/ios/Pods/hermes-engine/destroot/bin/hermesc -help'
hermesc: Did you mean '-output-source-map'?
```
## 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] - Fix build error when there are multiple EXTRA_COMPILER_ARGS
Pull Request resolved: https://github.com/facebook/react-native/pull/38147
Test Plan: Removing the quotes and running the command results a successful run of `hermesc` (exit code 0 and the expected files produced).
Reviewed By: rshest
Differential Revision: D47254412
Pulled By: cipolleschi
fbshipit-source-id: 96b71bb05c7a6939088816e76a9a2d02e89ed768
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38212
This mirrors the same logic that the Hermes team has on facebook/hermes.
Practically, we want to pass the CMake config flag `HERMES_ENABLE_DEBUGGER=False` only for Release
so that their CMake build is configured correctly.
Their build always enables the Debugger and allows us to selectively turn it off only for release
builds.
More context: https://github.com/facebook/hermes/commit/eabf5fcd25
Changelog:
[Internal] [Changed] - Compile hermes-engine with -DHERMES_ENABLE_DEBUGGER=False on Release
Reviewed By: cipolleschi
Differential Revision: D47252735
fbshipit-source-id: 9b5cd801dea3b540a3f80b0d0975e05984f1d9b9
Summary:
Fix build failure on iOS with pnpm and use_frameworks! due to cocoapods copying symlinked headers to wrong paths
When using pnpm all packages are symlinked to node_modules/.pnpm to prevent phantom dependency resolution. This causes react-native iOS build to fail because Cocoapods copies headers to incorrect destinations when they're behind symlinks. The fix resolves absolute paths to the header_mappings_dir at pod install time. With absolute paths cocoapods copies the headers correctly.
This commit also adds a few missing header search paths in use_frameworks! mode.
Fixes https://github.com/facebook/react-native/issues/38140
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - Build failure with pnpm and use_frameworks! due to incorrect header paths
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/38158
Test Plan:
1. `pnpm pnpx react-native@latest init AwesomeProject`
2. `cd AwesomeProject`
3. `rm -rf node_modules yarn.lock`
4. `mkdir patches`
5. copy [react-native@0.72.1.patch](https://github.com/facebook/react-native/files/11937570/react-native%400.72.1.patch) to `patches/`
6. Add patch to package.json
```
"pnpm": {
"patchedDependencies": {
"react-native@0.72.1": "patches/react-native@0.72.1.patch"
}
}
```
7. `pnpm install`
8. `cd ios`
9. `NO_FLIPPER=1 USE_FRAMEWORKS=static pod install`
10. `cd ..`
11. `pnpm react-native run-ios`
Hopefully an automated test of building with `pnpm` can be added to CI. I don't know how to make that happen, hopefully someone at facebook can do it.
Reviewed By: dmytrorykun
Differential Revision: D47211946
Pulled By: cipolleschi
fbshipit-source-id: 87640bd3f32f023c43291213b5291a7b990d7e1f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38205
Enable the preprocessor flag to allow debugging when in a debug build. This flag influences the Hermes headers included in the inspector, and causes them to include the debugging functionality.
Changelog:
[General][Fixed] - Re-enabled debugging for debug builds
Reviewed By: lunaleaps, cortinico
Differential Revision: D47243235
fbshipit-source-id: 7982c69ab554335a9ad985394e4416ed69831137
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38129
changelog: [iOS] Disable NSTextStorage caching in OSS
A [bug was reported](https://github.com/facebook/react-native/issues/37944) for NSTextStorage caching. Even thought I fixed the bug in D47019250, I want to disable the feature in OSS until the fix is verified in Facebook app.
My plan is to pick this commit for 0.72.1 and reenable NSTextStorage caching once the fix is validated.
Reviewed By: NickGerleman
Differential Revision: D47127912
fbshipit-source-id: 97694e383eb751e89b776c0599969f2c411bac6f
Summary:
This fixes a bug that started with React Native 0.72.0 when using the new architecture and installing a native lib that has Swift code (in my case, `datadog/mobile-react-native`).
Running `pod install` errors with the following output (`DatadogSDKReactNative` is the pod containing the Swift code):
```
[...]
Analyzing dependencies
Downloading dependencies
Installing DatadogSDKReactNative 1.8.0-rc0
[!] The following Swift pods cannot yet be integrated as static libraries:
The Swift pod `DatadogSDKReactNative` depends upon `React-Fabric`, `React-graphics`, `React-utils`, and `React-debug`, which do 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.
```
Indeed, this pods were added as dependencies in `packages/react-native/scripts/cocoapods/new_architecture.rb` but do not define modules contrary to the other pods in the list.
This PR is solving a problem that already occured in the past and was solved here: https://github.com/facebook/react-native/pull/33743
It's a new implementation for the PR initially opened here: https://github.com/facebook/react-native/pull/38039
## Changelog:
[IOS] [FIXED] - Fix pod install for libraries using Swift code when the new architecture is enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/38121
Test Plan:
1. Clone [this](https://github.com/louiszawadzki/react-native) repo
2. From `main`, add a Swift file to the `MyNativeView` native module in the RN tester app (see inspiration from [this commit](https://github.com/fortmarek/react-native/commit/26958fccf4b4ac90d0bf9bb3699f12760a6b2b58))
3. Try to run `RCT_NEW_ARCH_ENABLED=1 USE_HERMES=0 bundle exec pod install` inside the `packages/rn-tester`
4. Observe errors
5. Apply [the commit](https://github.com/facebook/react-native/commit/7b7c3ff530cae07daccc5b5ea6b72d239f913be0) from this PR
6. Both pod install and the subsequent build should succeed.
7. Revert the changes and repeat steps 2 to 6 with `RCT_NEW_ARCH_ENABLED=1 USE_HERMES=1 bundle exec pod install`
Reviewed By: cortinico
Differential Revision: D47127854
Pulled By: cipolleschi
fbshipit-source-id: bf7f65e0d126195a76a0fafbe2f3172f00d5adc1
# Conflicts:
# packages/react-native/ReactCommon/react/renderer/debug/React-rendererdebug.podspec
Summary:
We've been encountering a crash in `runAnimationStep` with "Calculated frame index should never be lower than 0" https://github.com/facebook/react-native/issues/35766 with OnePlus/Oppo devices as well, but don't have one on hand to test.
This just works around the issue: if the time is before the start time of an animation, we shouldn't do anything anyways, so we just log a message instead of throwing while in production. We still throw in debug mode though for easier debugging.
### Hypothesis of the root cause
Based on stacktrace in https://github.com/facebook/react-native/issues/35766 (which is the same one we see)
Normally, this should happen
1. Choreographer.java constructs a FrameDisplayEventReceiver
2. FrameDisplayEventReceiver.onVSync gets called, which sets the `mTimestampNanos`
3. FrameDisplayEventReceiver.run gets called, which then eventually calls our `doFrame` callback with `mTimestampNanos`. This then causes `FrameBasedAnimationDriver.runAnimationStep` to be called with the same timestamp
I suspect what's happening on OnePlus devices is that the `onVSync` call either doesn't happen or happens rarely enough that the `mTimestampNanos` when `run` is called is sometime in the past
### Fix
1. Add logging so we get the parameters to debug more if we end up getting this error
2. In production, just ignore past times instead of throwing an Error
## Changelog:
Pick one each for the category and type tags:
[ANDROID] [FIXED] - Prevent crash on OnePlus/Oppo devices in runAnimationStep
Pull Request resolved: https://github.com/facebook/react-native/pull/37487
Test Plan: Ran our app using patched version and verified no issues showed up when using it
Reviewed By: cipolleschi
Differential Revision: D46102968
Pulled By: cortinico
fbshipit-source-id: bcb36a0c2aed0afdb8e7e68b141a3db4eb02695a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38089
This change add a warning if a component is registered in both the New Renderer and in the Interop layer.
This can help users migrating their components once the library has been migrated.
[iOS][Added] - Add warning to help users migrate away from the interop layer.
Reviewed By: cortinico
Differential Revision: D47053556
fbshipit-source-id: cc2ba09db16aaa370947a77173b6ea6a0acfa519
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38093
In [this issue](https://github.com/facebook/react-native/issues/37905), the community detected a strict assumption in the interop layer for which, given a component `XXXView`, its ViewManager must be called `RCTXXXViewManager`.
That's not the case for some components, for example, `BVLinearGradient`, which View manager is `BVLinearGradientManager` and not `RCTBVLinearGradientManager`.
This diff adds a secondary lookup logic:
1. We look for the `RCTXXXViewManager`.
2. If not found, we look for `XXXViewManager`.
We will assess whether to generalize this logic once and for all or to expand other lookup cases on an example/failure basis as it's not a goal to have a 100% accurate interop layer. The Goal is to cover most use cases.
[iOS][Added] - Allow to lookup for ViewManager without the RCT prefix in the Interop Layer
Reviewed By: sammy-SC
Differential Revision: D47055969
fbshipit-source-id: 1d31f3f4bc6f1f543edbd157ce04ad9daf23dbc6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38075
changelog: [internal]
`SharedFunction<>` is created with nullptr for its internal `std::function`. If called after created with default constructor, it crashes app. It also does not have API to check if its internal function is not nullptr.
With image cancelation, there is a race between when native component calls `imageRequest.cancel()` and when cancelation function is set in `RCTImageManager`.
To fix this, this diff adds a nullptr check inside SharedFunction. So it is always safe to call.
Reviewed By: javache
Differential Revision: D47022957
fbshipit-source-id: 0a04a87cd1ffe6bf3ca2fded38f689f06cc92ca9
Summary:
Installing `react-native` 0.72.x causes a warning about `react-test-renderer` because `react-native/virtualized-lists` has declared a peer dependency on it. As far as I know, it is not used for anything but tests.
```
➤ YN0002: │ react-native@npm:0.72.0-rc.6 [292eb] doesn't provide react-test-renderer (p5a2fb), requested by react-native/virtualized-lists
```
Note that while many package managers default to warnings in this case, there are still a number of users out there for which this is an error.
## Changelog:
[GENERAL] [FIXED] - `react-native/virtualized-lists` does not need `react-test-renderer` at runtime
Pull Request resolved: https://github.com/facebook/react-native/pull/37955
Test Plan: n/a
Reviewed By: rshest
Differential Revision: D46871536
Pulled By: NickGerleman
fbshipit-source-id: 1e5e15608ab394bc43cd4e6ac727a74734874642
Summary:
[skip-ci]
I noticed that; when a _new_ RN App is created using RN CLI there is ***NO*** *README* file added to the project.
Having a simple README file explaining what type of project it is, for example how other web projects do it, such as long lived `create-react-app`, now widely used `create-next-app`, etc.
Why not for React Native App then?
This PR; Adds README file to RN Template App ⚡, which should be added to the project when a new project is created using RN CLI.
### Website PR: https://github.com/facebook/react-native-website/pull/3732🚀😇
bypass-github-export-checks
## Changelog:
[INTERNAL] [ADDED] - Add README to RN Template App ⚡
Pull Request resolved: https://github.com/facebook/react-native/pull/37521
Test Plan: - The README file should be included in the newly created RN App using RN CLI
Reviewed By: NickGerleman
Differential Revision: D46075719
Pulled By: cipolleschi
fbshipit-source-id: efcccc09d72c57a065b36de6e787594082000e15
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37832
This parameter is currently unused and is causing Android builds to fail
as they compile with `-Wall`
This is a follow-up to https://github.com/facebook/react-native/pull/37454/ as that PR updated only the `fromJs` and not the `toJs` method as well.
Changelog:
[Internal] [Changed] - Remove CallInvoker parameter from toJs method in Codegen
Reviewed By: rshest
Differential Revision: D46647110
fbshipit-source-id: 1f3e22aca7a3df11ac02b5c4b89c9311b8b1798c
Summary:
When trying to build an app using 0.72.0-RC.5 inside a project that uses `.xcode.env.local` the `[CP-User] Generate Legacy Components Interop` Phase script fails to run due to a `Permission denied` error. That's because `.xcode.env.local` is not being loaded, resulting in `NODE_BINARY=" "` and then the `React-RCTAppDelegate` script tries to run `generate-legacy-interop-components.js` directly.
E.g
In order to fix this we should run the `with-environment.sh` script instead of directly loading `.${PODS_ROOT}/../.xcode.env`
## Changelog:
[IOS] [FIXED] - Fix loading `NODE_BINARY` inside Generate Legacy Components Interop
Pull Request resolved: https://github.com/facebook/react-native/pull/37802
Test Plan: Make sure you don't have a `.xcode.env` file and run locally a project that uses React-RCTAppDelegate
Reviewed By: cortinico
Differential Revision: D46596246
Pulled By: cipolleschi
fbshipit-source-id: 5616395f39b0fae7b2fa9e59bd72c70f39198b4d
Summary:
Attempting to fix the issue https://github.com/facebook/react-native/issues/33418
## 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
-->
[ANDROID] Fixed inconsistent styling for text nodes with many children
Pull Request resolved: https://github.com/facebook/react-native/pull/36656
Test Plan:
No test plan yet. I'd like to ask for help with creating one.
##
Putting template aside, I'd like to ask for a review of the approach I'm suggesting.
React Native as-is (at least in some cases) [messes up the styles](https://github.com/facebook/react-native/issues/33418#issuecomment-1485305556) for text nodes with more than 85 children, just like that.
All of this text should be blue.
The root cause is that code (on Android) assumes it can assign as many `Spannable` span priority values as we'd like, while in reality, it has to be packed in an 8-bit-long section of the flags mask. So 255 possible values. In the scenario I produced, React generates three spans per text node, and for 85 text nodes, it sums up to 255. For each span, a new priority value is assigned.
As I understand it, we don't need that many priority values. If I'm not mistaken, these priorities are crucial only for ensuring that nested styles have precedence over the outer ones. I'm proposing to calculate the priority value "vertically" (based on the node's depth in the tree) not "horizontally" (based on its position).
It would be awesome if some core engineer familiar with `ReactAndroid` shared their experience with this module, especially if there are any known cases when we _know_ that we'd like to create overlapping spans fighting over the same aspects of the style.
Reviewed By: cortinico
Differential Revision: D46094200
Pulled By: NickGerleman
fbshipit-source-id: aae195c71684fe50469a1ee1bd30625cbfc3622f
Summary:
Currently when using a TextInput with a controlled selection prop the Copy / Paste menu is constantly getting dismissed and is impossible to use. This is because Android dismisses it when certain method that affect the input text are called (https://cs.android.com/android/platform/superproject/+/refs/heads/master:frameworks/base/core/java/android/widget/Editor.java;l=1667;drc=7346c436e5a11ce08f6a80dcfeb8ef941ca30176?q=Editor, https://cs.android.com/android/platform/superproject/+/refs/heads/master:frameworks/base/core/java/android/widget/TextView.java;l=6792;drc=7346c436e5a11ce08f6a80dcfeb8ef941ca30176). The solution to fix this is to avoid calling those methods when only the selection changes.
I also noticed there are a lot of differences on how selection is handled in old vs new arch and a lot of the selection handling can actually be removed as it is partially the cause of this issue.
This implements 2 mitigations to avoid the issue:
- Unify selection handling via commands for old arch, like fabric. Selection is currently a prop in the native component, but it is completely ignored in fabric and selection is set using commands. I removed the selection prop from the native component on Android so now it is exclusively handled with commands like it is currently for fabric. This makes it so that when the selection prop changes the native component no longer re-renders which helps mitigate this issue. More specifically for the old arch we no longer handle the `selection` prop in `ReactTextInputShadowNode`, which used to invalidate the shadow node and cause the text to be replaced and the copy / paste menu to close.
- Only set placeholder if the text value changed. Calling `EditText.setHint` also causes the copy / paste menu to be dismissed. Fabric will call all props handlers when a single prop changed, so if the `selection` prop changed the `placeholder` prop handler would be called too. To fix this we can check that the value changed before calling `setHint`.
## Changelog:
[ANDROID] [FIXED] - Fix copy / paste menu and simplify controlled text selection on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/37424
Test Plan:
Tested on new and old arch in RNTester example.
Before:
https://github.com/facebook/react-native/assets/2677334/a915b62a-dd79-4adb-9d95-2317780431cf
After:
https://github.com/facebook/react-native/assets/2677334/0dd475ed-8981-410c-8908-f00998dcc425
Reviewed By: cortinico
Differential Revision: D45958425
Pulled By: NickGerleman
fbshipit-source-id: 7b90c1270274f6621303efa60b5398b1a49276ca
# Conflicts:
# packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactTextInputShadowNode.java
Distiller
Lorenzo Sciandra
Riccardo Cipolleschi
Riccardo Cipolleschi
Kudo Chien
fergusean
Nicola Corti
evelant
Matt Blagden
Koichi Nagaoka
Samuel Susla
louiszawadzki
Alex Hunt
Adrian Hartanto
Harry Yu
Luna
Distiller
Bernhard Owen Josephus
Tommy Nguyen
Pranav Yadav
Distiller
Distiller
Gabriel Donadel
Alexander Eggers
Jakub Trzebiatowski
Janic Duplessis
Distiller
