Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41028
This removes misleading `const` modifiers from some methods in `RuntimeScheduler` that shouldn't really use it, and removes the `mutable` modifiers that were only necessary because of that.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D50364626
fbshipit-source-id: 28ed9fa923f8e787166f702ccaecd41a635d3b3a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40945
This adds some temporary logic to configure the use of the modern version of RuntimeScheduler based on values coming from the app configuration.
This logic is centralized in `ReactInstance` so from that point the code is completely cross-platform.
This doesn't use `ReactNativeConfig`/`CoreFeatures` because they're initialized after the point where we need to access them for this use case. This way is a bit uglier but this isn't intended to live for long (only until we verify this doesn't have regressions in a complex app).
Changelog: [internal]
---
Reviewed By: sammy-SC
Differential Revision: D50171297
fbshipit-source-id: 8d96e228550cc6112ffe2abec4d531514b052f82
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40944
## Summary
This creates a new version of `RuntimeScheduler` that's intended to be backwards compatible but with a few notable changes:
1. `scheduleTask` is now thread-safe.
2. `scheduleWork` is now just an alias of `scheduleTask` with immediate priority (to preserve the yielding semantics it had over other tasks).
3. Yielding mechanism has changed, to make lower priority tasks to yield to higher priority tasks, instead of just yielding to `scheduleWork` and `executeNowOnTheSameThread`.
We don't expect this to have any impact in performance or user perceivable behavior, so we consider it a short-lived refactor. When we validate this assumptions in a complex application we'll delete the old version and only keep the fork.
## Motivation
The main motivation for this refactor is to reduce the amount of unnecessary interruptions of running tasks (via `shouldYield`) that are only used to schedule asynchronous tasks from native.
The `scheduleWork` method is the only available mechanism exposed to native APIs to schedule work in the JS thread (as the existing version of `scheduleTask` is only meant to be called from JS). This mechanism **always** asks for any running tasks in the scheduler to yield, so these tasks are always considered to have the highest priority. This makes sense for discrete user events, but not for many other use cases coming from native (e.g.: notifying network responses could be UserBlocking, Normal or Low depending on the use case).
We need a way to schedule tasks from native with other kinds of priorities, so we don't always have to interrupt what's currently executing if it has a higher priority than what we're scheduling.
## Changes
**General APIs:**
This centralizes scheduling in only 2 APIs in `RuntimeScheduler` (which already exist in the legacy version):
* `scheduleTask`, which is non-blocking for the caller and can be used from any thread. This always uses the task queue in the scheduler and a new yielding mechanism.
* `executeNowOnTheSameThread`, which is blocking for the caller and asks any task executing in the scheduler to yield. These tasks don't go through the task queue and instead queue through the existing synchronization mechanism in `RuntimeExecutor`. The yielding mechanism for these tasks is preserved.
`scheduleWork` will be deprecated and it's just an alias for `scheduleTask` with an immediate priority (to preserve a similar behavior).
**Yielding behavior:**
Before, tasks would only yield to tasks scheduled via `scheduleWork` and `executeNowOnTheSameThread` (those tasks didn't go through the task queue).
With this implementation, tasks would now yield to any task that has a higher position in the task queue. That means we reuse the existing mechanism to avoid lower priority tasks to never execute because higher priority tasks never stop coming.
All tasks would yield to requests for synchronous access (via `executeNowOnTheSameThread`) as did the current implementation.
Changelog: [internal]
Reviewed By: javache, sammy-SC
Differential Revision: D49316881
fbshipit-source-id: 046afc8b6f510a8608ef3da6e27b2663d861f1b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40875
This introduces a proxy for RuntimeScheduler so we can select between 2 different implementations at runtime (current implementation vs. new implementation, done in D49316881).
Changelog: [internal]
Reviewed By: javache, sammy-SC
Differential Revision: D49316880
fbshipit-source-id: 4035ed6ba641a2316f2efb7cf4a0a86270d6ae23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40870
This removes an old experiment to implement microtasks in React Native (which is incorrect now that the runtime scheduler executes multiple tasks per runtime executor "task"). `drainMicrotasks` is a no-op at the moment in Hermes because the flag isn't set, so this code is essentially dead.
We'll add the new iteration of microtasks in a following PR.
Changelog: [internal]
Reviewed By: christophpurrer
Differential Revision: D49536251
fbshipit-source-id: b8efba2d0310b9e33e65b79c60ad2db1c8109def
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41054
changelog: [internal]
Avoid going into a while loop if there are no preMountItems.
Reviewed By: javache
Differential Revision: D50407034
fbshipit-source-id: 5c163e02303c331b8fff46fb9a955f88f72a529c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41051
Strictifies flow to flow strict-local in files where doing that doesn't cause new flow errors.
Changelog: Internal
Reviewed By: yungsters
Differential Revision: D50369011
fbshipit-source-id: b4a5a26b839b7327a3178e6f5b35246dea365a38
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41047
Array events are currently broken in the sample for RN Tester. This is because the event name is not registered correctly.
I'm updating the event registration to be correct.
Changelog:
[Internal] [Changed] - Make IntArray events work on Bridgeless for RN-Tester
Reviewed By: cipolleschi
Differential Revision: D50266485
fbshipit-source-id: 13bbce91a41281383d4857048e573b6d9cc5387b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41020
This adds Fabric and Paper bindings to support `alignContent: "space-evenly"` as implemented in https://github.com/facebook/yoga/pull/1422
Changelog:
[General][Added] - Bindings for `alignContent: "space-evenly"`
Reviewed By: yungsters
Differential Revision: D50347978
fbshipit-source-id: 44df3b8ddc7171cddf56957c11ac7d975f706f9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41019
### Changes made
- Regenerated tests (as some aspect ratio tests seem to be out of date compared to the fixtures)
- Added SpaceEvenly variant to the "Align" enums (via enums.py)
- Implemented `align-content: space-evenly` alignment in CalculateLayout.cpp
- Added generated tests `align-content: space-evenly`
- Updated NumericBitfield test to account for the fact that the Align enum now requires more bits (this bit could do with being reviewed as I am not 100% certain that it's valid to just update the test like this).
### Changes not made
- Any attempt to improve the spec-compliance of content alignment in general (e.g. I think https://github.com/facebook/yoga/pull/1013 probably still needs to happen)
X-link: https://github.com/facebook/yoga/pull/1422
Reviewed By: yungsters
Differential Revision: D50305438
Pulled By: NickGerleman
fbshipit-source-id: ef9f6f14220a0db066bc30db8dd690a4a82a0b00
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41023
X-link: https://github.com/facebook/yoga/pull/1426
Just like D50140503 where marginStart and marginEnd were not working with row reverse, paddingStart and paddingEnd are not working either with row reverse either. The solution is similar - we were checking the flex item layout starting/ending edges and not the general layout starting/ending edges. This change makes it so that we look at the proper edge according to what direction is set.
One caveat is that in the case of padding (and also border) there is a callsite that actually wants to get the flex item layout's leading/trailing padding and not the one dictated by direction. So, I made a new function to accommodate this and just swapped that callsite out.
Reviewed By: NickGerleman
Differential Revision: D50348995
fbshipit-source-id: 85717df23de7cf5f66b38d3ff28435b053a4e68e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41022
X-link: https://github.com/facebook/yoga/pull/1425
Just like D50140503 where marginStart and marginEnd were not working with row reverse, borderStart and borderEnd are not working either with row reverse either. The solution is similar - we were checking the flex item layout starting/ending edges and not the general layout starting/ending edges. This change makes it so that we look at the proper edge according to what direction is set.
One caveat is that in the case of border (and also padding) there is a callsite that actually wants to get the flex item layout's leading/trailing border and not the one dictated by direction. So, I made a new function to accommodate this and just swapped that callsite out.
Reviewed By: NickGerleman
Differential Revision: D50348085
fbshipit-source-id: eca2702c1753dbebb503034e2f0732684ad6c56e
Summary:
X-link: https://github.com/facebook/yoga/pull/1423
Pull Request resolved: https://github.com/facebook/react-native/pull/41017
Before resolving https://github.com/facebook/yoga/issues/1208 yoga was in a state where "leading" and "trailing" only referred to the main-start and main-end directions ([definition in spec](https://drafts.csswg.org/css-flexbox/#box-model)). That is, the start/end of the layout of flex items in a container. This is distinct from something like inline-start/inline-end which is the [start of text layout as defined by direction](https://drafts.csswg.org/css-writing-modes-3/#inline-start).
The bug linked above happened because "leading" and "trailing" functions are referring to the wrong directions in certain cases. So in order to fix this we added a new set of functions to get the "leading" and "trailing" edges according to what inline-start/inline-end would refer to - i.e. those defined by the direction (ltr | rtl). In this state I think it is confusing to understand which function refers to which direction and more specific names could help that.
This diff just renames the following 4 FlexDirection.h functions:
* **leadingEdge** -> **flexStartEdge**
* **trailingEdge** -> **flexEndEdge**
* **leadingLayoutEdge** -> **inlineStartEdge**
* **trailingLayoutEdge** -> **inlineEndEdge**
The spec calls the start/end directions as dictated by the flex-direction attribute "main-start" and "main-end" respectively, but mainStartEdge might be a bit confusing given it will be compared to a non-flexbox-specific name in inlineStartEdge. As a result I landed on flexStart/flexEnd similar to what values are used with alignment attributes (justify-content, align-content).
I chose to get rid of the "leading" and "trailing" descriptors to be more in line with what terminology the spec uses.
Next diff will be to rename the functions in Node.cpp to adhere to the above patterns.
Reviewed By: NickGerleman
Differential Revision: D50342254
fbshipit-source-id: 1e83a885876af9cf363822ebdbb64537f4784520
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41033
This has been rolled out with the false value (previous client-default of false). The open-source value was already false.
Changelog: [Internal]
Reviewed By: NickGerleman, sammy-SC
Differential Revision: D50362517
fbshipit-source-id: 577a2ead047b30d196409a26fd5385f333f20b18
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41036
Changelog:
[Added] - Shipping the new event dispatching pipeline that immediately moves events over to the C++ queue. This should unblock useDeferredValue + useTransition interruptibility on Android.
Reviewed By: javache
Differential Revision: D50365981
fbshipit-source-id: ecf60e5bc29fb4568463568a6ede4330e0294fd3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41016
This hasn't been very useful since AsyncStorage/persistence was removed, but takes up a good amount of usable screen real-estate for information in the center of the screen. Remove it.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D50297980
fbshipit-source-id: 296a377dffc89c5c203ca6264351a2a1a8281cc3
Summary:
… request to local pathname comparator variables to fix issue with other rightward elements of url such as query or fragment entering the comparison and causing 404 errors for key debugging routes.
A change in Chromium appended the query "?for_tabs" to the /json/list request made by Chrome DevTools to find remote debugger targets.
The current comparison in InspectorProxy.js compares the entire node IncomingMessage url field to the local pathname constants. The issue arises as url can also contain the query and fragment portions so the original comparison of "/json/list" === "/json/list" which resolved as true would become "/json/list?for_tabs" === "/json/list" and evaluate to false ultimately resulting in a 404 for the request.
In summary, all these changes/issues caused remote debugging of Hermes code in React Native apps to become unavailable, greatly impacting developer experience.
## Changelog:
[GENERAL] [FIXED] JS Debugging: Fix inspector-proxy to allow for DevTools requests with query strings
Pull Request resolved: https://github.com/facebook/react-native/pull/41005
Reviewed By: NickGerleman
Differential Revision: D50342265
Pulled By: robhogan
fbshipit-source-id: a65f2908f0bea9fc15e1e3e4e6d31a3b9598e81f
Summary:
Fix https://github.com/facebook/react-native/issues/40560
## Changelog:
[ANDROID] [FIXED] - Ensure that `configureJavaToolChains` is only executed once during configuration
Pull Request resolved: https://github.com/facebook/react-native/pull/40757
Test Plan:
- Create a fresh `react-native@0.73.0-rc.1` project
- Install `react-native-webview`
- Apply [this patch](https://github.com/react-native-webview/react-native-webview/pull/3175/files) for `react-native-webview` (caused by another issue https://github.com/facebook/react-native/issues/40559)
- Edit `android/gradle.properties` and set `newArchEnabled` to true
- Build application
- (Expected) Application fail to build
- Apply this PR
- (Expected) Application build successfully
**Additional explanation:**
According to the implementation of `configureJavaToolChains`, all the subprojects (both the app and the libraries) will have their toolchains setup in one execution of the method. Therefore, it is okay for the method to be invoked only when configuring the plugin for the app.
On the other hand, invoking the method for more than one time will cause the issue stated in https://github.com/facebook/react-native/issues/40560.
Reviewed By: cipolleschi
Differential Revision: D50361871
Pulled By: cortinico
fbshipit-source-id: bd5e18df97988122788d0482dba954e517a0cb5c
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:
Problem Causes: In ReactViewGroup, there is a conflict between the zIndex attribute and the removeClippedSubviews optimization attribute. When both are used at the same time, the array mDrawingOrderIndices in ViewGroupDrawingOrderHelper that records the rendering order of subviews is not reset when super is called in the updateSubviewClipStatus method to add and remove subviews.
Solution:�Because there are many third-party components that inherit from or depend on ReactViewGroup, all methods for adding and removing subviews in ViewGroup need to be override in ReactViewGroup, and ViewGroupDrawingOrderHelper corresponding to handleAddView and handleRemoveView needs to be called in these methods. And all the precautions for directly calling super to add and remove subviews are changed to calling the overridden method by ReactViewGroup.
Special Note: All addView related methods in ViewGroup will eventually be called to the addView(View child, int index, LayoutParams params) method, except addViewInLayout. Regarding the method of adding subviews, we only need to override addView(View child, int index, LayoutParams params) and addViewInLayout(View child, int index, LayoutParams params,boolean preventRequestLayout) in ReactViewGroup.
## Changelog:
[Android] [Fixed] - Fix the crash in ReactViewGroup of https://github.com/facebook/react-native/issues/30785
Pull Request resolved: https://github.com/facebook/react-native/pull/40859
Reviewed By: NickGerleman
Differential Revision: D50321718
Pulled By: javache
fbshipit-source-id: 7fa7069937b8c2afb9f30dd10554370b1be5d515
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.
## Changelog:
<!-- 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
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40941
Events are currently not working for Fabric Interop on Bridgeless. That's because the `BridgelessReactContext` is not checking for interop modules on `getJsModule` calls, so the `InteropEventEmitter` is never returned.
This extends `BridgelessReactContext` so that `InteropEventEmitter` is returned if the Interop Layer is turned on.
Changelog:
[Internal] [Changed] - Make events work for Fabric Interop on Bridgeless
Reviewed By: cipolleschi
Differential Revision: D50266484
fbshipit-source-id: 0188d71bdc7acc8c188d886d45f0258914ad7af7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41003
Following up the deprecation of Flipper in 0.73 and preparing for the removal of Flipper in 0.74, we are removing Flipper integration from the CI.
## Changelog:
[Internal] - Remove the Flipper integration from CI
Reviewed By: dmytrorykun
Differential Revision: D50321335
fbshipit-source-id: 04885d3dbaab9b2834c9461e0580dfbef386244f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41002
Following up the deprecation of Flipper in 0.73 and preparing for the removal of Flipper in 0.74, we are removing Flipper integration from the Codebase.
## Changelog:
[iOS][Breaking] - Remove the Flipper integration
Reviewed By: dmytrorykun
Differential Revision: D50321255
fbshipit-source-id: d2f4488ada7acdbd3687f54db4204ba7f09370af
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40895
This is a long running debug assert due to a race condition with BE. I have at times wanted to try to add a lock to protect this, and measure impact, but really it will go away when we get rid of BE anyway, and any strategy I have come up with to lock gets hairy quickly.
This change does not impact RN in OSS, where BE is already disabled.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D50247680
fbshipit-source-id: d004fc7db24f1f0b7c3ea8756d4678ce41579712
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40970
This cleans up https://github.com/facebook/react-native/commit/94972039571e1f3b387e0f63227a6ad13740eaf3 a bit, after I did some debugging and looking through Android source code.
1. `getRootView()` gives us constant-time access to root hierarchy, and we don't need to do instanceof check once per level. It also, at least in the sample activity I tried, gives us the Window's `LayoutParams`.
2. The root of the hierarchy is documented in code to do what we want. https://github.com/facebook/react-native/commit/94972039571e1f3b387e0f63227a6ad13740eaf3
3. Calling `getRootView().getLayoutParams()`, then casting to `WindowManager.LayoutParams`, seems to show up in a lot of other widgets (inc Unity, RoboElectric), as a solution to getting this information. https://github.com/search?q=getRootView%28%29.getLayoutParams%28%29&type=code
This still feels like not a 100% documented contract, so I added an assertion so we can catch if the contract isn't valid somewhere now or in the future, instead of silently breaking keyboard events.
Note that this code only runs on SDK 30+ (Android 11+).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D50297761
fbshipit-source-id: f97fb6ea1bcdb1b8e8dfcdcc178625efc0bb6b4a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41011
changelog: [internal]
topContentSizeChange should be a direct event. Otherwise it collides with ScrollView's `onContentSizeChange` any may break FlatList
Reviewed By: javache
Differential Revision: D50323281
fbshipit-source-id: dd8713acfdd5158ac8175b8efe5027d06cd0d0a8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40968
Enable Explicit API mode warning to let product developers get notified of Explicit API checks (similar to deprecation mechanism). Explicit API mode will be enabled as strict in a future version
more details: https://kotlinlang.org/docs/whatsnew14.html#explicit-api-mode-for-library-authors
changelog: [Android][Changed] Enabling Explicit API warning, this will be changed as Strict in a future version
Reviewed By: cortinico
Differential Revision: D50295069
fbshipit-source-id: 41f7eb823ef8cfb4266dfa2d927f54c7dab9193a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40929
This diff reduces the footprint that bridgeless is imposing on the new app template. Specifically:
- I've created a `.toReactHost` method that converts a DefaultReactNativeHost to a DefaultReactHost
- I've updated RN Tester to use the same setup as the New App template which reduces code duplication.
I also had to remove a couple of `UnstableReactNativeAPI` as those were bleeding in the new app template.
I don't think we should ask users to opt-in in `UnstableReactNativeAPI` in the New App template itself as
this means that all the apps will get this opt-in.
Instead we should keep it only for specific APIs that we want the users to opt into.
Changelog:
[Internal] [Changed] - Simplify new app template for bridgeless
Reviewed By: cipolleschi, luluwu2032
Differential Revision: D50227693
fbshipit-source-id: e86c54d5156cc27f1f898b43ca89c57d5cf148b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40866
This type doesn't do anything, and we can replace it with a `jsi::Function` inside `UIManagerBinding`.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D50176084
fbshipit-source-id: 1c782f3e4d212f1d956451fd650d3ed5ed8f0d71
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40942
The Fabric Interop example for Android is broken. This is due to the Kotlin conversion which moved the `Color.colorToHSV(color, hsv)` statement *after* the HSV array is read so the array is always [0,0,0].
I'm fixing it here.
Changelog:
[Internal] [Changed] - Fix broken Fabric Interop example
Reviewed By: cipolleschi
Differential Revision: D50264766
fbshipit-source-id: 27ae5289408c7c23c667d6d7112437fa7ebe36d5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40873
Some host platforms may require the LayoutContext for computing the size of text, e.g. to read the pointScaleFactor value. This change passes the LayoutContext to TextLayoutManager so it can be used during text measurement.
Please note, for now, this does not wire any fields from LayoutContext through to the TextMeasureCache, TextLayoutManager::getHostTextStorage, or TextLayoutManager::measureCachedSpannableById (on Android).
## Changelog:
[General] [Internal]
Reviewed By: rshest
Differential Revision: D50227592
fbshipit-source-id: 37ec16a4828c6cef4a1c1f01d144a86dd29dec29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40940
Currently the `onIntArrayChanged` event is invoked
only once inside RN Tester. I'm changing the logic to make sure it fires whenever we click "Set Opacity"
Changelog:
[Internal] [Changed] - Make sure onIntArrayChanged is invoked on RN Tester
Reviewed By: mdvacca, dmytrorykun
Differential Revision: D50264765
fbshipit-source-id: 93a60fd1b657c3d8b8182cab6bb7cd4368ac9a42
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41001
I believe this is due to a race condition between VM teardown and callback invocation. Because we were previously retaining the CallbackWrapper across the invokeAsync call, we may potentially have been holding onto the JSI::Function after it was already destroyed.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D50286876
fbshipit-source-id: 1277a9f37166da59ebb2169fe8d5a6fabce82f1b
