Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39525
Switches `EventEmitter#emit` to use `Array.from` instead of the spread operator.
This should be functionally identical (with marginally less overhead of the runtime having to determine the type of `registrations`), but there seems to be [some unexpected Babel configurations in the community](https://github.com/facebook/react-native/issues/35577#issuecomment-1723218934) that causes this line of code to do the wrong things.
Although we should independently root cause the Babel plugin configuration problems, this change might provide immediate relief and is also not any worse (e.g. in terms of code readability). This also adds a descriptive comment explaining the intention of the call to `Array.from`.
Changelog:
[Fixed][General] - Fix a potential bug in `EventEmitter` when used with certain Babel configurations that incorrectly polyfill the spread operator for iterables.
Reviewed By: javache
Differential Revision: D49389813
fbshipit-source-id: 7caf63734fc047496afe2f1ed6d918c22747258a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39828
Active Suppert released a new Gem which is incompatible with Cocoapods 1.13.0, the latest release, as they removed a method used by cocoapods.
This fix ensures that we install compatible versions of the Gem.
## Changelog:
[iOS][Fixed] - Set the max version of Active support to 7.0.8
Reviewed By: hoxyq
Differential Revision: D49949782
fbshipit-source-id: 278097502d3a416567cc8c0b90090fee4fb21503
# Conflicts:
# Gemfile
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39710
Last week Apple released Xcode 15, which required us to ship a workaround for the new linker.
Unfortunately, the previous fix was not good enough and there were some edge cases that were not covered.
For example, in some occasions the flags are read as an array and the `-Wl` and the `-ld_classic` flags were separated and not properly removed when moving from Xcode 15 to Xcpde 14.3.1.
This change fixes those edge cases, with a more robust solution where:
- We convert the flags to a string.
- We trim the string and the values properly.
- We add the flags when running `pod install` with Xcode 15 as the default iOS toolchain.
- We remove the flags when running `pod install` with Xcode <15 as the default iOS toolchain.
## Changelog:
[Internal] - Make the Xcode 15 workaround more robust.
Reviewed By: dmytrorykun
Differential Revision: D49748844
fbshipit-source-id: 34976d148f123c5aacba6487a500874bb938fe99
# Conflicts:
# packages/react-native/scripts/cocoapods/__tests__/utils-test.rb
# packages/react-native/scripts/cocoapods/utils.rb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39516
With Xcode15, Apple rewrote the C++ linker.
This is a breaking change that does not work with weak symbols.
As a workaround, apple is suggesting to add `-ld_classic` to the linker in order to readd support for weak symbols. The flag does not exists for Xcode 14.3 or lower, so we need to add it conditionally.
With this change, we introduce a couple of checks in the Hermes build logic:
1. Detect the version of Xcode that is used
2. Add the new flag to `HERMES_EXTRA_LINKER_FLAGS` if Xcode version is 15.
[Internal] - Make hermes build properly with Xcode 15
Reviewed By: cortinico, dmytrorykun
Differential Revision: D49368675
fbshipit-source-id: 62d8ed81855c426f56ed94b6a2d6da2eb882b355
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39474
When it comes to Xcode 15 RC, we are aware of two issues:
1. `unary_function` and `binary_function` not available in Cxx17
2. [Weak linking](https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes#Linking) is not supported anymore.
This change should fix both of the issues, adding the flags to allow for `unary_function`and `binary_function` to be called and adding the `-Wl -ld_classic` flag to `OTHER_LDFLAGS` in case Xcode 15 is detected.
[Internal] - add the `_LIBCPP_ENABLE_CXX17_REMOVED_UNARY_BINARY_FUNCTION` and the `-Wl -ld_classic` flags to projects when needed
Reviewed By: dmytrorykun
Differential Revision: D49319256
fbshipit-source-id: bb895f1e60db915db79684f71fa436ce80b42111
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39478
When testing Xcode 15, we realized that a few pods we do not control directly have the IPHONEOS_DEPLOYMENT_TARGET set to old versions of iOS.
We can update that setting to silence the warning with Cocoapods and this is what this script does.
Notice that bumping that setting generated other warning as some APIs have been deprecated.
[Internal] - Bump min IPHONEOS_DEPLOYMENT_TARGET for 3rd party pods
Reviewed By: dmytrorykun
Differential Revision: D49274837
fbshipit-source-id: 584d105c76d654daa2ecf5eb2f1b9381e70f567a
Summary:
See: http://blog.nparashuram.com/2019/10/debugging-react-native-ios-apps-with.html
When using direct debugging with JavaScriptCore, Safari Web Inspector doesn't pick up the source map over the network. Instead, as far as I can tell, it expects you to pass the source URL at the time you load your bundle: https://developer.apple.com/documentation/javascriptcore/jscontext/1451384-evaluatescript?language=objc . This leads to a very sub-par developer experience debugging the JSbundle directly. It will however, pick up an inline source map. Therefore, let's add a way to have React Native tell metro to request an inline source map.
I did this by modifying `RCTBundleURLProvider` to have a new query parameter for `inlineSourceMap`, and set to true by default for JSC.
[IOS] [ADDED] - Added support to inline the source map via RCTBundleURLProvider
Pull Request resolved: https://github.com/facebook/react-native/pull/37878
Test Plan:
I can put a breakpoint in RNTester, via Safari Web Inspector, in human readable code :D
<img width="1728" alt="Screenshot 2023-06-14 at 4 09 03 AM" src="https://github.com/facebook/react-native/assets/6722175/055277fa-d887-4566-9dc6-3ea07a1a60b0">
Reviewed By: motiz88
Differential Revision: D46855418
Pulled By: huntie
fbshipit-source-id: 2134cdbcd0a3e81052d26ed75f83601ae4ddecfe
Summary:
Currently Android fails to build on Windows, because CMake cannot work with
native Windows paths that are passed to it as build arguments. This change
converts the input paths to the CMake format.
## Changelog:
[Android] [Fixed] - Fix building Android on Windows.
Pull Request resolved: https://github.com/facebook/react-native/pull/39190
Test Plan: Build the React Native Android project on Windows. It should complete successfully.
Reviewed By: NickGerleman
Differential Revision: D48948140
Pulled By: cortinico
fbshipit-source-id: 6d584c2a10e683cdb6df0dd6dcd5875da7e06e2b
Summary:
This partially reverts commit 58adc5e4b9.
Using an absolute path in a podspec is wrong, and causes checksum issues when installs are ran on different systems.
Example:
`pod install --deployment --clean-install` breaks on non-matching checksums on CI because the absolute path is not the same in that environment.
```
Adding spec repo `trunk` with CDN `https://cdn.cocoapods.org/`
Verifying no changes
[!] There were changes to the lockfile in deployment mode:
SPEC CHECKSUMS:
React-debug:
New Lockfile: 419922cde6c58cd5b9d43e4a09805146a7dd13a8
Old Lockfile: 1ce329843d8f9a9cbe0cdd9de264b20e89586734
React-NativeModulesApple:
New Lockfile: a683b0c999e76b7d15ad9d5eaf8b6308e710a93e
Old Lockfile: f82356d67a137295d098a98a03be5ee35871b5a5
React-runtimescheduler:
New Lockfile: 79f8dff11acbe36aaeece63553680d7a8272af96
Old Lockfile: 16c5282d43a0df50d7c68ebf0218aeeb642a7086
React-utils:
New Lockfile: 4fabb3cba786651e35bc41e610b0698fa24cecff
Old Lockfile: e7e9118d0e85b107bb06d1a5f72ec5db6bddb911
ReactCommon:
New Lockfile: af30fb021799e18c85a8e30ce799e15607e82212
Old Lockfile: f04f86f33c22e05dbf875789ea522ee486dace78
```
And even tho the change fixed an issue with pnpm, the issue it introduces with cocoapods I think is a bigger one.
## Changelog:
[INTERNAL] - Revert commit that makes podfile unstable
Pull Request resolved: https://github.com/facebook/react-native/pull/39177
Test Plan: Tested locally that the hashes are stable
Reviewed By: NickGerleman
Differential Revision: D48773887
Pulled By: cipolleschi
fbshipit-source-id: 96bcdbadc17a24fa9a8669f569d004bee6a03521
Summary:
Android builds with new arch fail on Windows build host (https://github.com/facebook/react-native/issues/36475). This tiny correction fixes generation of `schema.json` (without it codegen failed to find any files, and generated empty schema). Unfortunately, does not fixes the issue with Windows host entirely, as builds still fail later (on ninja build step).
## Changelog:
[Android] [Fixed] - A bug fix for Android builds with new arch on Windows host.
Pull Request resolved: https://github.com/facebook/react-native/pull/36542
Reviewed By: NickGerleman
Differential Revision: D48563587
Pulled By: cortinico
fbshipit-source-id: acd510308ce9768fb17d3a33c7927de3237748ac
Summary:
An earlier [change](https://github.com/facebook/react-native/commit/8b1bf058c4bcbf4e5ca45b0056217266a1ed870c) I made (that huntie resubmitted) only works on Xcode 14.3+ (See more info [here](https://github.com/react-native-community/discussions-and-proposals/discussions/687)). This change adds the appropriate compiler checks so that the change is compatible with Xcode 14.2 and earlier, and therefore cherry-pickable to 0.71 and 0.72.
The check works by checking if iOS 16.4+ is defined, which is the closest proxy I could find for "Is this Xcode 14.3".
## Changelog:
[IOS] [CHANGED] - Guard `JSGlobalContextSetInspectable` behind a compile time check for Xcode 14.3+
Pull Request resolved: https://github.com/facebook/react-native/pull/39037
Test Plan: I can't actually test on Xcode 14.2 (it won't launch on my MacBook 😢), but I made a similar [PR](https://github.com/microsoft/react-native-macos/pull/1848) in React Native macOS, whose CI checks run against Xcode 14.2 and I'm getting passing checks there.
Reviewed By: huntie
Differential Revision: D48414196
Pulled By: NickGerleman
fbshipit-source-id: ba10a6505dd11d982cc56c02bf9f7dcdc104bbec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39008
Changelog: [Internal] - Adjust RawPropsPropNameLength's type to account for increased number of props
While investigating why we needed to back out D48288752 I discovered that the root cause was that the `items_` vector in `RawProsKeyMap` was now a size greater than 255 which becomes an issue because `items_`'s indices are statically cast to `RawPropsPropNameLength` (previously alias to `uint8_t`).
This diff updates `RawPropsPropNameLength` to be an alias to `uint16_t` so the current issue is resolved as well as adding an assert to ensure (however unlikely) that this happens again.
Reviewed By: rozele
Differential Revision: D48331909
fbshipit-source-id: f6bc3e4825f2f293d79d8cd90c40ced7cba0e3c5
Summary:
`mFirstVisibleView` is a weak ref so it can also be null when dereferencing.
This was reported on the original PR here https://github.com/facebook/react-native/pull/35049#discussion_r1288195469
## Changelog:
[ANDROID] [FIXED] - Fix null crash when using maintainVisibleContentPosition on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/38891
Test Plan: Not sure exactly in what cases this can happen, but the fix is trivial and makes sense.
Reviewed By: cortinico
Differential Revision: D48192154
Pulled By: rshest
fbshipit-source-id: 57a38a22a0e216a33603438355bde0013c014fbf
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
Distiller
Riccardo Cipolleschi
Tim Yung
Distiller
zhongwuzw
Thibault Malbranche
Alex Hunt
Saad Najmi
Ales Pergl
Koen Punt
Dr. Sergey Pogodin
Saad Najmi
Vincent Riemer
Janic Duplessis
Lorenzo Sciandra
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
Lorenzo Sciandra
Distiller