Summary:
For a very long time when a promise rejects without an attached catch we get this warning screen without a correct stack trace, only some internal calls to the RN internals.
<img src="https://github.com/facebook/react-native/assets/1634213/75aa7615-ee3e-4229-80d6-1744130de6e5" width="200" />
I created [an issue for discussion](https://github.com/react-native-community/discussions-and-proposals/discussions/718) in the react-native-community repo and we figured out it was only a matter of symbolication. While it cannot be done on release without external packages and source maps, at least while developing we can provide a symbolicated stack-trace so developers can better debug the source of rejected promise.
I got the stack trace symbolicated and the correct code frame. I'm missing some help trying to display it in the warning view but at the very least I can now correctly show the line of the error and log the codeframe to the console.
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[GENERAL] [FIXED] - Show correct stack frame on unhandled promise rejections on development mode.
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/40914
Test Plan:
I simply created a throwing function on a dummy app, and checked the output of the console and the warning view:
```ts
import React from 'react';
import {SafeAreaView, Text} from 'react-native';
async function throwme() {
throw new Error('UNHANDLED');
}
function App(): JSX.Element {
throwme();
return (
<SafeAreaView>
<Text>Throw test</Text>
</SafeAreaView>
);
}
export default App;
```
Here is the output
<img src="https://github.com/facebook/react-native/assets/1634213/2c100e4d-618e-4143-8d64-4095e8370f4f" width="200" />
Edit: I got the warning window working properly:
<img src="https://github.com/facebook/react-native/assets/1634213/f02a2568-da3e-4daa-8132-e05cbe591737" width="200" />
Reviewed By: yungsters
Differential Revision: D50324344
Pulled By: javache
fbshipit-source-id: 66850312d444cf1ae5333b493222ae0868d47056
Co-authored-by: Oscar Franco <ospfranco@gmail.com>
* Fix RNTestProject testing on Android (#41172)
Summary:
While releasing RN 0.73.0-RC3, we relaized that the e2e test script was bugged for Android when used to test RNTestProject with the `-c` option.
There were 2 problems:
- The downloaded maven-local was not actually used because it doesn't work with a zip. (We were always downloading a version from Maven)
- The versions of React Native between maven-local and the locally packaged React Native were different.
This change fixes the script by:
- Downloading maven-local
- Unzipping maven-local and passing the new folder to the Android app
- Downloading the React Native version that has been packaged in CI
By unzipping maven-local and using the unzipped folder, we make sure that Android is actually using the local repository.
By downloading both the packaged react native and the maven-local from the same CI workflow, we ensure that the versions are aligned.
This also speeds-up further the Android testing.
While running this change, we also moved the `pod install` step inside the `if (iOS)` branch, so we do not install Cocoapods if we need to test
Android.
[Internal] - Fix Android E2E test script when downloading artefacts from CI
Pull Request resolved: https://github.com/facebook/react-native/pull/41172
Test Plan: Tested locally on both main and 0.73-stable, on both Android and iOS
Reviewed By: cortinico
Differential Revision: D50651448
Pulled By: cipolleschi
fbshipit-source-id: 70a9ed19072119d19c5388e8a4309d7333a08e13
* Backport e2e script changes to main (#41332)
Summary:
Last week, I modified the e2e script to make sure it was working properly with 0.73.
This change backport those changes in main
## Changelog:
[Internal] - Backport e2e script changes
Pull Request resolved: https://github.com/facebook/react-native/pull/41332
Test Plan: Tested locally
Reviewed By: dmytrorykun
Differential Revision: D51025796
Pulled By: cipolleschi
fbshipit-source-id: 89ecd3701eaac4ba4bdde2c640df45a158329158
* Use old REACT_NATIVE_MAVEN_LOCAL_REPO env var
* prettier
---------
Co-authored-by: Riccardo Cipolleschi <riccardo.cipolleschi@gmail.com>
Co-authored-by: Riccardo Cipolleschi <cipolleschi@meta.com>
* Make the interop-layer work with components with custom name (#41207)
Summary:
This should fix
https://github.com/facebook/react-native/issues/37905#issuecomment-1774851214
When working on react-native-fast-image, we realized that the interop layer does not work for components where the exported name is different from the iOS class.
To fix this, we can use the Bridge to retrieve the actual view manager, given the component name.
This solution should be much more robust than making assumptions on the ViewManager name, given the ComponentName.
On top of that, we realized tha the interop layer was not calling `didSetProps` after setting the props, so we are invoking that.
bypass-github-export-checks
[iOS][Fixed] - Add support for Components with custom names in the interop layer.
Pull Request resolved: https://github.com/facebook/react-native/pull/41207
Test Plan: Tested locally on an app created in 0.72 and 0.73 in Bridge and Bridgeless mode.
Reviewed By: cortinico
Differential Revision: D50698172
Pulled By: cipolleschi
fbshipit-source-id: 49aee905418515b0204febbbe6a67c0114f37029
* Remove references to RCTBridgeProxy
---------
Co-authored-by: Riccardo Cipolleschi <riccardo.cipolleschi@gmail.com>
Co-authored-by: Riccardo Cipolleschi <cipolleschi@meta.com>
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41009
This change should fix [#39971](https://github.com/facebook/react-native/issues/39971), computing the relative path from the App path to the pod installation root and using that instead of the absolute path to the `react-native.config.js` file
## Changelog
[Internal] - Stabilize RCTAppDelegate podspec
Reviewed By: cortinico
Differential Revision: D50323710
fbshipit-source-id: e29e62228d08c752e822d7a9ab5b1a2b5dcd6eb4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36645
This broke while changing the AnimatedInterpolation back in D40571873 and D40632443, as I assumed the native side would be able to correctly handle values such as '1rad'. However these were being sent over as strings, and were thus using the string interpolation path, which does not work here.
Instead, handle both `deg` and `rad` explicitly when generating the config in JS.
Resolves issue https://github.com/facebook/react-native/issues/36608
Changelog: [General][Fixed] Resolves Animated.Value.interpolate results in NaN when output is in radians
Reviewed By: yungsters
Differential Revision: D44406034
fbshipit-source-id: fe0f3df16f2b8ec6c31f9359e4706cacc72b9951
Summary:
The Loading.../Refreshing... indicator is currently broken on Android.
The reason is related to D42599220
We used to have a Toast shown to users on Android as a fallback, but as the
DevLoadingView is not always loaded as a module in the core package, this ends up in the banner never beign shown to the user (on RN Tester or template apps).
Changelog:
[Android] [Fixed] - Fix broken Loading/Refreshing indicator on Android
Reviewed By: cipolleschi
Differential Revision: D49876757
fbshipit-source-id: 400e002327ebca908e3e7a7f81c5066888ac4e9b
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
Distiller
Marek Fořt
Riccardo Cipolleschi
Ivan Alexandrov
Pieter De Baets
Szymon Rybczak
Nicola Corti
Alex Hunt
Distiller
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
Ellis Tsung
Luna
Michał Mąka
Luna Wei
Fabrizio Bertoglio
Guil Varandas
Andrea Cassani