Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38857
`hitSlop` must be passed into the `usePressability` hook in order for it to take effect. It's a no-op if no hit slop is present
Changelog:
[Internal][Fixed] - Propagate hit slop prop to TextInput pressability config
Reviewed By: NickGerleman
Differential Revision: D48124538
fbshipit-source-id: a910fdcec55e67d37c84facca297428556ef777e
Summary:
Hello! This PR is a fix for one merged some time ago (https://github.com/facebook/react-native/pull/36216). In the PR check for `nullptr` value of `newRootShadowNode` just after performing commit hooks was overlooked. This PR restores previous behaviour of conditional commit cancellation after commit hook execution.
## Changelog:
[INTERNAL] [FIXED] - Restore checking shadow tree commit cancellation after commit hook execution
Pull Request resolved: https://github.com/facebook/react-native/pull/38715
Test Plan: Just register a commit hook that return `nullptr`. In that case current code crashes due to `nullptr` dereference.
Reviewed By: sammy-SC
Differential Revision: D47972245
Pulled By: ryancat
fbshipit-source-id: 7599ad11ed4b2dcaf25e53f676ec4530e37410d5
Summary:
This PR aims to fix an issue where installing iOS pods from a different directory causes the `hermes-engine` `:tag:` not to be properly resolved.
Ever since https://github.com/facebook/react-native/issues/37148 was merged, the `setup_hermes` script tries to resolve the `node_modules/react-native/sdks/.hermesversion` file and use its content to generate the pod tag, in order to verify when it changes over time.
This works perfectly when installing pods within the `ios` folder, as the `react_native_path` should point to the correct relative folder (`../node_modules/react-native` by default).
However, when installing pods from a different directory (the project root, for example) and leveraging the `--project-directory` flag, the file fails to resolve, as the current working directory is considered when resolving the `.hermesversion` file.
### Quick Example:
- `react_native_path`: `../node_modules/react-native` (the default config)
**Installing pods from the `ios` folder:**
- `cd ios`
- `bundle exec pod install`
- `hermestag_file` resolved path: `$project_root/node_modules/react-native` ✅
- `hermes-engine` `:tag:`: `hermes-2023-03-20-RNv0.72.0-49794cfc7c81fb8f69fd60c3bbf85a7480cc5a77` ✅
**Installing pods from the `$project_root` folder**
- `bundle exec pod install --project-directory=ios`
- `hermestag_file` resolved path: `$parent_folder/$project_root/node_modules/react-native` ❌
- `hermes-engine` `:tag:`: `''` ❌
### The fix
Turns out that the same file had a resolved reference to the `react-native` folder, assigned to the `react_native_dir` variable:
```ruby
react_native_dir = Pod::Config.instance.installation_root.join(react_native_path)
```
By resolving the `.hermesversion` using that folder, we guarantee that the relative path will always reference the directory where the `Podfile` is defined, which is the expected behaviour.
## Changelog:
[Internal] - Fix an issue where installing pods from a different directory would fail to resolve `hermes-engine` tags correctly.
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/38754
Test Plan:
- Init a new `react-native` repo
- Remove the generated `Podfile.lock` file
- Navigate to the project root folder
- `bundle exec pod install -project-directory=ios`
- Check that the `hermes-engine` entry has a properly populated `:tag:` attribute:
**Before:**
```
hermes-engine:
:podspec: "../node_modules/react-native/sdks/hermes-engine/hermes-engine.podspec"
:tag: ''
```
**After:**
```
hermes-engine:
:podspec: "../node_modules/react-native/sdks/hermes-engine/hermes-engine.podspec"
:tag: hermes-2023-03-20-RNv0.72.0-49794cfc7c81fb8f69fd60c3bbf85a7480cc5a77
```
Reviewed By: cortinico
Differential Revision: D48029413
Pulled By: cipolleschi
fbshipit-source-id: 82d465abd5c888eeb9eacd32858fa4ecf4f8c217
Summary:
This PR is a result of this PR, which got merged but then reverted:
- https://github.com/facebook/react-native/pull/37913
We are trying to implement a workaround for https://github.com/facebook/react-native/issues/35350, so react-native users on android API 33+ can use `<FlatList inverted={true} />` without running into ANRs.
As explained in the issue, starting from android API 33 there are severe performance issues when using scaleY: -1 on a view, and its child view, which is what we are doing when inverting the ScrollView component (e.g. in FlatList).
This PR adds a workaround. The workaround is to also scale on the X-Axis which causes a different transform matrix to be created, that doesn't cause the ANR (see the issue for details).
However, when doing that the vertical scroll bar will be on the wrong side, thus we switch the position in the native code once we detect that the list is inverted, using the newly added `isInvertedVirtualizedList` prop.
This is a follow up PR to:
- https://github.com/facebook/react-native/pull/38071⚠️ **Note:** [38071](https://github.com/facebook/react-native/pull/38071) needs to be merged and shipped first! Only then we can merge this PR.
## 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] - ANR when having an inverted FlatList on android API 33+
Pull Request resolved: https://github.com/facebook/react-native/pull/38073
Test Plan:
- Check the RN tester app and see that scrollview is still working as expected
- Add the `internalAndroidApplyInvertedFix` prop as test to a scrollview and see how the scrollbar will change position.
Reviewed By: cortinico
Differential Revision: D47848063
Pulled By: NickGerleman
fbshipit-source-id: 4a6948a8b89f0b39f01b7a2d44dba740c53fabb3
Summary:
This PR is a result of this PR, which got merged but then reverted:
- https://github.com/facebook/react-native/pull/37913
We are trying to implement a workaround for https://github.com/facebook/react-native/issues/35350, so react-native users on android API 33+ can use `<FlatList inverted={true} />` without running into ANRs.
This is the native part, where we add a new internal prop named `isInvertedVirtualizedList`, which can in a follow up change be used to achieve the final fix as proposed in https://github.com/facebook/react-native/pull/37913
However as NickGerleman pointed out, its important that we first ship the native change.
## 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] [ADDED] - Native part of fixing ANR when having an inverted FlatList on android API 33+
Pull Request resolved: https://github.com/facebook/react-native/pull/38071
Test Plan:
- Check the RN tester app and see that scrollview is still working as expected
- Add the `isInvertedVirtualizedList` prop as test to a scrollview and see how the scrollbar will change position.
Reviewed By: rozele
Differential Revision: D47062200
Pulled By: NickGerleman
fbshipit-source-id: d20eebeec757d9aaeced8561f53556bbb4a492e4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38256
Add RECEIVER_EXPORTED/RECEIVER_NOT_EXPORTED flag support to DevSupportManagerBase for Android 14 change. See
https://developer.android.com/about/versions/14/behavior-changes-14#runtime-receivers-exported for details.
Without this fix, app crashes during launch because of :
```SecurityException: {package name here}: One of RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED should be specified when a receiver isn't being registered exclusively for system broadcasts```
Changelog:
[Targeting SDK 34] Added RECEIVER_EXPORTED/RECEIVER_NOT_EXPORTED flag support in DevSupportManagerBase
Reviewed By: javache
Differential Revision: D47313501
fbshipit-source-id: 12e8299559d08b4ff87b4bdabb0a29d27763c698
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
Distiller
fortmarek
Ellis Tsung
Nicola Corti
Luna
Michał Mąka
Luna Wei
Fabrizio Bertoglio
Guil Varandas
Andrea Cassani
Hanno J. Gödecke
Kun Wang
Nick Gerleman
tarunrajput
Szymon Rybczak
Ruslan Lesiutin
Riccardo Cipolleschi
Lorenzo Sciandra
Distiller
Distiller
Riccardo Cipolleschi
Kudo Chien
fergusean
evelant
Matt Blagden
Koichi Nagaoka
Samuel Susla
louiszawadzki
Alex Hunt
Adrian Hartanto
Harry Yu
Distiller