Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43699
This diff initializes `RELEASE_VERSION` with the value that is provided by the `get_react_native_version` job (it stores its output into `/tmp/react-native-version`).
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D55484988
fbshipit-source-id: f0b5bb473096f3691f50152beb3181a454916fdc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43661
# Changelog: [Internal]
1. Remove `BridgelessDebugReactPackage.java`, this was added in D43407534. Technically, its the same as `DebugCorePackage.java`.
2. `ReactInstance` to add `DebugCorePackage`, so `DebuggingOverlay` view manager will be included in the bridgeless build.
3. Fix `RNTesterApplication.kt` to NOT create `MyLegacyViewManager` for every possible viewManagerName, apart from `"RNTMyNativeView"`, return null instead.
Reviewed By: cortinico
Differential Revision: D55375350
fbshipit-source-id: 1d3cb6b5ad3c0248df1def9f37c8c49b308f4473
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43690
# Changelog: [Internal]
Fixes https://github.com/facebook/react-native/issues/43678.
The issue is that once `getInspectorDataForViewAtPoint` is imported, it should throw if RDT global hook was not injected. ReactDevTools overlay imports `getInspectorDataForViewAtPoint`, this is why it did throw in testing environment.
ReactDevToolsOverlay JSX-element is already gated with RDT global hook check, adding a deferred import, same as it was already implemented for Inspector.
Still unclear to me how this didn't throw all this time while using the Catalyst / RNTester.
Reviewed By: cortinico
Differential Revision: D55474774
fbshipit-source-id: 759e5e8227cc7534193e5b95616b6099c15f5cb5
Summary:
When RN moved Button component from a class component to a function component (07e8ae42be) a forwardRef call was not added to the Button control. This caused a set of tests downstream in React Native for Windows to fail because they rely on being able to pass a ref through to the Button control.
## Changelog:
[GENERAL] [FIXED] - Adds forwardRef call to new functional component implementation of Button control.
Pull Request resolved: https://github.com/facebook/react-native/pull/43666
Test Plan: Button render remains the same.
Reviewed By: fabriziocucci
Differential Revision: D55398765
Pulled By: zeyap
fbshipit-source-id: ba32c764c16cb529ab1c92cb7888f2bae0f16f5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43664
Changelog: [internal]
Now that we have the event loop, we can modify the implementation of `MutationObserver` (which is still not enabled by default) to dispatch the notifications as microtasks, making the API more spec-compliant.
Reviewed By: javache
Differential Revision: D55380178
fbshipit-source-id: f876ffba49f9744f6603053f1485e7c2f43cb230
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43672
Changelog: [internal]
Small cleanup to move the last C++ native module defined in a JS directory to the new directory in `react-native/ReactCommon/react/nativemodule`.
Reviewed By: javache
Differential Revision: D55384106
fbshipit-source-id: 3bf477c2aceab6838f7f8131174b6eb74e890a23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43663
Changelog: [internal]
We have a new directory for built-in C++ native modules, but the native modules for `MutationObserver` and `IntersectionObserver` were created before we had it.
This moves the native module for `MutationObserver` to `react-native/ReactCommon/react/nativemodule/mutationobserver` to follow the convention.
Reviewed By: javache
Differential Revision: D55380179
fbshipit-source-id: 0c64acbec973f2e5b57a0e38a0992bba49a01a45
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43653
Changelog: [internal]
This will allow us to clean up some code in `UIManager` (using methods in the native module instead) and prepare to use the DOM APIs in OSS behind a feature flag.
This doesn't enable the DOM APIs in OSS, only the native module.
Reviewed By: javache
Differential Revision: D55365252
fbshipit-source-id: 70ec0eb022df586ad554c5b8ce6915b8ceddef5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43659
Changelog: [internal]
This adds an implementation for the legacy layout measurement methods in React Native (`measure`, `measureInWindow` and `measureLayout`) in the DOM native module, so we can clean up the API from the `nativeFabricUIManager` binding.
Reviewed By: javache
Differential Revision: D55368141
fbshipit-source-id: 196d4d29be3b78ffc22fdc136be6e0cf5ab9dd26
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43679
The current implementation of clear-with-predicate first copies unconsumed
elements and then all others. This works correctly when the buffer is full
(wraps around), but fails if size() < maxSize: add() may no longer insert
an element in the correct position (after the last unconsumed entry; see
new unit test).
Replace it with a loop that iterates over all entries in order, and adjusts
cursorStart and cursorEnd to point to the last numToConsume elements of the
vector.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D55273402
fbshipit-source-id: 647dc35faeb35c7fa99b8113cf85ce7f02f073e5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43676
changelog: [internal]
calling super invalidates eventEmitter. EventEmitter should be invalidated before reseting contentOffset on `_scrollView. Otherwise, UIScrollView::setContentOffset is called and it calls delegate method: `scrollViewDidScroll`.
Reviewed By: javache
Differential Revision: D55375060
fbshipit-source-id: f697805eb1ca05d15cf498ff9e5e06e90eb7ac56
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43538
The Hermes RuntimeConfig for bridgeless accidentally force-disabled ES6Proxy, resulting in https://github.com/facebook/react-native/issues/43523
Let's remove the incorrect override.
To test using RNTester, add the following change:
```
diff --git a/packages/rn-tester/js/RNTesterAppShared.js b/packages/rn-tester/js/RNTesterAppShared.js
index 87cb6b69dfe..f2512d09c5a 100644
--- a/packages/rn-tester/js/RNTesterAppShared.js
+++ b/packages/rn-tester/js/RNTesterAppShared.js
@@ -50,6 +50,8 @@ const RNTesterApp = ({
);
const colorScheme = useColorScheme();
+ new Proxy({}, {});
+
const {
activeModuleKey,
activeModuleTitle,
```
Before this change, RNTester will get an error at start-up. After, the app loads correctly.
Changelog: [General][Fixed] Correctly keep ES6Proxy for bridgeless mode
Reviewed By: cortinico
Differential Revision: D55045780
fbshipit-source-id: 666b99712d35622f87d42f22a4611851df67d905
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43251
Integrates the modern CDP backend with `CatalystInstanceImpl` (the React Native instance implementation) on Android.
This complete the modern CDP integration for Bridge.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D51458010
fbshipit-source-id: 6f73868da9d0d4cc5d086a4569c78444cb1b83ec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43657
This include is not correct and is breaking the OSS build
Changelog:
[Internal] [Changed] - Fix header import inside ReactInstanceManagerInspectorTarget.h
Reviewed By: rshest
Differential Revision: D55368321
fbshipit-source-id: 0530257ad5c548476beb882174d73842775b3726
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43646
PerformanceEntryReporter maintains a buffer of RawPerformanceEntry objects,
as well as a set of _pointers_ to elements within that buffer, used to find
entries by name.
However, those pointers aren't stable: BoundedConsumableBuffer internally uses
a vector, and there are a few cases where existing references get invalidated:
- When the vector's capacity changes (as new entries get inserted) [1]
- After calling clear-with-predicate, which copies elements into a new vector
This causes nameLookup to contain dangling pointers, and subsequent operations
on it can result in use-after-free.
Fix this by having BoundedConsumableBuffer reserve space for maxSize entries
up front (which ensures that existing pointers remain valid after adding new
elements) and by rebuilding nameLookup after clearing entries by name.
Note that reserve() causes the buffer's memory use to be higher than before in
case where the number of elements is small relative to the max size. Given the
(only) existing usage in PerformanceEntryReporter, as well as the property that
consumed elements remain in the buffer, that cost should be minor.
Changelog: [Internal]
[1] https://en.cppreference.com/w/cpp/container/vector/push_back
Reviewed By: rshest
Differential Revision: D55273403
fbshipit-source-id: c8f33203ae32685e29afa7f8e33edf1284d66e0f
Summary:
Small typo I encountered while trying to build custom C++ type converters :)
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [FIXED] Fixed a small typo in the "unsupported type" error message
Pull Request resolved: https://github.com/facebook/react-native/pull/43650
Reviewed By: zeyap
Differential Revision: D55364068
Pulled By: cortinico
fbshipit-source-id: 5a1bc9443c82f2473860f379c9ae063cd6e3ceb4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43655
## Changelog:
[Internal] -
The corresponding prop `ScrollBar.persistentScrollIndicator` was only passed to the Android platform code an `ScrollBar.horizontal` wasn't passed to native at all.
On other platforms we need those props to be available on the C++ side, so this exposes them to the corresponding C++ ScrollViewProps.
Reviewed By: sammy-SC
Differential Revision: D55367445
fbshipit-source-id: e8abca3a2b56a8e7c03593a6c4297f90749ac8fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43652
This improves the signature of our existing DOM APIs in 2 ways:
1. It replaces the use of `tuples` in `DOM.{h,cpp}` with safer structs.
2. It removes some unnecessary optionals from the API, returning the default values from the C++ API directly when appropriate.
It still preserves the use of tuples in the native module because objects are not properly supported in the codegen.
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D55316654
fbshipit-source-id: 16ce5ef62ca427cdcd6b9757d77db040e0ccc8b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43626
The things that create ReactApplicationContext should instead create BridgeReactContext.
Long-term, ReactApplicationContext will be abstract. This diff pulls noise out from that eventual diff.
Changelog: [Internal]
Reviewed By: arushikesarwani94
Differential Revision: D55218591
fbshipit-source-id: d359c794f3da4a1ecb2fa8edbed5eeeb620b137b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43627
Eventaully, ReactApplicationContext.initailizeWithInstance() will be moved to BridgeReactContext.
Doing the migration up-front to remove noise from the eventual diff.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55218593
fbshipit-source-id: c542c44cf8b36b9dc2a01db2bf6173639fb8698a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43624
Eventually, we will move all bridge methods to BridgeReactContext.
Long-term, ReactApplicationContext and ReactContext will become abstract. And these two contexts will only contain methods common to both modes.
Changelog: [Android][Added] Introduce BridgeReactContext
Reviewed By: cortinico
Differential Revision: D55218592
fbshipit-source-id: 731d4940d492a1ed3f855c9a181d2a6f9eeb9623
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43250
Integrates the modern CDP backend with `ReactInstanceManager` on Android.
`ReactInstanceManager` is equivalent to the CDP page / `HostTarget` concept, therefore we register the `addPage`/`removePage` calls with this object's lifecycle.
Implementation notes:
- `ReactInstanceManagerInspectorTarget` is created to avoid converting `ReactInstanceManager` to JNI (impacting tests).
- Its constructor receives a `TargetDelegate` object, so that we avoid passing the entire `ReactInstanceManager` class through (avoids cyclic dependency from `com.facebook.react.bridge` to `com.facebook.react`).
Changelog:
[Internal] - Register `ReactInstanceManager` with modern CDP backend
Reviewed By: motiz88
Differential Revision: D51456960
fbshipit-source-id: 942255bb2487fdc581eb4fa0903c8e68106f8b35
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43615
This class is used for a one-time setup of bindings into the jsi::Runtime. The lambda will retain ownership of any java components required, and we can rely on the teardown of the JS runtime to clean up any dependencies.
Changelog: [Internal]
Reviewed By: dmytrorykun
Differential Revision: D55241233
fbshipit-source-id: f7541f28277307be9b3a5f4f780c7eca1a467c57
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43614
Storing a global_ref to `jThis` in a JNI hybrid object leads to a reference cycle which cannot be cleaned up by Java GC. The Java object will keep the C++ object alive and vice versa.
In this class, we didn't seem to need this reference anyway.
Changelog: [Internal]
Reviewed By: dmytrorykun
Differential Revision: D55241232
fbshipit-source-id: 933521ed1483c149f693988ca17f4c53565dbfe0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43612
This class is used for a one-time setup of bindings into the jsi::Runtime. The lambda will retain ownership of any java components required, and we can rely on the teardown of the JS runtime to clean up any dependencies.
Changelog: [Internal]
Reviewed By: dmytrorykun
Differential Revision: D55241234
fbshipit-source-id: ee80ca0f91ebe95f8c44874b27912b260f70b572
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43618
Both common and Android implementations of AsyncEventBeat use weak_ptrs
to determine if the object is still valid before invoking the callback.
Move the write to `isBeatCallbackScheduled_` down so it's protected by
that same check.
Changelog: [Internal]
Reviewed By: javache, NickGerleman
Differential Revision: D55226529
fbshipit-source-id: 9e2a34369346d11dcea69d120dfa5935320f9ba1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43639
Currently, the `react-native/dev-middleware` inspector proxy intercepts `Debugger.scriptParsed` notifications from the target and replaces `sourceMapURL` with a data uri, via an async fetch from Metro. During this async fetch, other notifications from the debugger may pass through the proxy, which results in the frontend receiving them before `Debugger.scriptParsed`.
This reordering causes problems in breakpoint resolution and pausing, because `Debugger.breakpointResolved` and `Debugger.paused` events may reference `scriptId`s unknown to the frontend while the corresponding `Debugger.scriptParsed` is delayed.
In particular, breakpoint UI state and backend state can fall out of sync, and breakpoints hit may open to the incorrect source location.
This diff modifies the proxy to use a simple per-target promise queue to ensure messages are handled in the order they were received from the target.
Changelog:
[General][Fixed] Fix breakpoints opening to incorrect location or disappearing from debugger frontend UI.
Reviewed By: motiz88
Differential Revision: D55200617
fbshipit-source-id: 27c95f822266875ed668d0bf8a525da49554cafd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43642
Changelog: [internal]
This change broke some apps at Meta. Reverting until we figure out a safe way to land this.
Reviewed By: rshest
Differential Revision: D55324557
fbshipit-source-id: 684d3dc3780fc41e2e91f367d97fa5cd392e6638
Summary:
Now that RN is providing TS type information, many of those .d.ts files depend on types from react. In modern packagemanagers (Ex: pnpm) types/react will not be available to RN since it does not declare it as a dependency.
I also noticed that the types for react-native-popup-menu-android appear to be pointing to the wrong location.
Add types/react as a peerDependency on the packages that have .d.ts files that import from React.
Add types/react to peerDependencyMeta with optional:true to prevent users not using TS from requiring types/react.
## Changelog:
[GENERAL] [ADDED] Added types/react as an optional peerDependency
Pull Request resolved: https://github.com/facebook/react-native/pull/43509
Reviewed By: cortinico
Differential Revision: D55225940
Pulled By: NickGerleman
fbshipit-source-id: 4cbab071928cb925baec45f55461559acc9a54e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43578
Changelog: [internal]
We have a feature to do some validation of the mount operations when committing new trees in Fabric. That's very slow but it was ok before because we were only doing this in debug mode and in the JS thread. We're moving some of this work to the UI thread instead and we're seeing an impact on scroll performance.
This disables this feature by default but leaves it in code to enable it when necessary for debugging.
Reviewed By: NickGerleman, sammy-SC
Differential Revision: D55138795
fbshipit-source-id: 45ca47ae2562cecb070691bf33d95c9108a9eca3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43580
Changelog: [internal]
This introduces a new feature flag to commit state updates synchronously from the UI thread (generally) instead of dispatching them to the JS thread to be processed there. We can do this now because we introduced a UI consistency mechanism in D55024832 to JS would see a consistent revision during the execution of a specific task.
Reviewed By: sammy-SC
Differential Revision: D55083029
fbshipit-source-id: 8aa84ddaee383f098252fa679cfb07012ba29bf8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43579
Changelog: [internal]
This updates all the legacy layout APIs in React Native to make use of the UI consistency mechanism introduced in Fabric (if available, otherwise the behavior is the same we have now — we consume the latest version of the tree available).
Reviewed By: sammy-SC
Differential Revision: D55077309
fbshipit-source-id: f6ff2a4f6cd1a2040f0cfeffb1e68f4ec0240f91
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43577
Changelog: [Internal]
This updates all the DOM APIs in React Native (defined in the `NativeDOM` native module) to make use of the UI consistency mechanism introduced in Fabric (if available, otherwise the behavior is the same we have now — we consume the latest version of the tree available).
As part of that work, this creates a new `DOMMethods` class that implements all methods using purely C++ APIs (not JSI), moves a lot of logic that was specific for this functionality from `UIManager` to `DOMMethods` and modifies `NativeDOM` to use this new class.
This should make it easier to add unit tests for `DOMMethods` in the future.
Reviewed By: NickGerleman
Differential Revision: D55077311
fbshipit-source-id: f96bf5f3a97236fd24dbd2315256de4ce979e151
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43581
Changelog: [internal]
This implements a mechanism to ensure that JavaScript tasks have a consistent view of the state of the UI during their execution.
## Context
Fabric allows committing new revisions of the ShadowTree from any thread, but we don't make use of this capability and instead always commit them from the JS thread (e.g.: when we schedule Fabric state updates to update the offset of a list on scroll). This was done to make sure that JS work didn't see changes in the state of the tree at random points during its execution. E.g.:
```
useEffect(() => {
const rect = ref.current.getBoundingClientRect();
// do something
const newRect = ref.current.getBoundingClientRect();
// `rect` and `newRect` should always be the same
}, []);
```
This isn't used by Reanimated at the moment, which means JS can inadvertently see the result of animations in non-specific times during execution.
You can find additional context about this in the [RFC for DOM Traversal & Layout APIs in RN](https://github.com/react-native-community/discussions-and-proposals/blob/main/proposals/0607-dom-traversal-and-layout-apis.md#consistency-and-updates).
This works correctly at the moment, but we introduce a limitation in the execution model to prevent updating the tree synchronously from the main thread. One of the main problems this introduces is that computing intersections (for `IntersectionObserver`) relies on the information in the shadow tree, but this is updated asynchronously on scroll.
There are 2 potential solutions for that problem:
1) Send the timestamp of the scroll even with the state update to backdate the timestamps of the intersections. This could work but introduces more complexity and possibly accuracy problems due to batching those state updates with other changes (e.g.: what happens if we update the state and commit another tree in the same task? should we use the backdated timestamp or wait for mount?).
2) (**Preferred**/ this diff) Allow committing new revisions from any thread, but lock the JS thread into seeing a specific revision, which would only update/progress in specific moments when it's safe. Some of those moments would be:
1) When we start a new JS task.
2) When we commit a new tree from React (JS).
## Changes
This implements the solution outlined in 2), creating a few abstractions to handle what's the current tree that should be visible to JS and to lock/unlock it in specific moments.
More specifically:
* Creates `ShadowTreeRevisionProvider` as an abstract class for APIs consuming the visible revision of the ShadowTree (mainly DOM APIs and layout methods like `measure`, etc.).
* Creates `ShadowTreeRevisionConsistencyManager` as an abstract class to handle what trees are visible (with a `lockRevision` and `unlockRevision` to be called from `RuntimeScheduler` at the beginning and end of each JS task).
* Creates 2 different implementations of these abstractions:
* One that preserves the current behavior (`LatestShadowTreeRevisionProvider`, which just returns the last committed revision at the time of the call).
* One that locks revisions lazily (the first time they're accessed) (`LazyShadowTreeRevisionConsistencyManager`).
Reviewed By: sammy-SC
Differential Revision: D55024832
fbshipit-source-id: b59985bc83714ae7ec915baba72bf92b3d6fa140
Summary:
I found in 0.74.0-rc.x, `ccache_enabled` is introduced. However, it is not being delivered via npm.
fixes https://github.com/facebook/react-native/issues/43633
Changelog: [iOS] [Fixed] - Adding ccache_clang wrapper scripts to package.json for distribution
Pull Request resolved: https://github.com/facebook/react-native/pull/43634
Reviewed By: cortinico
Differential Revision: D55308743
Pulled By: blakef
fbshipit-source-id: e89a4bb3a1fbf8562d880b4c9d25dc9083717ba6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43611
Storing a global_ref to `jThis` in a JNI hybrid object leads to a reference cycle which cannot be cleaned up by Java GC. The Java object will keep the C++ object alive and vice versa.
In this class, we didn't seem to need this reference anyway.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D55240490
fbshipit-source-id: 9ba6f5b4b958cb273ad1923332b7b29a75630aea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43613
Storing a global_ref to `jThis` in a JNI hybrid object leads to a reference cycle which cannot be cleaned up by Java GC. The Java object will keep the C++ object alive and vice versa.
We can replace the reference in this class by using the this pointer passed in when `installJSIBindings` is invoked.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D55241235
fbshipit-source-id: 64883752a87f363a52a9f6661d6ddaa24a56fe62
