Summary:
This creates a `debugOptimized` build type for React Native Android, meaning that we can run C++ optimization on the debug build, while still having the debugger enabled. This is aimed at improving the developer experience for folks developing on low-end devices or emulators.
Users that intend to debug can still use the `debug` variant where the full debug symbols are shipped.
## Changelog:
[ANDROID] [ADDED] - Create a debugOptimized buildType for Android
Test Plan:
Tested locally with RNTester by doing:
```
./gradlew installDebugOptimized
```
This is the output of the 3 generated .aar. The size difference is a proof that we're correctly stripping out the C++ debug symbols:
<img width="193" height="54" alt="Screenshot 2025-07-15 at 17 49 50" src="https://github.com/user-attachments/assets/584a0e8d-2d17-40d4-ac29-da09049d6554" />
<img width="235" height="51" alt="Screenshot 2025-07-15 at 17 49 39" src="https://github.com/user-attachments/assets/eda8f9e7-3509-4334-8c16-990e55caa04d" />
<img width="184" height="52" alt="Screenshot 2025-07-15 at 17 49 32" src="https://github.com/user-attachments/assets/a5c94385-bc00-4484-b43e-088ee039827f" />
Rollback Plan:
Reviewed By: cipolleschi
Differential Revision: D78351347
Pulled By: cortinico
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52595
Changelog: [ANDROID][FIXED] Update font scale when recreating `RootView`
At the moment `enableFontScaleChangesUpdatingLayout` flag only works when the activity is configured to handle font scale changes by itself (`configChanges="fontScale"` in the manifest).
When that configuration is missing, the OS handles the font scale changes by recreating the activity, but in this case the path responsible for updating internally kept font size isn't executed.
This diff updates the RootView, so that the display metrics are also updated when it's created. Alternative approach would be to do that on the Activity, but that assumes usage of `ReactActivity`.
Reviewed By: NickGerleman
Differential Revision: D78323174
fbshipit-source-id: e48583091767497b5dfd4f2d938329530de4068d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52668
Changelog: [internal]
These methods have been available for months so no need to consider backwards compatibility with older binaries.
Reviewed By: huntie
Differential Revision: D78412932
fbshipit-source-id: 0f1d541c36c98a4cc8c847d1ee7a08a9d0f4b849
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52678
From partner feedback, there's still appetite to support Node 20.x for the next <1y of life. Lower min version to `20.19.4` (Jul 2025) and widen test matrix in CI.
Changelog:
[General][Breaking] - Our new minimum Node version is Node.js 20 (Overrides #51840)
Reviewed By: cortinico
Differential Revision: D78494491
fbshipit-source-id: c8d9dc6250cb11f8a12ca7e761b65f4a8dae9265
Summary:
In this diff, we migrated IntersectionObserver to tokens: D74262804.
So that we wouldn't have to store shadow nodes on the javascript side.
Storing shadow nodes lead to a memory leak in the past.
Changelog: [internal]
Reviewed By: rubennorte
Differential Revision: D78494075
fbshipit-source-id: 38923ca4b265de6ff81ea20e5649e0bd2e39afc9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52691
Unannotated array literals are unsound in Flow right now. This diff adds in annotations and makes a few things readonly, to reduce future errors.
Changelog: [Internal]
Reviewed By: marcoww6
Differential Revision: D78519638
fbshipit-source-id: d98a7668ecf97bcc87dcb3fad25ade736d885d9a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52686
Enables the `enableVirtualViewRenderState` feature flag by default.
Also, fixed classification for this and the `enableVirtualViewWindowFocusDetection` feature flags. (They were incorrect.)
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D78500846
fbshipit-source-id: 099adaa4ed0026c8bb7438df869564d76a999007
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52685
Cleans up the `scheduleAnimatedCleanupInMicrotask ` feature flag and deletes code paths that are now unreachable.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D78498600
fbshipit-source-id: 307562030373742e64968ae4c92d6bfbb48ddc71
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52684
Cleans up the `disableInteractionManager` feature flag and deletes code paths that are now unreachable.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D78498348
fbshipit-source-id: a3128c1e5ca9c5879080df54b7683a3c916cec13
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52683
Cleans up the `avoidStateUpdateInAnimatedPropsMemo` feature flag and deletes code paths that are now unreachable.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D78497862
fbshipit-source-id: 26406e713ca5b7b194159638a20dcfca877ba380
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52625
Changes `react-native/babel-preset` so that by default, `hermes-parser` is configured with `reactRuntimeTarget: "19"`. This changes the compiled output of Component Syntax to not use `forwardRef` when a `ref` prop is present.
Additionally, this adds a new preset option property, `hermesParserOptions`. This object allows users of `react-native/babel-preset` to supply overrides for any `hermes-parser` options.
Changelog:
[General][Changed] - Configures `react-native/babel-preset` to target React 19 by default, meaning Component Syntax will not compile to `forwardRef` calls when a `ref` prop is present.
[General][Added] - Added support to `react-native/babel-preset` for a `hermesParserOptions` option, that expects an object that enables overriding `hermes-parser` options.
Reviewed By: SamChou19815
Differential Revision: D78383269
fbshipit-source-id: 1e6b66b9bfbeaf8a06fdc39031cb6de7e921765f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52681
Changelog: [internal]
In the original change I made in D78418504 / https://github.com/facebook/react-native/pull/52645 I made 2 mistakes:
1. Used a lock that would try to re-lock on itself without it being recursive (which would cause a deadlock). I didn't see that because when testing I didn't hit the case where we'd exhaust the options.
2. The `attemps` variable wasn't incremented, so we never left the loop in case of exhaustion.
This propagates a flag to `tryCommit` to indicate we've already locked on the commitMutex_ so we don't need to lock again in that case and increases the counter, fixing the issue.
Reviewed By: cortinico
Differential Revision: D78497509
fbshipit-source-id: 546ccd0c84aed5416ce1aef47d79419b4fe06f66
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52680
Changelog: [internal]
Reverting to make the fix easier to pick. Will land again on top.
Original commit changeset: 91d7f5d88a90
Original Phabricator Diff: D78487202
Reviewed By: cortinico
Differential Revision: D78497511
fbshipit-source-id: 58379787786cadcbcbe354feb97bc400a24f9d58
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52679
Changelog: [internal]
Reverting to make the fix easier to pick. Will land again on top.
Original commit changeset: c18e967488de
Original Phabricator Diff: D78480136
Reviewed By: cortinico
Differential Revision: D78497510
fbshipit-source-id: 8037276cb70d27ff695c76cd9575b525568c4489
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52592
Changelog: [Internal] - Expose VirtualViewExperimental in JS, use in a test surface
Reviewed By: yungsters
Differential Revision: D78027899
fbshipit-source-id: d3d9808b8ba8e36c5fdb0c831c0855ed318d0a30
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52590
Changelog: [Internal] - Fix a couple of bugs with VirtualViewExperimental
1. `also` side-effect bug where we were accessing `scrollView` before it was assigned
2. Handling empty `rect`. Now, we don't add the virtualView until it has a non-empty rect layout
Reviewed By: yungsters
Differential Revision: D78287690
fbshipit-source-id: 1806b748a0117e51c7a201191396d79db3a8d205
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52673
We should be incrementing the `attempts` variable as otherwise this loop with never stop.
Created from CodeHub with https://fburl.com/edit-in-codehub
Changelog:
[Internal] -
Reviewed By: rubennorte
Differential Revision: D78487202
fbshipit-source-id: 91d7f5d88a90bdfa806195fd35897f2f51c1deb9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52633
Changelog: [internal]
Now that we have the correct type definition for `console.timeStamp` we can remove the unnecessary `$FlowFixMe` annotations we had to add to use the new arguments.
Reviewed By: hoxyq
Differential Revision: D78405312
fbshipit-source-id: 29378ee6fa5986e22d0dfdfb85b7e25375361dc9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52632
Changelog: [internal]
This improves the type definitions for methods in the global `console` object, most importantly:
- Removes use of `any`.
- Defines correct typing for `console.timeStamp`, including new parameters for the Chrome Extensibility API.
Reviewed By: hoxyq
Differential Revision: D78405314
fbshipit-source-id: 6f31cc3005ff708ef6aa155bcd150d53a845e66c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52631
Changelog: [internal]
Just a small improvement in the type definitions to serve as documentation for the expected arguments for custom tracks in RNDT.
Reviewed By: hoxyq
Differential Revision: D78405313
fbshipit-source-id: 75d250ea27f2e55e172aaf6e72399b85cecd43f4
Summary:
This PR fixes logging of rejections, which stopped working with the transition from using `LogBox` for warnings to directing users to use React Native Debugger, where warnings can be viewed in the `Console` tab.
Rejected promises before this PR used `LogBox.addLog` with the `level: warn` directly without `console.warn`, which notified users to open debugger to view a warning (after rejected promise) without actually printing any warnings to the console.
This PR uses `ExceptionsManager.handleException(error, false /* isFatal */);` for promise rejections that correctly raising an error to the console if needed.
### Rejected Promise in Chrome
Displaying the error as long as it's uncaught in the form:
`Uncaught (in promise) Error`
and if there's a message in that error:
`Uncaught (in promise) Error: ${message}`
once the error is handled, this error disappears:
{F1978806409}
This is done with `Runtime.exceptionThrown`, and `Runtime.exceptionRevoked`:
{F1979815326}
## Changelog:
[General][Breaking] unhandled promises are now handled by ExceptionsManager.handleException, instead of being swallowed as Logbox Warnings.
----
This is a breaking change because we changed the wording for these errors and because some systems (like Sentry) might start monitoring a new set of errors when this code is adopted.
Pull Request resolved: https://github.com/facebook/react-native/pull/51594
Test Plan:
Use `Promise.reject` and observe that the rejection is now shown symbolicated in LogBox and also printed in React Native Debugger Console.
```
<Button
title="Uncaught Promise Rejection"
onPress={() => {
const err = new Error('test error');
err.cause = new Error('cause');
const promise = Promise.resolve().then(() => {
throw err;
// also test with throwing a string / object:
// throw 'aa';
// throw {test: 'object'};
// return Promise.reject();
});
setTimeout(() => {
promise.catch(e => {
console.log('promise error caught', e);
});
}, 4000);
}}
/>
```
### Before
There's no indication whatsoever there's an uncaught promise.
### After
An error is logged:
Error-
{F1979749366}
Text-
{F1979749350}
Object-
{F1979749351}
Promise.reject() or undefined-
{F1979749826}
Reviewed By: hoxyq
Differential Revision: D75442651
Pulled By: vzaidman
fbshipit-source-id: bf6c56e643f03997f5a604b85c543aad62648a29
Summary:
When switching between debug/release we run a small script to make sure to copy the correct version of the RNDeps xcframework.
This script was missing a resolve function that fixed up some path issues that we do when installing in the podspec.
## Changelog:
[IOS] [FIXED] - Fixed issue with RNDeps release/debug switch failing
Pull Request resolved: https://github.com/facebook/react-native/pull/52664
Test Plan:
- Create new RN App
- Install pod with prebuilt deps
- Build (success)
- Switch to release
- Build (success)
Reviewed By: cortinico
Differential Revision: D78481590
Pulled By: cipolleschi
fbshipit-source-id: 2d02b0bc55e8aef6f3fafb4f7aa193c4cf00414e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52662
Changelog: [internal]
In the original change I made in D78418504 / https://github.com/facebook/react-native/pull/52645 I made a mistake and used a lock that would try to re-lock on itself without it being recursive (which would cause a deadlock). I didn't see that because when testing I didn't hit the case where we'd exhaust the options.
This propagates a flag to `tryCommit` to indicate we've already locked on the `commitMutex_` so we don't need to lock again in that case, fixing the issue.
Reviewed By: sammy-SC
Differential Revision: D78480136
fbshipit-source-id: c18e967488de14e73e6abf6f6e82c16bc42a12c6
Summary:
When switching between release/debug we're running a script to copy the correct xcframework. This script for the React-Core prebuilts was not part of the package.json file.
This caused the build to fail after trying to switch from debug -> release.
## Changelog:
[IOS] [FIXED] - Fixed missing script for resolving prebuilt xcframework when switching between release/debug
Pull Request resolved: https://github.com/facebook/react-native/pull/52663
Test Plan:
- Create new RN App
- Install pod with prebuilt deps and core
- Build (success)
- Switch to release
- Build (success)
Reviewed By: cortinico
Differential Revision: D78481302
Pulled By: cipolleschi
fbshipit-source-id: 1c7181e63219098ae140d77ff1cb2c0c9b9642e5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52661
The CI is currently red on main due to a missing dependency on `rrc_view`
from the recent TransformHelper.cpp addition.
This fixes it.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D78479785
fbshipit-source-id: 3d2b698d9ce46cf22c15ad43005f621526590145
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52660
The documentation for those methods mention that users should override them to
provide their own implementation.
However those vals are not `open` so users cannot really override them.
This fixes it.
See more context on https://github.com/facebook/react-native/pull/48800#issuecomment-3082665024
So this was practically a breaking change, that I'm attempting to mitigate.
Changelog:
[Android] [Fixed] - Make accessors inside HeadlessJsTaskService open again
Reviewed By: cipolleschi
Differential Revision: D78479162
fbshipit-source-id: eefc7332e2004198cd6bd64b60a66215f137ad4a
Summary:
Changelog: [Internal]
Adds a basic `--version` command line flag to the RNDT shell. This will be used in code paths (including tests) that need to verify that the shell is executable, but do not need to actually display a window or hand over control to the main shell instance.
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D78351936
fbshipit-source-id: e8982cfea6435da0ac9ea5f50d57c7642a8e2edb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52640
Not having `TransformHelper.cpp` included in CMake is causing the C++ code to fail compiling.
This diff fixes it.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi, javache
Differential Revision: D78414015
fbshipit-source-id: 4900427a86eb38bfec10e5e385296d89c73e9051
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52639
Add feature flag in the attempt to address the pile of tasks reporting the following error in panelapps:
> Error: android_crash:java.lang.AssertionError:com.facebook.react.runtime.ReactHostImpl.onHostPause
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D78339196
fbshipit-source-id: 9ef748e7ea85f179d8f8c418a978bd5c99f70601
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52612
changelog: [internal]
View Culling is purely performance optimisation but it must work correctly with accessibility features like VoiceOver and Switch Control.
In this diff, View Culling is lazily disabled whenever use of an accessibility feature is detected to make sure all views are present in the view hierarchy.
Reviewed By: NickGerleman, philIip
Differential Revision: D78336010
fbshipit-source-id: 7a201afc8e2ffd8b586d75ed4de2c03d7966750c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52604
changelog: [internal]
For Fabric View Culling to work correctly, content offset changes must be applied synchronously to avoid UI flicker.
The flicker happens because content offset update happens asynchronously and the OS paints scroll position update before React Native has a chance to adjust view hierarchy for the new scroll position.
Reviewed By: lenaic
Differential Revision: D78334322
fbshipit-source-id: dc1f1b3f9db9f9547e5a588dc184fcf21cca2727
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52603
Processing transforms is expensive in Java, as it requires bridging the entire ReadableNativeArray/Map. Instead, we can use the existing parser logic `resolveTransform` logic to perform this operation in C++.
Ideally, we actually re-use the existing parsed transform from Props, that could be something we revisit after Props 2.0.
As a follow-up, we should consider also moving the matrix decomposition logic from MatrixMathHelper here, and make that the only information we send back to Java.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D78298588
fbshipit-source-id: a698ac8587ccfb2be04665747082398ccdde9294
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52611
We compare the current transform (represented as a ReadableArray) with the incoming one to know whether to invalidate. This can be expensive as it requires to materialize the entire transform data structure over JNI. Instead, we can delegate this comparison to native code, which can compare the underlying folly::dynamic directly.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D78340288
fbshipit-source-id: f44a054e234694c316fb080fe2dbc2017780123a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52613
Changelog: [internal]
This adds first-class support for the `detail` field in `performance.mark` and `performance.measure`.
Now that we have access the JS entry in native, we can access the `detail` field to propagate it to DevTools (and use it to extract track names for Perfetto).
In order to avoid the performance overhead of always having to extract the `detail` field from the entry, this is done lazily only if we're actively profiling with DevTools or Perfetto.
Reviewed By: sbuggay
Differential Revision: D78340911
fbshipit-source-id: 383dd1cb6fcc8a04be9e65038503986f196e23c9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52614
Changelog: [internal]
We're adding first-class support for custom tracks, so we can remove the legacy mechanism to specify tracks with the "Tracks:" prefix in the event names.
Reviewed By: sbuggay
Differential Revision: D78340910
fbshipit-source-id: cbbadd519baf7bb50072cb97d8cd1ccc87a8a35c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52588
Changelog: [internal]
This adds tests to show how `performance.measure` isn't spec compliant when `end` and `duration` are used. This will be fixed in the following diff.
Reviewed By: javache
Differential Revision: D78193069
fbshipit-source-id: 30ba4874c4d2b4adb20608fc8d5ed61bfd6d92d8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52587
Changelog: [internal]
This just re-organizes the tests for the `Performance` API and `PerformanceObserver` as the previous organization didn't make much sense. Now it's a test for `PerformanceObserver` and another for the User Timing API.
Reviewed By: huntie
Differential Revision: D78193070
fbshipit-source-id: f15524bf07d2dc9edc155214279ce3af705cde67
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52621
In D77261958, I made a typo when implementing the cleanup of window focus detection in `onDetachedFromWindow`. This fixes it.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D78366506
fbshipit-source-id: 2a377cd7e8ec08f0c899dbd9cb3757bec580d30f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52583
Changelog: [Internal]
OSS build is broken atm as there is rn-tester dep in Fantom, needed for Meta only purposes.
Platformizing code to allow for Meta only implementation here and also for OSS only. Using this approach over ifdef.
Reviewed By: christophpurrer
Differential Revision: D78275698
fbshipit-source-id: c3234bb61b4591c0a5045fdb84aa0316f6382ecc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52607
changelog: [internal]
The current design of enableSynchronousStateUpdates is not correct and breaks <Modal /> on Android. let's delete it.
Reviewed By: philIip
Differential Revision: D78332201
fbshipit-source-id: 109909ebc706168372c565e8ff6e0c95d7565b10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52617
The `test-release-local` script was failing to execute the npx rreact-native run-ios command for some issues with cocoapods.
That command tries to reinstall the pods so there might be some issues when testing.
As an alternative, we can avoid duplicated work by dropping the npx react-native command and, instead, build the app with xcodebuild and install it in the simulator with xcrun.
This is a backport of [this PR](https://github.com/facebook/react-native/pull/52609)
## Changelog:
[Internal] -
Reviewed By: vzaidman
Differential Revision: D78344397
fbshipit-source-id: cf2d9c032966a9be05670259e9532789829349f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52618
In 0.81 we dropped the JSC configuration in CI. That means that the artifacts we generate in CI have a slightly different name. The current e2e script failed to run with the ci flag because it was still using the old artifacts name and it was not finding them.
This change adress the problem by:
- using the right artifact names
- removing the --hermes parameter which controlled the Hermes vs JSC scenario.
It is also a port to main of [this PR](https://github.com/facebook/react-native/pull/52606)
## Changelog:
[Internal] -
Reviewed By: cortinico, vzaidman
Differential Revision: D78344244
fbshipit-source-id: a658ba161b867bbad773fe093df9679ea92579b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52584
The method `_initializeUIRefreshControl` creates a new instance of `UIRefreshControl` which has the default values for things like tint color.
However the props that we are keeping in the component are the `_props` before recycling. The actual state of the newly created UIRefreshControl is out of sync w.r.t the props the component thinks to have.
By introducing a `_recycled` state variable, we can force the first `updateProp` call to apply all the props to the newly created component.
## Changelog:
[iOS][Fixed] - Make sure that the recycled refresh control have the right props setup.
Reviewed By: sammy-SC
Differential Revision: D78278207
fbshipit-source-id: 4be20aa43f96eb87828b44a4deedd33a23d1d17f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52615
The refresh control has some issues that this change addresses.
- Issue with zIndex not propagating to RefreshControl.
- Issue when RefreshControl being mounted as refreshing.
- Issue with color props not applied
## Changelog:
[iOS][Fixed] - Correctly propagate props to RefreshControl
Reviewed By: sammy-SC
Differential Revision: D76668478
fbshipit-source-id: c3a5ff04b1b2654d25c9053973c5cff0002a804a
Summary:
We should use indent size 2 everywhere. While we were using 4 for some old reasons. This is causing editing of .kts files and BUCK files inside OSS Android Studio quite painful.
Changelog:
[Internal] -
Reviewed By: cipolleschi
Differential Revision: D78348532
fbshipit-source-id: 97e0e1f54fdc76c8a9cdc44e1f67684c9e97a08f
Summary:
This PR adds the basic `ktfmt` setup in OSS to lint Kotlin files before they're imported into the Meta codebase, making collaboration with external contributors smoother for Android related PRs.
I tried to put together certain rules that mimic the current code style and it seems to work well as I get no errors for properly formatted files but this still might need some input to have the correct configuration.
Added two scripts to the main package.json:
- To check the files format you can run: `yarn lint-kotlin-check`
- To apply formatting fixes, run: `yarn lint-kotlin`
## Changelog:
[INTERNAL] - Kotlin: Set up ktfmt in OSS
Pull Request resolved: https://github.com/facebook/react-native/pull/52064
Test Plan:
Unformat any random Kotlin file inside ReactAndroid and then run:
```sh
yarn lint-kotlin-check
yarn lint-kotlin
```
Reviewed By: cipolleschi
Differential Revision: D78272876
Pulled By: cortinico
fbshipit-source-id: 0cf6b976968dfc5c6c478e88d17eb21c18961a34
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52602
changelog: [internal]
fixes RTL issue in View Culling where scroll view offset was not correctly adjusted for RTL. The example failing case is described in a test.
Reviewed By: lenaic
Differential Revision: D78322759
fbshipit-source-id: d60d98aa45d4d9b576b133990f64ef941e6618e8
Summary:
for IOS and React native windows we can observe that the macro conversion is incorrect in ParagraphProps particularly for selectable prop.
current conversion
```
case ([]() constexpr -> RawPropsPropNameHash { return facebook::react::fnv1a("isSelectable"); }()): fromRawValue(context, value, isSelectable, defaults.isSelectable); return;
```
issue is that isSelectable is not the raw prop therefore JS to native flow for the prop is not correct .
(Note : this works for Android as ReactProp(name = "selectable"): https://github.com/facebook/react-native/blob/bbc1e121c71d14803d29a931f642bf8ea6ee2023/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/text/ReactTextAnchorViewManager.kt#L97-L100 )
fix
```
RAW_SET_PROP_SWITCH_CASE(isSelectable, selectable)
```
Current implementation selectable prop is not working for IOS and React native windows as the macro conversion is incorrect in ParagraphProps particularly for selectable prop.
## Changelog:
Updated ParagraphProps macro conversion for isSelectable , keeping it backward compatible.
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - Fix selectable prop not working correctly
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/52599
Test Plan:
Tested on react native windows playground
Sample code
```
export default class Bootstrap extends React.Component {
render() {
return (
<View style={styles.container}>
<Text style={styles.header}>Selectable vs Non-Selectable Text</Text>
<Text selectable={true} style={styles.text}>
✅ This text is selectable. You can long-press and copy it.
</Text>
<Text selectable={false} style={styles.text}>
❌ This text is not selectable. You cannot copy it.
</Text>
</View>
);
}
}
```
before fix debug output , native unaware of selectable prop values from JS
```
ReactNative ['Samples\text'] (info): ''[Text.js] NativeText _selectable:', true'
ReactNative ['Samples\text'] (info): ''[Text.js] NativeText _selectable:', false'
[ParagraphComponentView] updateProps - old isSelectable: 0, new isSelectable: 0
[ParagraphComponentView] DrawText - isSelectable: 0
[ParagraphComponentView] DrawText - selection logic would be DISABLED here.
[ParagraphComponentView] updateProps - old isSelectable: 0, new isSelectable: 0
[ParagraphComponentView] DrawText - isSelectable: 0
[ParagraphComponentView] DrawText - selection logic would be DISABLED here.
[ParagraphComponentView] updateProps - old isSelectable: 0, new isSelectable: 0
[ParagraphComponentView] DrawText - isSelectable: 0
[ParagraphComponentView] DrawText - selection logic would be DISABLED here.
```
after fix debug output , native picks up selectable prop values from JS correctly
```
ReactNative ['Samples\text'] (info): ''[Text.js] NativeText _selectable:', true'
ReactNative ['Samples\text'] (info): ''[Text.js] NativeText _selectable:', false'
[ParagraphComponentView] updateProps - old selectable: 0, new selectable: 0
[ParagraphComponentView] DrawText - selectable: 0
[ParagraphComponentView] DrawText - selection logic would be DISABLED here.
[ParagraphComponentView] updateProps - old selectable: 0, new selectable: 1
[ParagraphComponentView] DrawText - selectable: 1
[ParagraphComponentView] DrawText - selection logic would be enabled here.
[ParagraphComponentView] updateProps - old selectable: 0, new selectable: 0
[ParagraphComponentView] DrawText - selectable: 0
[ParagraphComponentView] DrawText - selection logic would be DISABLED here.
```
Reviewed By: rozele
Differential Revision: D78333906
Pulled By: javache
fbshipit-source-id: 4d2f9ea591e991b1aed126e9fed72fdfe1a49ce9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52598
Defining this as {50%, 50%} mean we do unnecessary work as part of every transform. Instead set it to undefined, which means we'll ignore it when determining the final transform.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D78298587
fbshipit-source-id: 9d3b7375fc3bd9ea04f0a6d7e314fbba0fba6949
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52601
Changelog: [internal]
Fixes a bug in Fantom when throwing a value that's not an instance of `Error` in a test.
Reviewed By: javache
Differential Revision: D78332756
fbshipit-source-id: 350479dcb7bcea399070c6851aca76a1d1cc2629
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52597
Add a Flow lib def for `memfs`, for use in internal and subsequently Metro tests, now that `metro-memory-fs` is deprecated.
Changelog: [Internal]
Reviewed By: vzaidman
Differential Revision: D78268713
fbshipit-source-id: f714000f2071f4bf45b4436cbd63fc6d74939f98
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52446
The logic for retrieving metrics from a placeholder character is kind of insane, and has been around since inline views were added built into TextView in Paper.
One of the workarounds, for old versions of Android on Samsung phones (no more info to bound the versions) causes incorrect behavior, at least in the case where we have RTL text in LTR layout.
Another, explicitly mentions `singleLine` with RTL para, a deprecated TextView prop, that doesn't apply to us here (and also could never apply to BoringLayout, since RTL chars are not boring).
We don't have these workarounds anywhere else (though we have some other workarounds for bidi crash in old Android), including other frameworks I could find.
Let's bias to cleaning this old code up.
Changelog:
[Android][Fixed] - Fix incorrect positioning of inline view at the end of string when RTL text in LTR container
Reviewed By: javache
Differential Revision: D77703906
fbshipit-source-id: f25a5e2f05100f0288f3889132b658cdabf26f22
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52574
Changelog: [Internal]
The main change here is to catch *all* exceptions in:
- loadScriptFromDevServer
- loadScriptFromBundlePath
so that we can make the `loadScript(...` method `noexcept`
Other methods which only call into `noexcept` methods have been marked with `noexcept` as well
Reviewed By: lenaic
Differential Revision: D78222989
fbshipit-source-id: 174ac2420e88c913662f857c875fef996959c564
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52582
Continues integration of `NetworkReporter` (jsinspector-modern) on Android, to enable the Network panel in React Native DevTools.
NOTE: As with iOS, all changes are gated behind the `enableNetworkEventReporting` and `fuseboxNetworkInspectionEnabled` feature flags.
**This diff**
Updates the Android inputs to `NetworkReporter` to support incremental string data HTTP responses (`Transfer-Encoding: chunked`).
Implemented:
- Incremental response case for `Network.getResponseBody` (fetch response previews).
- `Network.dataReceived` (incremental response update event).
This means that incremental responses, such as Metro bundle requests, can be displayed as previews in React Native DevTools.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D77927896
fbshipit-source-id: 6eff2e7b94d3f784bbc33b1fecdc20242f98b39f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52487
Continues integration of `NetworkReporter` (jsinspector-modern) on Android, to enable the Network panel in React Native DevTools.
NOTE: As with iOS, all changes are gated behind the `enableNetworkEventReporting` and `fuseboxNetworkInspectionEnabled` feature flags.
**This diff**
Integrates `Network.storeRequestBody` on Android (CDP: [`Network.getResponseBody`](https://chromedevtools.github.io/devtools-protocol/tot/Network/#method-getResponseBody) CDP event) to populate the "Preview" and "Response" tabs in the React Native DevTools Network panel.
This is integrated with `NetworkingModule.kt` to support synchronously received `text` or `blob` data types, with incremental response support added next in D77927896.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D77799617
fbshipit-source-id: 495baebbb3b447d1ea86705c1680578eed796d78
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52566
This bumps the plugin we use to publish to Maven Central from 1.3.0 to 2.0.0
as it has better support for the latest Gradle feature.
We're not affected by the breaking changes so we should be good to go (nightlies will tell).
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D78161579
fbshipit-source-id: de5178b2cc17885636f17eabdb0eea4e5b1515dd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51493
Changelog: [IOS][FIXED] Don't retain cached images in state after `RCTImageComponentView` gets recycled
Fixes https://github.com/facebook/react-native/issues/51198
Crosspost from the task comment:
From what I've been able to figure out, it seems like the image shadow nodes (keeping the loaded image in state) are being kept in memory by shadow node reference wrappers. It doesn't seem strictly like a memory leak - manually triggering garbage collection causes those nodes to be deallocated, but since Hermes isn't aware of the memory they are retaining, I think, it doesn't trigger it automatically.
This diff releases the image data when the observers are notified and adds a new (`Consumed`) status to signify that.
Reviewed By: sammy-SC
Differential Revision: D75137263
fbshipit-source-id: 97eda7e6d1ef5cd633c4a5a4c37babc5e08968fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52545
Pull Request resolved: https://github.com/facebook/react-native/pull/51735
This diff refactors the ViewManagerInterfaces codegen to generate kotlin classes,
As a consequence of this change, there are some ViewManagerInterfaces that have changed their APIs
## Changelog: [Android][Breaking] - Migrate ViewManagerInterfaces to kotlin. Some types in code generated ViewManagerInterfaces might differ. e.g. this will start enforcing nullability in parameters of viewManagerInterface methods (e.g. String commands parameters are not nullable, view params are not nullable in any method, etc)
Reviewed By: cortinico
Differential Revision: D78118738
fbshipit-source-id: cdd9e660e55397bd0936efce1c5aaf90c2946b7a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52571
This diff fixes the following warning:
```
The corresponding parameter in the supertype 'XYZViewManager' is named 'value'. This may cause problems when calling this function with named arguments.
```
changelog: [Android][Changed] Changed method arguments names for Core ViewManagers to match the names of ViewManagerInterfaces
Reviewed By: cortinico
Differential Revision: D78170316
fbshipit-source-id: 29a2611eabb4e260bd6126aeca95516912ea4b4d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52485
Begins integrating `NetworkReporter` (jsinspector-modern) on Android, to enable the Network panel in React Native DevTools.
Since the larger lift of initial setup and the C++ subsystem has been done for iOS, this will be a lighter stack of changes solely setting up necessary integration points in the Android Networking stack.
NOTE: As with iOS, all changes are gated behind the `enableNetworkEventReporting` and `fuseboxNetworkInspectionEnabled` feature flags.
**This diff**
Initially integrates the `NetworkReporter` methods corresponding to the `Network.requestWillBeSent`, `Network.requestWillBeSentExtraInfo`, `Network.responseReceived`, `Network.loadingFinished` CDP events, which are sufficient for populating a minimally rendered Network request list.
- Create JNI `InspectorNetworkReporter` helper class (may also become the later public API for 3P reporting into the `Network` domain).
- Renames `ResponseUtil.kt` as `NetworkEventUtil.kt`.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D71897099
fbshipit-source-id: 90972a5bfa34a095252b7e745e5f4afeb53b0ebe
Summary:
Bump Metro to 0.83.0.
This release contains some breaking changes for integrators, and a minimum Node.js version of 22.14.
Full release notes: https://github.com/facebook/metro/releases/tag/v0.83.0
Changelog: [General][Changed] Bump Metro to ^0.83.0
Test Plan:
Imported from GitHub, without a `Test Plan:` line.
Rollback Plan:
Differential Revision: D78171925
Pulled By: robhogan
fbshipit-source-id: 7ea5e04d285632a14dd71ba00da872d60f283840
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52572
We'd like to stop supporting `metro-memory-fs` - there are better alternatives out there.
This replaces the one usage of `metro-memory-fs` in `react-native` with `memfs`, and swaps the dependency.
Changelog: [Internal]
Reviewed By: vzaidman
Differential Revision: D78161921
fbshipit-source-id: 139233adac413a4f47a0d56d9e08ec841abaf47c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52543
Prefixing "eager" to the name makes it less confusing. React native already has main queue modules: they're just lazy.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D78109287
fbshipit-source-id: 5fa6095d2dd8fcf74fdda64e05483eb487bc8f56
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52544
Let's remove these runtime errors for now. We can re-introduce this later, if needed.
Main queue coordinator will make "unsafe execute on main queue sync" not deadlock.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D78109286
fbshipit-source-id: 7c3acc2e560e341889d8ede4665bc70fefc2f058
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52570
JSONArguments is a set of utility methods that are not part of the legacy architecture, removing the annotation.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D78168536
fbshipit-source-id: 25fcc41441df6c71f9a96ec0ba82c42e8f6af80c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52564
Currently, `metro-babel-register` has a function as its default export, to which we've tagged on various properties.
This tidies that up to a more idiomatic object of named exports, with `register` as a new one of them.
This also serves to make it more compatible with automatic TypeScript generation.
This is semver breaking, but `metro-babel-register` has very little usage outside Meta projects so isn't expected to be disruptive.
Changelog: [Internal]
Metro changelog:
```
- **[Breaking]**: Move metro-babel-register's main function to a named export `register`
```
Reviewed By: huntie
Differential Revision: D78157559
fbshipit-source-id: c59c9820e9895007345561fed9ccec2273b925c8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52561
The removed code comment is pretty clear that this workaround is in place for a specific bug, which was closed in a Node.js 8.x minor: https://github.com/nodejs/node/issues/13391
A related issue descibed a problem that still existed in Node 10:
https://github.com/nodejs/node/issues/27363
Subsequent comments reporting problems with newer Node.js versions all seem to relate to mismatched configuration with load balancers, not directly relevant to Metro.
Reproducers for the original bugs no longer repro on new Node.js (tested with 22.14), so I think it's safe to conclude this is fixed.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D78158427
fbshipit-source-id: 0be5dbc4334ac7b0bbccde44a840caac43deb4df
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52548
Changelog: [Internal]
While this does not cause real crashes as the code is already gated via
```
bool haveRHS = j < rhs.operations.size();
```
it still represents a bug in the logic
Reviewed By: rshest
Differential Revision: D78133364
fbshipit-source-id: 80efc97b5174e3d0d7efe33604255a96bc856e87
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52565
When we implemented caching in prebuilds for RN core for iOS, we were naïve in choosing the cache key. The current cache key does not consider the source code that is built and this can be problematic.
Imagine a contributor that changes a file in a React folder in their PR, but CI reuses a binary created from `main` and so everything will work well in CI even if the change contains an error.
This change globs over the header and implementation files in the React, ReactCommon and Libraries folder to ensure that we rebuild the code when iOS code changes.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D78161427
fbshipit-source-id: e612b76232308835eb88c3776122bebd1316f751
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52560
Changelog: [internal]
This migrates the profiling logic for `XMLHttpRequest` from `performance.measure` to `console.timeStamp` with built-in support for tracks.
Reviewed By: hoxyq
Differential Revision: D78157407
fbshipit-source-id: 0ef060557a00e7973ef7f0478b26b81471d38226
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52542
Changelog: [internal]
This adds support to propagate performance entries logged to `console.timeStamp` to Perfetto, if enabled. It also modifies the Perfetto integration to support track groups, in addition to track names.
Reviewed By: hoxyq
Differential Revision: D78092596
fbshipit-source-id: 76b0fe2738d856fd75ee941de223d6a6a73d8e1c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52535
Those constructors are no longer necessary. They're deprecated + the class is internal so they're not breaking changes.
I'm just cleaning them up as they're not needed anymore.
Changelog:
[Internal] [Changed] - Remove deprecated constructors for TextInput *Event classes
Reviewed By: javache
Differential Revision: D78095748
fbshipit-source-id: 2dc6c750f8470a88918d8a69b68364f38251d79e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52562
This change use the prebuilds we build in CI i other iOS jobs to speed-up the iOS CI
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D78159367
fbshipit-source-id: 64486c99fdbc54487dbcff786209cacac304b9b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52563
The test_ios_rntester_dynamic_frameworks is identical to the test_ios_rntester but for the framework parameter.
This change unifies the two, using a matrix to test all the configurations:
- Debug / Static Libraries
- Release / Static Libraries
- Debug / Dynamic Frameworks
- Release / Dynamic Frameworks
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D78159366
fbshipit-source-id: b321f295477fe3ae6e43c7518d47afb0714bddb8
Summary:
This change tries to use the prebuilds we build in CI i other iOS jobs to speed-up the iOS CI
bypass-github-export-checks
## Changelog:
[Internal] -
Pull Request resolved: https://github.com/facebook/react-native/pull/52531
Test Plan:
Build rntester using prebuilds:
```
# after downloading the prebuilds from CI and unzipping them
export HERMES_ENGINE_TARBALL_PATH=~/Downloads/hermes-ios-Debug.tar.gz
export RCT_USE_LOCAL_RN_DEP=~/Downloads/reactnative-dependencies-debug.tar.gz
export RCT_TESTONLY_RNCORE_TARBALL_PATH=~/Downloads/React.xcframework.tar.gz
USE_FRAMEWORKS=dynamic bundle exec pod install
open RNTesterPods.xcworkspace
```
And then build from Xcode.
Reviewed By: rshest
Differential Revision: D78158734
Pulled By: cipolleschi
fbshipit-source-id: 43cbb66bd44fa621292b69de0dadde5ed20c4574
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52549
Changelog: [Internal]
- The #includes are not used
- `enum class` is C++, (enum is C)
Reviewed By: rshest
Differential Revision: D78135339
fbshipit-source-id: 1a35301ea063ce17c195be7dc373132d342f111a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52556
Changelog: [internal]
This adds a new benchmark for `performance.measure` to measure the performance of calling it without arguments.
Reviewed By: hoxyq
Differential Revision: D78013563
fbshipit-source-id: 84e2151d9d91cfc2e85d310f42010483e7304648
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52557
Changelog: [internal]
`PerformanceEntry.detail` should be `null` if not defined, not undefined as it is currently. This fixes that.
Reviewed By: hoxyq
Differential Revision: D78013568
fbshipit-source-id: b22dfdd8d582594fc1e5199264e8af92c26bb0ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52558
Changelog: [internal]
Small refactors for `$ReadOnly`, move `getCurrentTimeStamp` to utils so it can be reused, etc.
Reviewed By: hoxyq
Differential Revision: D78013570
fbshipit-source-id: f73d119f22dd4dc9aaa5efef76a1156821ecd8de
Summary:
Resolves https://github.com/microsoft/react-native-windows/issues/14797
We were facing a type conversion error in the DynamicEventPayload::extractValue() method. The function signature declares a return type of std::optional<double>, but when handling INT64 values, but when handling `INT64` values, the code was directly returning `dynamic.asInt()` without proper type conversion
We faced the issue while integrating https://github.com/microsoft/react-native-windows/pull/14791
## Changelog:
[General][Fixed]
Pull Request resolved: https://github.com/facebook/react-native/pull/52525
Test Plan:
The fix involved wrapping the dynamic.asInt() call with static_cast<double>(), creating the corrected line: return static_cast<double>(dynamic.asInt())
Tested E2E in RNW
Reviewed By: andrewdacenko
Differential Revision: D78083842
Pulled By: rshest
fbshipit-source-id: 8dbedd67fa7c21e89b863d8b1bc7b9e0d7978b9f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52530
This PR fixes two issues with `display: contents` implementation:
1. When a node with `display: contents` set is a leaf, it won't be cloned after the initial tree is built. The added test case covers this scenario.
2. It was possible for the subtree of `display: contents` nodes not to be cloned during layout. I don't have a minimal reproduction for this one, unfortunately. It was discovered in the Expensify app: https://github.com/Expensify/App/issues/65268, along with a consistent reproduction. In that specific case, it seems to be heavily tied to `react-native-onyx`, which is a state management library.
Changelog: [GENERAL][FIXED] - Fixed nodes with `display: contents` set being cloned with the wrong owner
X-link: https://github.com/facebook/yoga/pull/1826
Reviewed By: adityasharat, NickGerleman
Differential Revision: D78084270
Pulled By: j-piasecki
fbshipit-source-id: eb81f6d7dcd1665974d07261ba693e2abea239bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52532
Since we updated TypeScript in https://github.com/facebook/react-native/pull/51831, ESLint has printed a warning that `typescript/eslint` doesn't support our TS version.
This updates it to fix the warning.
Changelog: [Internal]
Reviewed By: vzaidman
Differential Revision: D77833826
fbshipit-source-id: 29a5179c4f223a8cc0ab2c8071f0a5efa09e5edc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52533
This method is deprecated in the JavaDoc but not correctly annotated as Deprecated, let's fix it.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D78092468
fbshipit-source-id: 31e4cb958a51b20f5105a4bec3366d67402e5419
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52528
This was a breaking change that is currently breaking `react-native-safe-area-context` so we can't ship it as it is, especially because all the apps in OSS will be affected by this.
Changelog:
[General] [Changed] - Revert breaking change due to the removal of `ShadowNodeTraits::Trait::DirtyYogaNode`
Original commit changeset: 869e81f0ae00
Original Phabricator Diff: D75324251
Reviewed By: huntie
Differential Revision: D78085848
fbshipit-source-id: f7fcc5e33d59cc966a4ee88dfdbedca4f4c580e0
Summary:
This PR fixes the following build error while trying to build `react-native@0.81.0-rc.0` app with `react-native-screens@4.10.0` installed using react-native prebuilds (AAR) due to a missing `react/renderer/bridging/bridging.h` file in `prefab/modules/` inside `react-android-0.81.0-rc.0-debug.aar`.
```
In file included from /Users/tomekzaw/RNOS/react-native-reanimated/node_modules/react-native-screens/android/src/main/cpp/NativeProxy.cpp:2:
In file included from /Users/tomekzaw/.gradle/caches/8.14.1/transforms/75e7f8f7b5ef763e687a16737daf01b6/transformed/react-android-0.81.0-rc.0-debug/prefab/modules/reactnative/include/react/fabric/Binding.h:12:
In file included from /Users/tomekzaw/.gradle/caches/8.14.1/transforms/75e7f8f7b5ef763e687a16737daf01b6/transformed/react-android-0.81.0-rc.0-debug/prefab/modules/reactnative/include/react/fabric/FabricUIManagerBinding.h:22:
/Users/tomekzaw/.gradle/caches/8.14.1/transforms/75e7f8f7b5ef763e687a16737daf01b6/transformed/react-android-0.81.0-rc.0-debug/prefab/modules/reactnative/include/react/renderer/uimanager/primitives.h:14:10: fatal error: 'react/renderer/bridging/bridging.h' file not found
14 | #include <react/renderer/bridging/bridging.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
ninja: build stopped: subcommand failed.
```
## Changelog:
[ANDROID] [CHANGED] - Expose `react_renderer_bridging` headers via prefab
Pull Request resolved: https://github.com/facebook/react-native/pull/52529
Reviewed By: cipolleschi
Differential Revision: D78092428
Pulled By: cortinico
fbshipit-source-id: de8208ae7545201f600c277a0c8907575c310c58
Summary:
Fixes #T228219721
This commit adds the debug/release switch script like we have for rn deps and hermes for react-core prebuilt:
- Added script: replace-rncore-version-js
- Inserted script into React-Core-prebuilt podspec
- Updated rncore.rb with correct filenames
bypass-github-export-checks
## Changelog:
[IOS] [ADDED] - add release/debug switch script for React-Core-prebuilt
Pull Request resolved: https://github.com/facebook/react-native/pull/52498
Test Plan: Run in RNTester and switch between release/debug
Reviewed By: rshest
Differential Revision: D78012917
Pulled By: cipolleschi
fbshipit-source-id: 71cad23cd41484a8253fc89d5dce8653649657a0
Summary:
Instead of returning when creating the list of header files from our podspecs, we now call `continue`. This is a bug that causes all subsequent globs in the header file list to be omitted after the first omitted glob.
bypass-github-export-checks
## Changelog:
[IOS] [FIXED] - Fixed premature return in header file generation from podspec globs
Pull Request resolved: https://github.com/facebook/react-native/pull/52490
Test Plan: Run prebuild scripts and verify that React-Fabric podspec headers are included in the resulting xcframework.
Reviewed By: mdvacca
Differential Revision: D78012399
Pulled By: cipolleschi
fbshipit-source-id: 2d334f4f7ff966ea4c778786a7056e13a255a708
Summary:
When using prebuilts the USE_FRAMEWORKS setting is not really relevant for the React Native code, since there will not be any source code to build frameworks for - and because we already have a framework for the code in React.XCFramework.
This commit adds a new command to the React Native podspecs like we did with the ReactNativeDependencies framework. The method is called `add_rncore_dependency` and it does nothing when building from source - but when linking with the React.XCFramework it explicitly adds linking with the framework.
In addition there are a few places in the ruby code where we check for the USE_FRAMEWORK value and changes some settings - where needed this commit will add a separate check to ensure we're building from source when making these changes.
bypass-github-export-checks
## Changelog:
[IOS] [ADDED] - Added support for using USE_FRAMEWORKS with prebuilt React Native Core
Pull Request resolved: https://github.com/facebook/react-native/pull/52489
Test Plan:
RNTester:
- Builds without USE_FRAMEWORKS as before with/without prebuilt
- Builds with USE_FRAMEWORKS=dynamic as before with source - and now also with prebuilt code.
- Same goes for the static variant.
Reviewed By: mdvacca
Differential Revision: D78012332
Pulled By: cipolleschi
fbshipit-source-id: ea942738ae52b9dceae48fb78a5026f04b7545b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52519
Changelog: [Internal] - Experiment with intersection logic for VirtualViews in scrollView. Currently only on Android
### Changes in detail
`VirtualViewContainer` is held by the ScrollView and is lazily instantiated once a VirtualView tries to access.
Upon initial layout, a VirtualView will add itself to the container and report its updated `rect`. `VirtualViewContainer` holds a sorted list of VirtualViews and iterates through them to update mode
Reviewed By: yungsters
Differential Revision: D77313890
fbshipit-source-id: 30843143bf1828dcac9091479964e83934bf330c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52521
Progress is moving quickly on the cxxNativeAnimatedEnabled flag, which this animatedShouldSignalBatch was intended to de-risk. We no longer need this flag to de-risk issues with animated batch flushing.
## Changelog
[Internal]
Reviewed By: christophpurrer
Differential Revision: D78005971
fbshipit-source-id: 719f1dfb0594fbe90dd6f08dea21ad20665832df
Summary:
accessibilityRole is not getting the default value from sourceProps.
This change will fix https://github.com/facebook/react-native/issues/52396
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Fixed accessibilityRole parsing.
Pick one each for the category and type tags:
[GENERAL] [FIXED] - Added fix for setting the default value for accessibility props
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/52397
Test Plan: After this change accessibilityRole will get the default value from sourceProps.
Reviewed By: joevilches
Differential Revision: D77879025
Pulled By: NickGerleman
fbshipit-source-id: c2fd10dd34462e2cd01488b720ba91e4f1998000
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52474
1. Enables the feature flags for fragment refs on fbsource
2. Adds a test with Fantom for usage of `FragmentInstance#observeUsing` and `FragmentInstance#unobserveUsing`.
3. Exposes the `ReactFragmentInstance` type with the common methods that are used on native. We can override the DOM only methods in www libdefs.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D74326262
fbshipit-source-id: e35ee45b23179ad3ba5527763567c9b04c127eff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52514
As per title, this change add the `ENTERPRISE_REPOSITORY` env variable so that users can use their owm maven mirror to consume artifacts rather than the official url.
This is helpful as:
- we can reduce the traffic toward maven central
- companies can speed up their builds by relying on local/closer replicas
## Changelog:
[iOS][Added] - Add the `ENTERPRISE_REPOSITORY` env variable to cocopaods infra
Reviewed By: cortinico
Differential Revision: D78011424
fbshipit-source-id: 24b83b4866095d7fe3318362afc5075b99b146e7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52511
# Changelog: [Internal]
This is actually used in React for logging triggers, like Mount / Unmount / Reconnect / Disconnect.
Reviewed By: huntie
Differential Revision: D78008351
fbshipit-source-id: 9d39d45da499ce78172531c00cc7465b985c2646
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52494
Changelog: [Internal]
- Use C++ private namespace instead of C static methods
- Strongly type C++ TM functions via AsyncCallback
Reviewed By: javache
Differential Revision: D77978354
fbshipit-source-id: 2274b95cfc5b65392fc3c808bbdf54ec4ab3a37e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52512
The way Maven works is that the artifacts are uploaded and available way before the browsing UI will allow us to browse them.
By trying to download the `.pom` file instead of checking for the browsing website to be visible, we can shave some minutes during the release
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D78008635
fbshipit-source-id: 96516163628d6d25db385d996a11b4af78db764a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52513
We bumped the requirement for cocoapods to use Xcode 16.1 or greater.
This job was not update and therefore it failed when releasing 0.81.0-rc.0.
This change should fix it and it should be cherry picked in the release branch too.
By default, the macos executor in github actions are using Xcode 15.2
## Changelog
[Internal] -
Reviewed By: cortinico, fabriziocucci
Differential Revision: D78008316
fbshipit-source-id: 4d05233ca3b936cf128400030328124c453963ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52509
When building the CI Workflow to build React Native prebuilds, we were reading the react-native's version from the root package.json. This package.json is not updated by the release script, so the version is always 1000.
This makes the build process fail for stable releases.
With this change, we read the version from the right package.json file
## Changelog:
[Internal] - Read React Native version from the right package.json file
Reviewed By: cortinico
Differential Revision: D78007906
fbshipit-source-id: 35f868a1c203245fdcf518ee81957352e3ab1de7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52505
changelog: [internal]
there is a race condition where `startRenderCallbackIfNeeded` may be called from JS thread and the main thread at the same time, leading to a crash. To address this, this diff adds uses a boolean to make sure `startOnRenderCallback_` is only called once and `stopOnRenderCallback_` is only called after start was called.
Reviewed By: javache
Differential Revision: D77871230
fbshipit-source-id: 6d7fba596e7146adaff6f8dbe1f436ddd59950c6
Summary:
Resolves https://github.com/microsoft/react-native-windows/issues/14666
We faced this issue while integrating [0.79.0-nightly-20250220-41b597c73](https://github.com/microsoft/react-native-windows/pull/14662/files#top)
This warning is treated as error and should be fixed here as well.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[GENERAL] [FIXED] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/52496
Test Plan:
Fixed error:
##[error]node_modules\react-native\ReactCommon\react\renderer\css\CSSHexColor.h(39,12): Error C4244: 'return': conversion from 'int' to 'uint8_t', possible loss of data
2>D:\a_work\1\s\node_modules\react-native\ReactCommon\react\renderer\css\CSSHexColor.h(39,12): error C4244: 'return': conversion from 'int' to 'uint8_t', possible loss of data [D:\a_work\1\s\vnext\Microsoft.ReactNative\Microsoft.ReactNative.vcxproj]
(compiling source file '../../node_modules/react-native/ReactCommon/react/renderer/components/view/BaseViewProps.cpp')
Tested E2E in RNW
Reviewed By: javache
Differential Revision: D78000818
Pulled By: rshest
fbshipit-source-id: 5caafc5e92540f722b009480f030276e526355af
Summary:
This is a backport of a fix we applied to the 0.81 branch.
Changelog:
[Internal] [Changed] -
bypass-github-export-checks
Reviewed By: vzaidman
Differential Revision: D78000573
fbshipit-source-id: 64a4e90632158c1f52c45f9fbc3452e848271e94
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52473
Shared utils that were located in the root of `scripts/` are now colocated closer to their dependencies or moved to `scripts/shared/` — simplifying the root directory layout.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D77873875
fbshipit-source-id: e04dba41a1ef811d32793931033fdfa93afad0cd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52441
When an error is thrown using `handleHostException` from within the (immediate) execution of a `Task`, the `Task` will capture the error. If those errors are never consumed, the error is just silently swallowed. Instead we should make sure that this is raised outside of the context of a `Task` so the error correctly bubbles up and crashes the app (in release).
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D77798248
fbshipit-source-id: 41803aba0cace0e364a235501cf34bb946e7ff51
Summary:
This came out of https://github.com/facebook/react-native/issues/52457 as I had to fix some tests and realised there is a lot of setup that could be shadow and other things that are not needed at all.
## Changelog:
[INTERNAL] - Clean up unnecessary test setup for Android tests
Pull Request resolved: https://github.com/facebook/react-native/pull/52471
Test Plan:
```sh
yarn test-android
```
Reviewed By: cortinico
Differential Revision: D77926887
Pulled By: javache
fbshipit-source-id: ff493d87633fcb4c4194b50cd374ad2e8acda974
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52483
Changelog: [internal]
This is a small refinement for `performance.mark` and `performance.measure` to use `structuredClone` to copy the value of the `detail` field, instead of assigning it by reference.
This still doesn't completely fix the semantics of `performance.mark` and `performance.measure`, as the entries returned by those methods aren't referentially equal to the entries reported by `PerformanceObserver` (and the latter don't have the `detail` field yet).
Reviewed By: huntie
Differential Revision: D77863037
fbshipit-source-id: 54d959612ecd560250e49bb0887bb12112a0142f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52476
Changelog: [Internal] - Refactor package structure on Android to prepare for experimental VirtualView so that non-view related objects go under `virtual` and the native view goes under `view`.
This breaks dependency circles for experimental VirtualView in upcoming change.
Reviewed By: yungsters
Differential Revision: D77335426
fbshipit-source-id: 3b978e9cc5ad376c71aebc039cfc74d2515d2cfa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52470
These metrics are not actively consumed and are highly noisy.
Changelog: [Android][Removed] Deprecated MessageQueueThreadPerfStats API and replaced with stub.
Reviewed By: cortinico
Differential Revision: D77867087
fbshipit-source-id: 8bf7423ad60cb3bb21a5dbe94771d5a71832633d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52399
I'm raising the deprecation warnings for those methods that are using legacy arch.
Previously the `DeprecatedInNewArchitecture` was not generating warnings for user in their builds, while now the Kotlin's/Java's `DeprecatedInNewArchitecture` it will.
Changelog:
[Android] [Changed] - Introduce more deprecation warnings for Legacy Arch classes
Reviewed By: mdvacca
Differential Revision: D77736713
fbshipit-source-id: bc21729ed8253d3ec6b6a40577bcd76622c3f8a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52442
Changelog: [Internal]
The sample is from an outdated approach of enabling C++ Modules in RN which is not recommended anymore.
Prefer C++ Turbo Modules if you need to expose / access C or C++ APIs in RN apps:
https://reactnative.dev/docs/the-new-architecture/pure-cxx-modules
It is not included in any RNTester app at this time
Reviewed By: cortinico
Differential Revision: D77771111
fbshipit-source-id: a4fe1d13fd0224babc46f54b921a036f7b237a48
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52401
changelog: [internal]
- Mark ShadowNode::ListOfWeak as deprecated with appropriate deprecation message
- Replace all usages of ShadowNode::ListOfWeak with std::vector<std::weak_ptr<const ShadowNode>>
- Updated primitives.h and ReactNativeCPP.api to use the explicit type instead of the alias
This change continues the effort to remove type aliases in favor of explicit standard library types for better code clarity and maintainability.
Reviewed By: christophpurrer
Differential Revision: D77652083
fbshipit-source-id: 79cad019e039c19f661346604ff49a44a4af7a79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52465
Changelog: [internal]
Now that we have enough coverage for the Performance API in Fantom, Jest tests where most of the API is mocked are redundant and useless, so this removes them (and the mock).
Reviewed By: huntie
Differential Revision: D77860888
fbshipit-source-id: 7dbd1a8a43b056a3b34e4e37d578be9ccb521824
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52462
Changelog: [internal]
This adds a few more tests for `performance.getEntries`, `performance.getEntriesByName` and `performance.getEntriesByType`.
Reviewed By: huntie
Differential Revision: D77801746
fbshipit-source-id: 42f80c4e2b787c455b149ee38d071511181532b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52431
Changelog: [internal]
`performance.measure` supports passing mark names as `start` and `end` options, so this fixes the Flow type before fixing the actual implementation.
It also makes it so you can't specify both `end` and `duration`, enforced by the type system.
Reviewed By: huntie
Differential Revision: D77795991
fbshipit-source-id: e89f509c7efc2fa49d17d79bc19bc1d14e007871
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52432
Changelog: [internal]
This creates a battery of tests for `performance.mark` and `performance.measure`. For this, it was necessary to add a new method in the native module to mock the current time.
Many of the tests are currently failing, as the API doesn't support all the options or behaviors defined in the spec. They're skipped here and will be re-enabled and fixed in a following diff.
Reviewed By: huntie
Differential Revision: D77795989
fbshipit-source-id: 3ebf18c8ac336df1fb43003a55a4678b52e8982d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52402
changelog: [internal]
Mark ShadowNode::ListOfShared as deprecated and replace most usages throughout the React Native renderer codebase with the explicit std::vector<std::shared_ptr<const ShadowNode>> type. This improves code clarity by making the container type explicit rather than relying on a type alias.
Reviewed By: christophpurrer
Differential Revision: D77651676
fbshipit-source-id: 8c4bd9b8cbbe467384b947ef9e7a4524f2053e36
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52412
Changelog: [Internal]
The sample is from an outdated approach of enabling C++ Modules in RN which is not recommended anymore.
Prefer C++ Turbo Modules if you need to expose / access C or C++ APIs in RN apps:
https://reactnative.dev/docs/the-new-architecture/pure-cxx-modules
It is not included in any RNTester app at this time
Reviewed By: cortinico
Differential Revision: D77770455
fbshipit-source-id: 987c9f2b9ab4145a2f6a724aad12d8473957dbe8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52407
Changelog: [Internal]
The sample is from an outdated approach of enabling C++ Modules in RN which is not recommended anymore.
Prefer C++ Turbo Modules if you need to expose / access C or C++ APIs in RN apps:
https://reactnative.dev/docs/the-new-architecture/pure-cxx-modules
Reviewed By: javache
Differential Revision: D77765443
fbshipit-source-id: 112fef4c1a7e1c567f3c1d471728a1dfc926adc6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52388
Changelog: [Internal]
Similar to `AsyncCallback<>` (the foundation of `AsyncPromise`) we should allow `void` Promise types in C++ such as `AsyncPromise<>`
Reviewed By: rbergerjr
Differential Revision: D77712020
fbshipit-source-id: d7360df5cc1b77f1e03e5fb73b0b468f6e3a415b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52456
Remove the last use of a Metro deep import in preparation for making all deep imports semver-private.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D77450110
fbshipit-source-id: de7aa9c1f6b0d281fe8a6c3bd95e721c5bb58c63
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52438
Motivation: After some investigation, these make sense as private APIs, and we intend to modify `UriHandler` slightly in order to report blob response body payloads via CDP for Network debugging.
Changelog:
[Android][Removed] - Internalize `NetworkingModule`'s `UriHandler`, `RequestBodyHandler`, and `ResponseHandler` APIs
Reviewed By: cortinico
Differential Revision: D77799144
fbshipit-source-id: 20c36f52a900830091a253ab9917832c30b31d31
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52436
Reordered the different property types in the switch/case to group similar outputs together.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D77799101
fbshipit-source-id: 5b7c6d188e9ffa0f1e41f44f82f438afeda04d74
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52439
Users should not be passing true/false values for the 3 params in the `load()` method. The app template already uses the no param overload.
I'm deprecating it so it can go in 0.81.
Changelog:
[Android] [Changed] - Deprecate the DefaultNewArchitectureEntryPoint.load(Boolean, Boolean, Boolean)
Reviewed By: rubennorte
Differential Revision: D77739268
fbshipit-source-id: c901d1ed2e9623b0fa39f4e2d79f25404c284b8d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52427
Adds and wires up a minimal implementation of `PerformanceResourceTiming` on the JS side. This materialises D74245441 in user space.
When all feature flags are enabled, network requests can now be observed from JS via `PerformanceObserver`.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D75062713
fbshipit-source-id: 06523e70f57feaaa53432ef21fa92676d1e90360
Summary:
reverting Refactor ViewManagerInterfaces codegen to generate kotlin classes because of warning in OSS, we will reland after 0.81 cut
Changelog: [Android][Breaking] - Revert of Migrate ViewManagerInterfaces to kotlin. Some types in code generated ViewManagerInterfaces might differ. e.g. this will start enforcing nullability in parameters of viewManagerInterface methods (e.g. String commands parameters are not nullable, view params are not nullable in any method, etc)
Reviewed By: lenaic, mlord93
Differential Revision: D77759777
fbshipit-source-id: c24b216b231cdc53296d8c9fca8d789d80daa596
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52393
## Changelog:
[General][Deprecated] - ShadowNode::Shared is now deprecated. Use `std::shared_ptr<const ShadowNode>` instead.
- Mark ShadowNode::Shared as deprecated in ShadowNode.h
- Replace all uses of ShadowNode::Shared with std::shared_ptr<const ShadowNode>.
This continues the systematic effort to remove ShadowNode type aliases in favor of explicit standard library types for improved code clarity and maintainability.
Reviewed By: christophpurrer
Differential Revision: D77650696
fbshipit-source-id: b4769e2a1e39f49d14d5927be105487ecf69fa3f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52405
This field has been deprecated since RN 0.77, we can safely remove it ahead of the branch cut.
Changelog:
[Android] [Removed] - Remove deprecated `isStartSamplingProfilerOnInit` from `DeveloperSettings`
Reviewed By: mdvacca, javache
Differential Revision: D77734913
fbshipit-source-id: 231ecb360921d48ec941a3a214e73b4b89446c13
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52395
This method was exposed as `public` but there is no need for us to expose it in OSS.
So I'm marking it as internal.
Changelog:
[Internal] [Changed] - Make loadWithFeatureFlags correctly internal
Reviewed By: mlord93, mdvacca, javache
Differential Revision: D77734270
fbshipit-source-id: 34e1d7aaa4a5bf3563c78aad570e2310592bcc77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52382
Changelog: [Internal]
In C++, both `virtual ~CallInvoker() {}` and `virtual ~CallInvoker() = default` can be used to define a virtual destructor. However, they have slightly different implications:
1. `virtual ~CallInvoker() {}`:
* This is the traditional way of defining a virtual destructor.
* It provides an empty implementation for the destructor, which does nothing.
* The compiler will not generate a default implementation, as you've provided one explicitly.
2. `virtual ~CallInvoker() = default`:
* This is a more modern way of defining a virtual destructor (introduced in C++11).
* It tells the compiler to generate a default implementation for the destructor.
* The default implementation will perform the necessary cleanup operations, such as calling the destructors of base classes and member variables.
In general, `= default` is considered better because it:
* Avoids unnecessary code duplication: By letting the compiler generate the default implementation, you avoid duplicating code that's already generated by the compiler.
* Improves maintainability: If the class has member variables or base classes with non-trivial destructors, using `= default` ensures that the correct cleanup operations are performed without requiring manual updates.
* Conveys intent: Using `= default` clearly indicates that the destructor should perform its default behavior, making the code easier to understand.
So, unless you have a specific reason to provide a custom implementation, `virtual ~CallInvoker() = default` is generally the better choice.
Reviewed By: rshest
Differential Revision: D77685932
fbshipit-source-id: 78c81f8e400069ad38d8d7405dafeb0b6db8e67b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52347
We can build an accessibility tree for Talkback by overriding addChildrenForAccessibility of ViewGroup.
With this we just manually build a tree that contains the elements we care about in the order we want.
We also try to keep most of the tree intact so that coopting works properly
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D77258926
fbshipit-source-id: 767ebc880a2efbf7934b9e7dee3013dd7822e5ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52297
Doing virtual views is the only way of making it possible to add the host view into the order. This however is too complex for very little gain, we are opting to go for a cleaner solution with the trade off of not being able to add the host view.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D77278752
fbshipit-source-id: 709b995f51a9a03f6d07f2e24f8aea21d62d95c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51735
This diff refactors the ViewManagerInterfaces codegen to generate kotlin classes,
As a consequence of this change, there are some ViewManagerInterfaces that have changed their APIs
## Changelog: [Android][Breaking] - Migrate ViewManagerInterfaces to kotlin. Some types in code generated ViewManagerInterfaces might differ. e.g. this will start enforcing nullability in parameters of viewManagerInterface methods (e.g. String commands parameters are not nullable, view params are not nullable in any method, etc)
Reviewed By: javache
Differential Revision: D75719542
fbshipit-source-id: 7e9aa7ccc24e827bd7b6df72b3302e852932e731
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52400
`react-stack-bottom-frame` -> `react_stack_bottom_frame`.
This survives `babel/plugin-transform-function-name`, but now frames
will be displayed as `at Object.react_stack_bottom_frame (...)` in V8.
Checks that were relying on exact function name match were updated to
use either `.indexOf()` or `.includes()`
For backwards compatibility, both React DevTools and Flight Client will
look for both options. I am not so sure about the latter and if React
version is locked.
DiffTrain build for [91d097b2c588a0977a7a10ed12512dc8a34e3a5b](https://github.com/facebook/react/commit/91d097b2c588a0977a7a10ed12512dc8a34e3a5b)
Reviewed By: jackpope
Differential Revision: D77601866
fbshipit-source-id: 24ed8713af4bebbaeb7a612333cd79c51b696565
Summary:
This PR (initially created for edge-to-edge opt-in support, rebased multiple times) fixes the `Dimensions` API `window` values on Android < 15, when edge-to-edge is enabled.
Currently the window height doesn't include the status and navigation bar heights (but it does on Android >= 15):
<img width="300" alt="Screenshot 2025-06-27 at 16 23 02" src="https://github.com/user-attachments/assets/c7d11334-9298-4f7f-a75c-590df8cc2d8a" />
Using `WindowMetricsCalculator` from AndroidX:
<img width="300" alt="Screenshot 2025-06-27 at 16 34 01" src="https://github.com/user-attachments/assets/7a4e3dc7-a83b-421b-8f6d-fd1344f5fe81" />
Fixes https://github.com/facebook/react-native/issues/47080
## Changelog:
[Android] [Fixed] Fix `Dimensions` `window` values on Android < 15 when edge-to-edge is enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/47554
Test Plan:
Run the example app on an Android < 15 device.
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D77547628
Pulled By: alanleedev
fbshipit-source-id: 9d841f642d5b7ef3294dfbf3868137087a672ad6
Summary:
We need to upgrade the targetSdk to 36, which requires ensuring compatibility with the latest Android APIs and addressing any deprecations or behavior changes introduced in this version.
## Changelog:
[Android] [Changed] - Updated targetSdk to 36 in Android.
Pull Request resolved: https://github.com/facebook/react-native/pull/52355
Test Plan:
- Verified that the app builds and runs successfully with targetSdkVersion 36.
- Ran the full suite of unit and instrumentation tests: all tests passed.
- Manually tested key user flows (login, navigation, data sync) on devices running Android 14 (API 34) and emulator with API 36
- Confirmed that there are no runtime crashes or warnings related to `targetSDK` upgrade.
Behavioral guide for migration: https://developer.android.com/about/versions/16/behavior-changes-16
Reviewed By: fabriziocucci
Differential Revision: D77728391
Pulled By: cortinico
fbshipit-source-id: 3f714f900bbeecc56c0cf46c54b4e42c532c8384
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52335
Adds support for `Network.requestWillBeSentExtraInfo` and `Network.dataReceived` CDP events in jsinspector-modern and wires up for iOS.
In particular, `Network.requestWillBeSentExtraInfo` is necessary to populate request headers in the UI.
**End of base Network implementation for iOS**
After this diff, we are spec-complete on all CDP Network methods for our V1, on iOS.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D77489476
fbshipit-source-id: 84aa4da9d9fcbdc61eff236fc6bd2136496910a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52334
Adds support for `Network.loadingFailed` in jsinspector-modern and wires up for iOS.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D77489477
fbshipit-source-id: dc8156979fe49583819019fa4b88b6eb99dea734
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52331
Updates the iOS inputs to `NetworkReporter` to support incremental string data HTTP responses (`Transfer-Encoding: chunked`).
This means that incremental responses, such as Metro bundle requests, can be displayed as previews in React Native DevTools.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D77457109
fbshipit-source-id: 00a622dbac97c38e07c67b5ee3661c8d586f6fe1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52332
Adds support for the [`Network.getResponseBody`](https://chromedevtools.github.io/devtools-protocol/tot/Network/#method-getResponseBody) CDP event in `jsinspector-modern` and configures this for iOS. This enables us to populate the "Preview" and "Response" tabs in the React Native DevTools Network panel.
This is integrated with `RCTNetworking.mm` to support synchronously received `text` or `blob` data types, with incremental response support added next in D77457109.
**Implementation notes**
- Adds a new `BoundedRequestBuffer` construct to safely buffer response previews at a max memory size.
- `RCTNetworking` will always call `maybeStoreResponseBody` (when feature flag enabled), but is unaware whether there is an active CDP debugging session with network support or not.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D74319394
fbshipit-source-id: c9dbb44551c15d1b1a7cce56b35bf829f8a99dc7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52380
Apps that rely support focus in FlatList rendered items are missing out on a FlatList optimization that defers rendering for offscreen content updates.
For example, on Android, if you focus and smooth scroll an item into view, the onScroll event will fire first. For most sufficiently large virtualization windows, the next render will be delayed by the render batch timeout as most materialization of virtualized views is not treated as a high pri render.
However, this batch / timeout mechanism isn't being used for cell render updates that occur as a result of a focus change.
This change adds the same timeout mechanism used for scroll events. In most cases, the view that is focused is in the viewport, and the extra rendering needed is already scheduled (or executed with high priority if needed) when the onScroll event is processed.
In cases where the focus change occurs outside the viewport, most platforms will want to do some kind of "bring into view" anyway, and the same applies - onScroll will take care of scheduling the cell rendering priority.
## Changelog
[Internal]
Reviewed By: NickGerleman
Differential Revision: D77681274
fbshipit-source-id: 1ade377e513eca21338a380ff9299dd410606aec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52358
Another class going from Java to Kotlin.
This is quite involved due to the amount of Raw generics we were using so I'd appreaciate a couple of further eyes here.
Changelog:
[Android] [Changed] - Convert UIManagerModuleConstantsHelper to Kotlin
Reviewed By: mdvacca, javache
Differential Revision: D77589975
fbshipit-source-id: 477c1e2a8dfd31db60047fd1252f6d47c177f5c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52378
This adds a Gradle property called `exclusiveEnterpriseRepository`
that users can set in their `android/gradle.properties` as such:
```diff
# Use this property to enable or disable the Hermes JS engine.
# If set to false, you will be using JSC instead.
hermesEnabled=true
+exclusiveEnterpriseRepository=https://my.internal.proxy.net/
```
This will remove all the existing Maven repositories and only use the internal mirror they have.
Changelog:
[Android] [Added] - RNGP - Add support for `exclusiveEnterpriseRepository` to specify an internal Maven mirror.
Reviewed By: mdvacca
Differential Revision: D77667573
fbshipit-source-id: 835004d2ae7aa4e250b6f7a88a41918b573f5bd5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52387
I would like to grab this in a subclass but unfortunately can't. It is kinda jank since this is a val obtained via reflection, but I figure this is better than copy and paste. I think that I could also expose a function that uses this scroller the way I want it to. Let me know if there are strong objections here
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D77684599
fbshipit-source-id: 6f02c1da5135c1cf34fa1483542e06bf8f0be75e
Summary:
This change fixes an issue on iOS where gradients that fade to a transparent color-stop appear dark or "muddy." The fix ensures that the color's hue is preserved during the transition, matching the behavior on Android and web.
### The Problem
When creating a gradient on iOS (e.g., linear-gradient(red, transparent)), the transparent keyword is treated as transparent black (rgba(0,0,0,0)). The `CAGradientLayer` on iOS then interpolates all color channels linearly, causing the red, green, and blue components of the start color to fade to 0. This transition through black results in an undesirable dark or "muddy" appearance in the middle of the gradient.
## Changelog:
[IOS][FIXED] - Gradient interpolation for transparent colors
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/52249
Test Plan:
Checkout `LinearGradient` example in RNTester, checkout the newly added transparent color transition example, it should render same on android and iOS.
| Before | After |
| --- | --- |
| <img src="https://github.com/user-attachments/assets/c0bb54ad-ed0e-4a80-b37f-0458af0f1f77" width="300"> | <img src="https://github.com/user-attachments/assets/02da921a-bd0e-45c1-881c-cf6460d5ed43" width="300"> |
| `linear-gradient(to right, red, transparent)` transitions to black on iOS, creating a dark effect. | The gradient correctly fades the red color's alpha channel to zero |
Reviewed By: javache
Differential Revision: D77312194
Pulled By: NickGerleman
fbshipit-source-id: 053df8e44f52cd22a3f28fd01f583f7d03c66af5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52386
Enum `values()` function makes a copy of an underlying array on each call. This happens in a hot path, and seems to show up during profiling. Let's cache it.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D77623705
fbshipit-source-id: 5a33425822f477f63fe104ca9e5ed474385a2022
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52385
This replaces `buildSpannableFromFragmentsOptimized()` with a more optimized version. There are a couple main changes.
1. We don't need a complicated structure around ordering, and span priority, that made its way from the Java ShadowNode logic. AttributedString already ensures there are no overlapping attributes per fragment.
2. `SpannableStringBuilder` is a complicated text-editor style data structure, optimized to allow text content to be modified, and spans re-applied. We can use a much lighter `SpannableString`, on top of the ahead-of-time known text content, which is faster, and saves around 500 bytes per string (and prepared layout). If we assign this to an `EditText`, which later gets edited, Android will copy it to a `SpannableStringBuilder`.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D77622848
fbshipit-source-id: 69bbac86e1f0fd4a15dab6bc279cca305f2a53ae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52372
This is just a follow-up on top D77025333 to make sure that the links in the blog posts and the GitHub releases keep working.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D77654056
fbshipit-source-id: a1c6df44ebee058dd5b59e5b6a60c7c1e060e52c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52370
This is just a patch bump of Gradle ahead of the 0.81 branch cut.
Changelog:
[Android] [Changed] - Bump Gradle to 8.14.2
Reviewed By: fabriziocucci
Differential Revision: D77601121
fbshipit-source-id: b2fdc8b022f2ab43997f412c77e0c924c01f1a5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52369
Tiny fix where the system status bar elements were no longer visible under Android edge-to-edge.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D77653633
fbshipit-source-id: 1275a0de6665a6ef4599166fb205865cd581bb41
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52359
This is needed ahead of the 81 branch cut.
Changelog:
[Internal] - Bump all packages to 0.81.0-main
Reviewed By: huntie
Differential Revision: D77602196
fbshipit-source-id: 1b52a7d1577783d72aba8d20f98032f29ffcc7df
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52357
Changelog: [Internal]
Adds a hyper-minimal build script using `electron/packager` that produces custom binaries for the experimental React Native DevTools standalone shell. The main user-facing benefit of this is replacing the Electron name and icon with our own branding.
NOTE: `electron/packager` is designed to include the application code in the resulting binary. This is arguably overkill for us - the current launch model of `electron src/electron/index.js` is actually wholly sufficient for what we need - but I decided to go with the grain of the available tooling for simplicity.
Icon design courtesy of huntie. 🙏
Reviewed By: huntie
Differential Revision: D77591742
fbshipit-source-id: a968465df4f54fba54c874b6300788e151600ed7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52365
Adds type imports autofix support and pass `fb_internal` paths in react native deep imports eslint rule. The rule fixes imports with all matched types with static API mapping to prevent splits.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D77445445
fbshipit-source-id: cd5b75b4b3b53792117b8297352dddc4d63dbf70
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52345
changelog: [internal]
I would like to measure impact of D76597973 to get a better understanding of UIKit's rendering.
Reviewed By: yungsters
Differential Revision: D77542666
fbshipit-source-id: 4c2de4f36d2b374d83df934dd3a98d01b24f487f
Summary:
This PR connects breaking change detection with a danger bot. The action takes snapshot from main branch and from the PR as inputs to`diff-api-snapshot` (saved in runner temp directory).
## Changelog:
[Internal]
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/52045
Reviewed By: huntie
Differential Revision: D76735630
Pulled By: coado
fbshipit-source-id: 9208117340c1e0bf10d58b67892727717d22e62f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52353
This diff aligns breaking change detection script with new snapshot format. It compares hashes to determine if the API changed for each specifier.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D77377762
fbshipit-source-id: e1c69692ace389fb08ae9470b9f9631e53834206
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52342
This diff deletes `public-api-test` for detecting changes in public API. It is replaced with public API snapshot validation (in D76340729) for better detection and understanding of changes that influence external interfaces.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D77531763
fbshipit-source-id: a8ef2b6f52fa6efb5b312598ea3e4746fc51e4ec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52352
This diff adds excution of `yarn build-types --validate` to run RN JS API snapshot validation on CI.
### Motivation
Detect react-native public API changes before they land.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D76340729
fbshipit-source-id: 10c465418e0ba4eb05cf557a16119f9756843d9e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52343
This diff commits our V2 JavaScript API snapshot for React Native.
This is a new format and workflow that replaces the previous `public-api-test` Jest test.
Please look at the file header for up-to-date instructions on updating the API snapshot.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D77532617
fbshipit-source-id: d5faae815aa5071b0f472fcb02318b73772b11cf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52268
Ships the feature flag introduced in https://github.com/facebook/react-native/pull/51719 to fix crahes that result from shadowed animated style values.
Changelog:
[General][Changed] - Animated now always flattens `props.style`, which fixes an error that results from `props.style` objects in which `AnimatedNode` instances are shadowed (i.e. flattened to not exist in the resulting `props.style` object).
Reviewed By: javache
Differential Revision: D77314904
fbshipit-source-id: b442d0256aee7a8925e28c7e87aee5e0a3f39425
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52354
These should no longer be needed as `ReactNativeFeatureFlags` handles the missing native module gracefully.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D77365271
fbshipit-source-id: 92c6789b2175f24c79838118f681107a43c9ff0a
Summary:
X-link: https://github.com/facebook/yoga/pull/1823
Pull Request resolved: https://github.com/facebook/react-native/pull/52348
Fixes https://github.com/facebook/yoga/issues/1819
Yoga has a fast path when measuring a node, if it thinks it knows its dimensions ahead of time.
This path has some eroneous logic, to set both axis to owner size, if *either* will evaluate to zero, while having an `YGMeasureModeAtMost`/`FitContent` constraint. This means that if a node is given a zero width, and Yoga later measures with with `FitContent`, its height will become the maximum allowable height, even if it shouldn't be that large.
We can fix this, by only allowing if both axis are this fixed case, instead of just one.
This bug has existed for about a decade (going back to at least D3312496).
Changelog:
[General][Fixed] - Fix possible invalid measurements with width or height is zero pixels
Reviewed By: yungsters
Differential Revision: D76851589
fbshipit-source-id: 6f5a0e6beccc51f591726c9e83e9b90f3350ed0f
Summary:
Static code analysis reports several weak warnings, many of which seem to be leftovers after Kotlin migration. This PR addresses quite a few:
- [Accessor call that can be replaced with property access syntax](https://www.jetbrains.com/help/inspectopedia/UsePropertyAccessSyntax.html)
## Changelog:
[INTERNAL] - Kotlin: fix static code analysis weak warnings (6/n)
Pull Request resolved: https://github.com/facebook/react-native/pull/52338
Test Plan:
```sh
yarn android
yarn test-android
```
Reviewed By: NickGerleman
Differential Revision: D77504913
Pulled By: cortinico
fbshipit-source-id: 62661ba6adafb7893ce27811357020966d5ea4c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52346
This is bypassing the mutex, and potentially not thread-safe.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D77541041
fbshipit-source-id: f97415d066786864806836768dbce2d5e68487ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52341
The setter for `createNewDialog` is now wrong (after D76834213).
If the `createNewDialog` has been set to `true` by any other field, we should respect it and not set it to true/false regardless
(only considering the `isEdgeToEdgeFeatureFlagOn`) property.
This fixes it.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D77539533
fbshipit-source-id: a1deaf1f1b856895304e8b73fa5d0c0367e677af
Summary:
There is an issue with keyboard navigation if some scroll view sets `snapToAlignment`. In this case, we are unable to find potential focus candidates if clipping is enabled since this prop will make it so that certain views in the hierarchy under the scroll view form a native view without any traits being set. The fix we have in place currently relies on `FormsStackingContext` to be set to discover potential candidates so it will break in this case. To fix this, we just return the entire ancestor list, since native will know how to deal with the cases that are not actual views, and in general has the official knowledge of what can be in the hierarchy or not.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D77467933
fbshipit-source-id: 35daaba06347c738cf7a85eef86adb7944a9cb26
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52308
Experimentation shows, that we very heavily rely on the global text cache for performance (not sure how much of this is invalidation, vs repeated text, or revisiting previous surfaces).
This adds a global LRU cache, of prepared layouts, given a specific AttributedString and constraints. This is similar to the existing cache, with the caveat, that we need to have separate entries for any display states, instead of just those that effect metrics.
I sized it at 200 elements for now, since an Android `Layout` is much heavier than a `Size` (in practice, each seem to weight 1-3KB (though this will be significantly reduced with future change to move from `SpannableStringBuilder` to `SpannableString` and also contributes to the global JNI ref table, but set this up to be customizable via flag, so we can experiment, on perf impact, vs memory.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D77341994
fbshipit-source-id: b453250dc475f6a281a3260b876bf80f301dd5dd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52323
Original commit changeset: b144ca6db6f7
Original Phabricator Diff: D77388413
Reverting the revert since it did not fix our javascript crash problem for v270 https://fburl.com/scuba/errorreporting_system_vros_javascripterrors/mtexik9e
Original diff stack: D76908041
Revert diff stack: D77388940
Changelog[Internal]:
Puting back the Kotlin Migration for ReactDelegate file
Reviewed By: cortinico
Differential Revision: D77448293
fbshipit-source-id: ed40836c3ecb4ca551b23cb64de2c34cfda0dea1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52322
Original commit changeset: 4a366205ea9c
Original Phabricator Diff: D77388940
Reverting the revert since it did not fix our javascript crash problem for v270 https://fburl.com/scuba/errorreporting_system_vros_javascripterrors/mtexik9e
Original diff stack: D76908041
Revert diff stack: D77388940
Changelog[Internal]:
Puting back the Kotlin Migration for ReactDelegate file
Reviewed By: cortinico
Differential Revision: D77448238
fbshipit-source-id: f41faa19f6761b7ed644e804019f5ec4738326a7
Summary:
This follows https://github.com/facebook/react-native/pull/47554
Compared to the initial proposal, I had to remove the `edgeToEdgeEnabled` property from the root `gradle.properties` and put it in the app `gradle.properties` instead (explaining the `AgpConfiguratorUtils.kt` / `GenerateEntryPointTask.kt` / `ProjectUtils.kt` / `PropertyUtils.kt` changes)
This PR:
- Enable edge-to-edge for `MainActivity` (when `edgeToEdgeEnabled` is set to `true`)
- Disable `StatusBar` `backgroundColor` and `translucent` (when `edgeToEdgeEnabled` is set to `true`)
- Enforce `statusBarTranslucent` and `navigationBarTranslucent` on `Modal` when edge-to-edge is enabled
- Add an `isEdgeToEdge` constant to `DeviceInfoModule` for [`react-native-is-edge-to-edge`](https://github.com/zoontek/react-native-edge-to-edge/tree/main/react-native-is-edge-to-edge) detection
## 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] - Add edge-to-edge opt-in support
Pull Request resolved: https://github.com/facebook/react-native/pull/52088
Test Plan:
- Update `enableEdgeToEdge` value in `packages/rn-tester/android/app/gradle.properties`
- Recompile
https://github.com/user-attachments/assets/4c6beb98-fa88-427c-b62d-a42ffe5330f0
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D76834213
Pulled By: alanleedev
fbshipit-source-id: c39b2cff1a5e94e31306e3b35651aa2de83d2fe6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52309
This is another class going from Java to Kotlin.
Thish should have no breaking changes, but I'll keep an eye to see if this is disruptive for users in the ecosystem.
I also haven't removed any of the Deprecated method, which can be cleaned up afterwards.
Changelog:
[Android] [Changed] - Migrate ThemedReactContext to Kotlin
Reviewed By: javache
Differential Revision: D77374236
fbshipit-source-id: d1787b21897b01c45bbf841fdda00972e0be58db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52296
## Changelog:
[Internal] [Changed] - Fewer calls to direct manipulation callback
`NativeAnimatedNodesManager::onRender` is supposed to run each frame for c++ animation, from the callstack sample trace, the vast majority of time is spent on `updateNodes` (run update on all AnimatedNodes) and `commitProps` (where either Fabric ShadowTree commit or direct manipulation is called). Change in this PR is supposed to reduce time spent in `commitProps`
{F1979788964}
Reviewed By: sammy-SC
Differential Revision: D77380842
fbshipit-source-id: 2f25ca1fba4171a7b3e485298738379d0daff3ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52306
The RCTPushNotificationManager is deprecated and not part of the prebuilds as it is optional.
We mistakenly added it to the umbrella header and nightlies do not work with prebuilds.
This change removes the header ad should fix the build.
## Changelog:
[Internal] -
Reviewed By: philIip
Differential Revision: D77395754
fbshipit-source-id: 66371650dc56f5be16a00319d9e4a1078a7b68bd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52276
The line metrics reported do not process the Spannable, meaning their layout results may disagree with those used for measurement and display.
Changelog:
[Android][Fixed] - Fix onTextLayout metrics not incorporating ReactTextViewManagerCallback
Reviewed By: lenaic
Differential Revision: D77261839
fbshipit-source-id: 87bdc86ce16a2ae9fa69532c5721c19567a53595
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52222
Changelog: [Internal]
Introduce environment option to force usage of OSS fantom test runner.
If env is not set - check for BUCK file in tester which is checked in for FB but not for OSS.
Reviewed By: rubennorte
Differential Revision: D77160761
fbshipit-source-id: 1701ff140ff2be1bbeacfb4305e9f89089cacb42
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52294
changelog: [internal]
Views that are hidden provide couple perf benefits:
- The layer is skipped during hit-testing, so the view no longer receives touches.
- Compositing work for the layer is skipped, so nothing is uploaded to the GPU for that view.
Note, VirtualView still occupies space in memory and because this is infinite list and its numbers will grow unbounded.
In this diff, hidden = YES is only set when VirtualView does not participate in accessibility features.
Reviewed By: yungsters
Differential Revision: D76597973
fbshipit-source-id: 10eb36fccabba9e37cc6322ed5969b8502193a5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52295
The current setup for several of our podspecs abuses the `**` globbing mechanism, forcing us to specify some excluded folders.
By excplicitly mention the folders that we want to use on iOS, we can avoid the usage of the `exclude_files` property.
This should make the setup more reliable and it will also avoid to leak to OSS the presence of some folders we only use internally like `platform/macos` and `platform/windows`
## Changelog:
[Internal] -
Reviewed By: huntie
Differential Revision: D77381512
fbshipit-source-id: 4cb9118bf9f0ecd253d7d871341f733564d84c83
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52300
Targeted improvement to `versionExportedApis` (D77303917) to reduce noise.
This eliminates the false positive from a rename to a local (unexported) type, that does not structurally change the shape of exported types.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D77314292
fbshipit-source-id: 4de90f5b5f1b622225762b2a73e386538000d54a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52299
Correctness improvement to the `versionExportedApis` transform (D77303917). Now handles namespaced references (e.g. `Animated.Value`) by redirecting to the locally defined type name.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D77314293
fbshipit-source-id: 6442d3ab0a3c8bebf6593455b1c2fb74266e657f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52298
Exposes the ability to output inline debug annotations for the `versionExportedApis` transform (D77303917) as a formalised `--debug-version-annotations` CLI flag.
This is helpful for debugging and future maintenance, and will be used to show the effect of the next diffs.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D77373723
fbshipit-source-id: 91c91abcb657ab88ee2f8209efccb4024602acc7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52292
Adds a new transform that annotates all exported symbols in our V2 JS API snapshot with a version hash based on the shape of all input types.
This intends to be a reliable mechanism to indicate how changes to local types will ultimately affect exported types.
**Advantages** (over our alternative type inlining prototype)
- More intuitive to developers — in that source type changes are preserved closer to their original source code shapes.
- Enables useful Git blaming of individual exported APIs — hash for each export line will change every time a type is affected, and relevant commits can be looked up based on this.
- Handles recursive types.
- Can be **best-effort** with minimal structural effect over time. We are okay with false positives that over-match input type changes (these are refined later in the stack).
- Similar to this, is **lower risk** in terms of requiring future updates that may pollute the diff of the body of the API snapshot structurally.
**Example change**
Example type change with multiple references: D77378010
{F1979784798}
✅ 8 char hash based on input type shapes printed next to each root-exported identifier
✅ For a source change to the `AccessibilityProps` type, 33 dependent exported types are updated with a new hash
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D77303917
fbshipit-source-id: 9d43a617697418218eb4951e8e9858d125e222b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52293
# Changelog:
[Internal] -
Adds a helper method to the `IMountingManager` API in order to get the platform specific image loader implementation, if available.
Reviewed By: christophpurrer
Differential Revision: D77379053
fbshipit-source-id: b7595d78c83e9270ec1818daf2d0f1d342661e52
Summary:
To make sure we are exposing the same public API to swift as without prebuilt, this commit changes the follow:
- ModuleMap / Umbrella file is generated from template, not dynamically to align with non-prebuilt (cocoapods). This is temporary, we are already working toward a solution to generate them dynamically.
- Headers are extracted by reading from podspec files and expanding their globs. This is now easy since we can use the podspec_sources function to look for file globs.
## Changelog:
[Internal] - refactored header/umbrella/modulemap generation for prebuild
Pull Request resolved: https://github.com/facebook/react-native/pull/52286
Test Plan:
- Run RN-tester with/without prebuilts
- Create new RN app based on nightly, build with/without prebuiltsTo make sure we expose all the swift features that we should, we expose and declare a variable from React_RCTAppDelegate
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D77368255
Pulled By: cipolleschi
fbshipit-source-id: 88e2c9d1622753895c8667a9b5aeae4a0d332cc4
Summary:
# Changelog: [Internal]
Adds support for experimental non-standardized `console.timeStamp` API for capturing performance entries on a timeline. The main idea of the API is to be highly performant. More details in the corresponding RCP [1].
NOTE: Because of the `jsinspector-modern` stack gating logic, this won't be installed in production builds. `console.timeStamp` will be polyfilled with a stub - D76987507.
Reviewed By: rubennorte
Differential Revision: D77374707
fbshipit-source-id: cb66b9fda06168f4b13af764afe95a63a0a8d5a0
Summary:
Changelog: [Internal]
A minimal tweak to a legacy code path for React DevTools in React Native (**NOT** Fusebox!) that enables it to work / not crash when encountering an IPv6 dev server address. See doc comment for more.
Reviewed By: hoxyq
Differential Revision: D77150288
fbshipit-source-id: c11c742aad7b83861a1242dd13c5ed2753fbdf29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52091
# Changelog: [Internal]
Adds support for experimental non-standardized `console.timeStamp` API for capturing performance entries on a timeline. The main idea of the API is to be highly performant. More details in the corresponding RCP [1].
NOTE: Because of the `jsinspector-modern` stack gating logic, this won't be installed in production builds. `console.timeStamp` will be polyfilled with a stub - D76987507.
Reviewed By: rubennorte
Differential Revision: D76284119
fbshipit-source-id: c87c6645fe32f56d84f5915ff57865cfd9723a47
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52168
# Changelog: [Internal]
The main reason for the stub is to make sure this method is always installed. The actual implementation will be part of the `jsinspector-modern` stack, which is fully initialized in production builds.
Once there is a gurantee that RuntimeTarget globals are always installed in any environments, we can remove polyfills altogether.
Reviewed By: rubennorte, GijsWeterings
Differential Revision: D76987507
fbshipit-source-id: 2602af28f9e4359cf58dfafdf84802c0bf92372d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52289
The old `devtools://devtools/...` URL is **unsupported** with our modern debugger backend.
This reference was something we'd been intentionally leaving in place to preserve the old experience in Flipper — we can now remove.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D77368319
fbshipit-source-id: 400183e9bc477a887d66d79b412277971cf425e5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52280
Changelog: [Internal]
Adds a type-simplifyng transform for the API snapshot, with the goal of resolving some built-in TS types during build time. Most notably, it's able to simplify `Omit` structures emitted by the `flow-api-translator` when translating Flow's type spread operator.
It builds upon a simplified type inlining transform from the previous approach. The type inlining transform is able to handle inlining type references and resolution of built-in TS types on literal types:
- `Omit`
- `Readonly`
- `Partial`
- `keyof`
Reference inlining is performed top-down and built-in type resolution is performed bottom-up, which makes it possible for the second step to assume working on type literals.
Type simplifying transform uses the type inlining to reduce type references encountered inside `Omits` to their literal shapes, which makes possible to determine whether `Omit` is neccessary case-by-case. If `Omit` is redundant, it can be safely removed. If it's not, the omitted keys can be reduced to represent a subset of keys existing in the target type.
It also keeps the ability to resolve `Partial` and `Readonly` types on type literals, simplifying the snapshot further.
An example diff the transform can handle:
Before:
```
export declare type AccessibilityProps = Readonly<
Omit<
AccessibilityPropsAndroid,
| keyof {
accessibilityActions?: ReadonlyArray<AccessibilityActionInfo>
accessibilityHint?: string
accessibilityLabel?: string
accessibilityRole?: AccessibilityRole
accessibilityState?: AccessibilityState
accessibilityValue?: AccessibilityValue
accessible?: boolean
"aria-busy"?: boolean
"aria-checked"?: "mixed" | (boolean | undefined)
"aria-disabled"?: boolean
"aria-expanded"?: boolean
"aria-hidden"?: boolean
"aria-label"?: string
"aria-selected"?: boolean
"aria-valuemax"?: AccessibilityValue["max"]
"aria-valuemin"?: AccessibilityValue["min"]
"aria-valuenow"?: AccessibilityValue["now"]
"aria-valuetext"?: AccessibilityValue["text"]
role?: Role
}
| keyof AccessibilityPropsIOS
> &
Omit<
AccessibilityPropsIOS,
keyof {
accessibilityActions?: ReadonlyArray<AccessibilityActionInfo>
accessibilityHint?: string
accessibilityLabel?: string
accessibilityRole?: AccessibilityRole
accessibilityState?: AccessibilityState
accessibilityValue?: AccessibilityValue
accessible?: boolean
"aria-busy"?: boolean
"aria-checked"?: "mixed" | (boolean | undefined)
"aria-disabled"?: boolean
"aria-expanded"?: boolean
"aria-hidden"?: boolean
"aria-label"?: string
"aria-selected"?: boolean
"aria-valuemax"?: AccessibilityValue["max"]
"aria-valuemin"?: AccessibilityValue["min"]
"aria-valuenow"?: AccessibilityValue["now"]
"aria-valuetext"?: AccessibilityValue["text"]
role?: Role
}
> & {
accessibilityActions?: ReadonlyArray<AccessibilityActionInfo>
accessibilityHint?: string
accessibilityLabel?: string
accessibilityRole?: AccessibilityRole
accessibilityState?: AccessibilityState
accessibilityValue?: AccessibilityValue
accessible?: boolean
"aria-busy"?: boolean
"aria-checked"?: "mixed" | (boolean | undefined)
"aria-disabled"?: boolean
"aria-expanded"?: boolean
"aria-hidden"?: boolean
"aria-label"?: string
"aria-selected"?: boolean
"aria-valuemax"?: AccessibilityValue["max"]
"aria-valuemin"?: AccessibilityValue["min"]
"aria-valuenow"?: AccessibilityValue["now"]
"aria-valuetext"?: AccessibilityValue["text"]
role?: Role
}
>
```
After:
```
export declare type AccessibilityProps = Readonly<
AccessibilityPropsAndroid &
AccessibilityPropsIOS & {
accessibilityActions?: ReadonlyArray<AccessibilityActionInfo>
accessibilityHint?: string
accessibilityLabel?: string
accessibilityRole?: AccessibilityRole
accessibilityState?: AccessibilityState
accessibilityValue?: AccessibilityValue
accessible?: boolean
"aria-busy"?: boolean
"aria-checked"?: "mixed" | (boolean | undefined)
"aria-disabled"?: boolean
"aria-expanded"?: boolean
"aria-hidden"?: boolean
"aria-label"?: string
"aria-selected"?: boolean
"aria-valuemax"?: AccessibilityValue["max"]
"aria-valuemin"?: AccessibilityValue["min"]
"aria-valuenow"?: AccessibilityValue["now"]
"aria-valuetext"?: AccessibilityValue["text"]
role?: Role
}
>
```
Reviewed By: huntie
Differential Revision: D77295302
fbshipit-source-id: 213aef46035bde4f9783353b5344a6986a418399
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52246
This diff adds the required override to codegen props to make the `FabricMountingManager` aware of the availability of a prop diffing implementation for native components using codegen props.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234066
fbshipit-source-id: 8e95628348f491c5ee08609bc7d7b3d30bc7151b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52266
Native components may use `MixedType` properties in rare cases to hold untyped data. This diff adds support for serializing and prop diffing these types of props so that all of the props and object fields would be included in prop diffing results.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77307169
fbshipit-source-id: ae6b00207ef857c9cfa4bdf9c235972915410a29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52244
The ArrayType props converts to std::vector. This prompted the need for `toDynamic(const T&)` conversion functions as this breaks to potential reliance on all type instances having a `toDynamic()` function available. This includes:
- array of arrays types
- array of objects types
- object with arrays
The ArrayType conversion uses the availability of the `toDynamic` conversion methods for all supported types to convert the values stored by the `std::vector` to `folly::dynamic` values to be stored on a `folly::dynamic::array`.
The diff removes unnecessary conversion methods implemented previously for the core components prop diffing. These are now handled by the generic `toDynamic(const std::vector<T>&)` conversion method.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234065
fbshipit-source-id: 97a3b175ff07fe4a6de3adb14ee6cb42db1a2cfe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52243
Building on the availability of `toDynamic` conversion methods for all supported property types, this diff adds support for diffing of `ObjectType` props.
The template adds the generation of a default comparator for the generated C++ struct. The struct also gains a `toDynamic` conversion method that will convert each property of the object type to a `folly::dynamic` value.
Primitive types make use of the implicit conversion supported by `folly::dynamic`, all other types are converted using `toDynamic`.
The `toDynamic` logic is implemented as a method defined on the struct to avoid increased binary size when required multiple times by the prop diffing implementation.
The external `toDynamic` conversion function calls the struct method directly. This enables support for converting object types using object types within their props.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234064
fbshipit-source-id: 21deb3104303aa374fb65b969af57a6aca6db38c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52242
Codegen supports `DimensionType` props which represents a YGValue. This diff adds a conversion to `folly::dynamic` supporting all the existing value types `YGValue` can represent.
This completes codegen support for all allowed `ReservedPropTypeAnnotation` prop types.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234061
fbshipit-source-id: 6c3aef5e3ab0459d8a68ebd8efaccfecb83b0b08
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52241
Add support for converting string and int32 enum types to `folly::dynamic` and generating the correct property diffing for it conditionally adding the prop value to the prop diff result.
This diff updates the template to convert the enum back to the original string representation provided from the JS side based on the current generated C++ enum value.
The string enum re-uses the existing `toString` conversion. The number enum generates the switch-case mapping required to map back the C++ enum value to the original value assigned to it.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234070
fbshipit-source-id: 8c669d5b2e21bd6022c6ba36149465495e4d4bf3
Summary:
Changelog: [Internal]
Fixes a thread safety bug in the C++ platform's `InspectorPackagerConnectionDelegate::WebSocket` implementation. Since D60520747 `IWebSocketDelegate` event calls have been required to be made on the inspector thread, but the C++ platform was making them on the platform's WebSocket thread instead.
Reviewed By: christophpurrer
Differential Revision: D77150289
fbshipit-source-id: f57de05eaccbbe9db674076fc9e60f8d0dd243c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52271
In my haste I messed up a few of these. Either type in the text, or giving them props they should not have.
Changelog: [Internal]
Reviewed By: jorge-cab
Differential Revision: D77310876
fbshipit-source-id: 9c5a28285d4bb3673fe99630fa7ed97033b17904
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52263
Changelog: [Internal]
Adds a bare-bones API to set the dev server host and port at the time of creating a `ReactInstance` in the C++ platform.
Reviewed By: rshest
Differential Revision: D77050457
fbshipit-source-id: 642dc96d3cb486a2e7faa177adcbf8a15b8fb668
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52256
## Summary
ReactNativeAttributePayloadFabric was synced to react-native in
https://github.com/facebook/react-native/commit/0e42d33cbcfadcf5d787108da785d56a83d07a9f.
We should now consume these methods from the
ReactNativePrivateInterface.
Moving these methods to the React Native repo gives us more flexibility
to experiment with new techniques for bridging and diffing props
payloads.
I did have to leave some stub implementations for existing unit tests,
but moved all detailed tests to the React Native repo.
## How did you test this change?
* `yarn prettier`
* `yarn test ReactFabric-test`
DiffTrain build for [7a3ffef70339c10f8d65a27b88cd73bfbe13eb8a](https://github.com/facebook/react/commit/7a3ffef70339c10f8d65a27b88cd73bfbe13eb8a)
Reviewed By: rubennorte
Differential Revision: D77296286
fbshipit-source-id: a26aa0fe0f7f1c8a42407d759351734a4c85f970
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52050
Uncaught errors are currently raising a custom error to `console.error`:
* With somewhat unclear messaging.
* Only the **component stack** is reported.
* The top-most stack leads to the component where the throw occurred and not to the actual error being thrown.
* The actual error being thrown is never logged
After this change:
* We print the actual error thrown
* The *Owner stack* is attached
(see test plan for examples)
## Changelog:
[General][Breaking] Improve messaging and add error stack trace in console errors generated on throws from components.
----
This is a breaking change because someone might be monkey-patching console.errors, or just listens to them.
Reviewed By: rickhanlonii
Differential Revision: D75080385
fbshipit-source-id: 824f30a804a3bb836ea1be7257784e56c00077c1
Summary:
After switching to the new backwards compatible cocoapods structure with prebuilts, we no longer need any change in the ReactCodegen template.
This commit fixes this.
## Changelog:
[IOS] [FIXED] - revert changes in ReactCodegen template
Pull Request resolved: https://github.com/facebook/react-native/pull/52257
Test Plan: Build RN-tester with prebuilt
Reviewed By: cortinico
Differential Revision: D77303429
Pulled By: cipolleschi
fbshipit-source-id: d251d7d67b1c902082891ba705db5158c558e842
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52234
Changelog: [Internal]
Use raw regex instead of micromatch as it depends on node imports.
Reviewed By: christophpurrer
Differential Revision: D77241819
fbshipit-source-id: c579b42f064f67c2e44e15e40ab6262f45a90797
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52220
# Changelog: [Internal]
Mainly, 2 changes:
1. `PerformanceTracer::serializeTraceEvent(const TraceEvent& event)` -> `PerformanceTracer::serializeTraceEvent(TraceEvent&& event)` for less copies, actually move strings from the `TraceEvent` into the serialized `folly:object`.
2. When collecting events from the buffer, only lock when accessing buffer, not when serializing.
Reviewed By: rubennorte
Differential Revision: D77164969
fbshipit-source-id: c7dd84dd3c94dae22b89ffd4b229974e6d8084de
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52196
# Changelog: [Internal]
Probably been overlooked for quite some time, but shouldn't be a bottleneck.
Reviewed By: motiz88
Differential Revision: D77148271
fbshipit-source-id: e8eb32137086d6c280aab2ec5903be03f96175ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52188
# Changelog: [Internal]
`buffer_.push_back` -> `buffer_.emplace_back`
I didn't measure if there were any runtime wins from this, because I don't expect there would be. Let's avoid potential copies, if possible.
Reviewed By: rubennorte
Differential Revision: D77053032
fbshipit-source-id: 80a0d3759bf95b1945ebe560806712bfa6a4f924
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52187
# Changelog: [Internal]
- `bool tracing_` -> `std::atomic<bool> tracingAtomic_`.
- More doc-comments to explain the usage of mutex and atomics.
- `PerformanceTracer::isTracing()` -> `inline PerformanceTracer::isTracing()`.
- `uint64_t processId_` -> `const uint64_t processId_`.
The main change is that the boolean flag that controls "if we are tracing" is now atomic, which should eliminate potential data races. To avoid "logic" races, we are still going to lock mutex, and then check again. The use of `std::atomic` allows us to perform cheaper check first to avoid potentially unnecessary serializations from other systems that report events into `PerformanceTracer`.
Reviewed By: rubennorte
Differential Revision: D77053030
fbshipit-source-id: 82966055db0d75f828e7b95ad4c6cd7f18902265
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52254
changelog: [internal]
View culling would generate incorrect mounting instructions because view culling context is checked before it is changed by a view.
Reviewed By: javache
Differential Revision: D77298889
fbshipit-source-id: 2f98dc4de90f34673ff6f627b597942d80fda865
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52239
Add `toDynamic` conversion function for `EdgeInset` which allowed for removing the custom conversion implemented for the `ViewProps`.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234069
fbshipit-source-id: 3aecad8a6d78468f0056167fa1523ccdfb68f369
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52238
Add prop diffing codegen for `PointPrimitive` prop type by adding a `toDynamic` conversion for the struct and the prop diffing conditional result update.
The addition of the `toDynamic` function will allow for converting the type when used in array and object types.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234062
fbshipit-source-id: d0f52e8fd78ac7712925ea2a47cdd0fe3392d5b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52237
For array props conversion following later in this stack, each type should have a toDynamic conversion available that can be called upon to convert all supported types to a `folly::dynamic` result.
This diff adds the toDynamic conversion function for `ImageSource`
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234063
fbshipit-source-id: 392cbaf172595936f7f66faa824900dadd58bdcf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52252
Instead of declaring two different sets of Pods for prebuilt and build from source, this commit now keeps the pod structure the same for both modes so that consuming libraries can expect to have the same pods and header files available - without this, libraries would have to be updated to take advantage of the prebuilds.
This PR does:
- Added React-Core-prebuilt as a pod in React-Core if prebuilt is enabled
- Simplified react_native_pods to keep pods structure and add React-Core-prebuilt pod if prebuilts are enabled
- Added function for selecting source sets based on prebuilt/build from source
To be able to function both in prebuilt and in regular build from source mode, all podspecs are now using the switch function podspec_sources so that they only include header files if we are in prebuild mode.
Also added React-Core-prebuilt as dependency on React-Core if we are in prebuilt mode so that we install the React.XCFramework.
## Changelog:
[IOS] [FIXED] - Added backwards compatible use of prebuild through cocoapods
Pull Request resolved: https://github.com/facebook/react-native/pull/52223
Test Plan:
Tested in RN-Tester both with and without prebuild.
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D77296047
Pulled By: cipolleschi
fbshipit-source-id: f3eb4d56b2a78bfc8e10ad852746be1ceaf828b2
Summary:
`Package.swift` was missing the `RCTVibration` target. This commit adds this target.
## Changelog:
[Internal] - Added RCTVibration to SwiftPM
Pull Request resolved: https://github.com/facebook/react-native/pull/52223
Test Plan: Tested in RN-Tester both with and without prebuild.
Reviewed By: cortinico
Differential Revision: D77257066
Pulled By: cipolleschi
fbshipit-source-id: 13c918387a2ed4a8e3941ddce8b7ba11c24eaab5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52235
Adds `organizeDeclarations` transform, replacing `sortTypeDefinitions`.
All `export declare ...` statements are now collected and represented at the end of the snapshot in a single `export {}` block — significantly improving readability and diffing.
Changelog: [Internal]
Reviewed By: j-piasecki
Differential Revision: D77150017
fbshipit-source-id: 1bd451c0e2a18fd6fc0504970b10a5d2502ac872
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52245
Changes `VirtualView` to avoid dispatching redundant mode change events by reading the last committed `renderState` to determine whether the desired render state is already in effect.
This enables `VirtualView` to avoid dispatching synchronous `Visible` mode change events when a previous `Prerender` mode change event has already been committed.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D77271865
fbshipit-source-id: 75418aec1416995737f308a1beff407f2cedb940
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52240
Changes `VirtualView` to detect when its window is not in a focused window (e.g. scroll position or layout changes when it is blurred) and to instead dispatch an async `Prerender` event instead of a sync `Visible` event.
This minimizes unnecessary main thread synchronous work that is needed for a view that is not important to the user experience.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D77261958
fbshipit-source-id: 32acef9bc938005a0d73c5166f1741aebadf23bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52236
Enable experimental Flow 'match' syntax for `react-native-github/packages/react-native/src/private/components/virtualview/` and adopt in one case to see if there are any issues.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D77250963
fbshipit-source-id: 0b2a5817a05f3332031f0c0590fe956eaa74ddd3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52212
Correcting some C++ imports that show up when build with Xcode 26:
- Missing `<string>` imports.
- `<tgmath.h>` is a deprecated C++ header file, which in this case can be substituted with `<cmath>`.
## Changelog: [Internal]
[iOS][Fixed] - Fix deprecated C++ imports
Reviewed By: zhenma
Differential Revision: D77192276
fbshipit-source-id: 30c836947cb3eb54f6e7ac42b87fd2493334a4f4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52231
Not calling `super.onInitializeAccessibilityNodeInfo` on the host view with accessibilityOrder prevents setting proper dimensions for the node that backs the view which leads TalkBack to trigger scrolling when under a ScrollVIew.
We still need the host's node to not be accessible so we still set it to not be focusable and not have a content description since this should be handled by the virtual views
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D77180494
fbshipit-source-id: fe8794cf421cdc9548cf3e18a62d4bb3e8c26b09
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52066
Before, to disable views that were excluded from the order we were setting them to be not important for accessibility. This however breaks coopting behavior of parent views, because parent views will not announce content descriptions of children that are not important for accessibility.
Instead of disabling by setting `important for accessibility = no` now we just set `isFocusable = false` which disables focusing but still allows parent views to coopt
We also add functionality to restore view focusability when enabling disabling screen readers since `isFocusable` changes keyboard focusability and when screen readers are disabled we don't want to change it.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D76745057
fbshipit-source-id: cc237c5f8a4b894a7caa3e34207080777de440ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52228
To avoid unexpected behaviour, apply all Babel transforms within `build-types` sequentially, so that each transform plugin has an accurate starting AST.
Changelog: [Internal]
Reviewed By: j-piasecki
Differential Revision: D77148444
fbshipit-source-id: f86beac12b7a08ef800e28db1ff88755970cf64e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52194
Changelog: [Internal]
Introducing a way to include sources and deps via function that react_native_android_dep.
This will help with Fantom OSS build.
Reviewed By: cortinico
Differential Revision: D77146189
fbshipit-source-id: 06b09d433741506bc1f58fbf1f9e6add9a9cff91
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52221
It is currently not possible to use prebuilds, because we are missing the `React-Core-prebuilt.podspec` from the npm package we publish.
This change should fix it.
## Changelog:
[iOS][Added] - Ship the `React-Core-prebuilt.podspec` in the package.json
Reviewed By: cortinico
Differential Revision: D77223271
fbshipit-source-id: ab068e1711fdd86f3f0069dc9aa3c0a591fcd26b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52215
We were not handling the download of the XML properly. Using `Net::HTTP.get` will directly return the body and that won't let us check on the status code of the response.
## Changelog:
[Internal] - use get_response instead of get when downloading the maven metadata
Reviewed By: cortinico
Differential Revision: D77216121
fbshipit-source-id: 4da0abff1624c687977a7b77db8a15f19e6b887d
Summary:
This PR replaces Core Graphics implementation with Core Animation for radial gradients. I found that `endPoints` for radial gradient type works differently than linear gradient type. The `endPoint.x` accounts for horizontal length and `endPoint.y` accounts for vertical. This makes it possible to draw ellipse gradients. So we don't need the core graphics API anymore.
## Changelog:
[IOS] [CHANGED] - Optimised Radial Gradients.
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/52117
Test Plan: Non breaking change. Test Radial gradient example from RNTester. Compare results with web, android and iOS. Each platform should render the gradients identically.
Reviewed By: rshest
Differential Revision: D77140709
Pulled By: javache
fbshipit-source-id: 6e3ad9fcf8e819d340ccf5f5946beb140e616cb0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52122
Would love to have a place with all the edge cases we can come back to when we try and tweak things.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D76942595
fbshipit-source-id: ce6e293e2c068383e54404af71a29a0586dbc04e
Summary:
### The Problem
When trying to measure the location of a `View` within a `ScrollView` (ie. for scrolling to the view), the current recommended method is to use `measureLayout` on the nested view to determine its location inside the containing scroll view:
```tsx
const MyComponent = () => {
const scrollViewRef = useRef<ScrollView>(null);
const nestedViewRef = useRef<View>(null);
const scrollToNestedView = () => {
if (!scrollViewRef.current || !nestedViewRef.current) {
return;
}
nestedViewRef.current.measureLayout(
scrollViewRef.current.getInnerViewNode(),
(x, y) => { scrollViewRef.current.scrollTo({ y, animated: true }); },
);
}
return (
<ScrollView ref={scrollViewRef}>
<View ref={nestedViewRef}>
{ /* content */ }
</View>
</ScrollView>
);
}
```
This is valid in the Typescript types layer. However, the only two methods on `ScrollView` to use in this scenario that are [available in the type definitions](https://github.com/facebook/react-native/blob/main/packages/react-native/Libraries/Components/ScrollView/ScrollView.d.ts#L830) are `getScrollableNode` and `getInnerViewNode` – both of these methods [return a `number`](https://github.com/facebook/react-native/blob/main/packages/react-native/Libraries/Components/ScrollView/ScrollView.js#L139-L140). The issue is that a `number` not a valid value to use with `measureLayout` because [its source returns early for that type](https://github.com/facebook/react-native/blob/main/packages/react-native/Libraries/ReactNative/ReactFabricPublicInstance/ReactFabricHostComponent.js#L91-L102).
(Note, you can also use `findNodeHandle` with the scroll view ref, but this also returns a `number`.)
### The Solution
The long-term solution would be to update the types for both `measureLayout` and `ScrollView`. However, that would constitute a breaking change and require some fairly expansive updates. Instead, I am proposing an additive solution.
`ScrollView` has [a public method called `getNativeScrollRef`](https://github.com/facebook/react-native/blob/e69f0726cd2616fb112d2e4fabfeaafc8cada5d7/packages/react-native/Libraries/Components/ScrollView/ScrollView.js#L142) which returns the underlying `HostInstance`. This method correctly works in the runtime layer, but is not supported in the types layer. This PR exposes the public method in the type definition so that we can properly access the underlying instance without using `ts-ignore`.
## Changelog:[GENERAL] [FIXED] - Expose `ScrollView.getNativeScrollRef` on the type definition to allow accessing the underlying `HostInstance`.
Pull Request resolved: https://github.com/facebook/react-native/pull/52203
Test Plan: None needed. This is only a type update exposing existing functionality.
Reviewed By: cortinico
Differential Revision: D77153959
Pulled By: rshest
fbshipit-source-id: 5880695da85406ed9fe49a1b736b5754db0e6382
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52095
This diff removes `shelljs` from `run-ci-javascript-tests.js` and replaces `echo, exec, and exit` methods.
### Motivation
Decrease number of references to `shelljs` across the react-native-github.
Changelog:
[Internal]
Reviewed By: NickGerleman
Differential Revision: D76512374
fbshipit-source-id: 6e02901b570cf9a36bd13a075106a7066a85a2d9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52192
Changelog: [internal]
When we shipped the event loop we removed the need to run only expired tasks in `RuntimeScheduler_Modern`, but we never cleaned up the code properly. This does it.
Reviewed By: javache
Differential Revision: D77142978
fbshipit-source-id: f808edf80a134f487723fa36ab7a3593e4efe2d3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52191
Changelog: [internal]
Some time ago we added logging for the timer ID in Systrace/Perfetto so we could see where timers were scheduled vs. executed.
This diff adds support for the same functionality for tasks in the runtime scheduler.
Reviewed By: javache
Differential Revision: D77039038
fbshipit-source-id: 792d2fe29b44fb209f9129f46f9d661dad7ebdff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52190
Changelog: [internal]
This adds some tracing metadata to IntersectionObserver to contextualize the performance of certain operations (logging how many observers it's processing).
Reviewed By: javache
Differential Revision: D77039037
fbshipit-source-id: 9cee79ac0509f57e4658a16142f3fe2d10d71fdf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52189
Changelog: [internal]
This creates a benchmark to measure the changes in performance in RuntimeScheduler.
Reviewed By: javache
Differential Revision: D77142979
fbshipit-source-id: 1a6e6824f4c6fdb8d2c5cbad77fb4b8ba406ef29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52138
Integrate React Core prebuilds with apps
## Context
This PR introduces the first working version of building React Native apps on iOS using prebuilt RNCore and cocoapods.
- Added React-Core-prebuilt.podspec for installing/consuming XCFrameworks
- Added logic in react_native_pods.rb for switching between build from source and using prebuilts
- Added rncore.rb - utilities for the ReactCore prebuilts
- Updated rndependencies with some extra error handling modelled after rncode.rb
- Added support for hard linking headers and modules in each inner framework in the XCFramework in xcframework.js
## Swift:
To enable support for the objective-c types from swift, the swift compiler uses a module map to gather exports from the framework (module.modulemap). This file basically points to an umbrella header file that exports the valid objective-c types (non c++) to Swift. In addition these files are read from the DerivedData and not the project source - so it is a bit hard to control everyting.
I was initially not able to use cocoapods own module definitions (module_name, module_file props) to use a custom module map. I finally found that these files are expected in the deriveddata (build folder) where only the active inner framework is copied - so then I had to hard link both module map and header files for each arch.
## Changelog:
[IOS] [ADDED] - Added support for using prebuilt RNCore with Cocoapods
Pull Request resolved: https://github.com/facebook/react-native/pull/52109
Test Plan:
Run with RN Tester. We need to remove all extra pods from RNTester pod file since none of them are yet compatible with prebuilt (they reference non-prebuilt pods)
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D76980286
Pulled By: cipolleschi
fbshipit-source-id: 0ef34599cf7a60e54f799708bce93bcf6fb9d950
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52134
Update RNDependencies podspec to fail fast if framework is missing
## Context
This PR introduces the first working version of building React Native apps on iOS using prebuilt RNCore and cocoapods.
- Added React-Core-prebuilt.podspec for installing/consuming XCFrameworks
- Added logic in react_native_pods.rb for switching between build from source and using prebuilts
- Added rncore.rb - utilities for the ReactCore prebuilts
- Updated rndependencies with some extra error handling modelled after rncode.rb
- Added support for hard linking headers and modules in each inner framework in the XCFramework in xcframework.js
## Swift:
To enable support for the objective-c types from swift, the swift compiler uses a module map to gather exports from the framework (module.modulemap). This file basically points to an umbrella header file that exports the valid objective-c types (non c++) to Swift. In addition these files are read from the DerivedData and not the project source - so it is a bit hard to control everyting.
I was initially not able to use cocoapods own module definitions (module_name, module_file props) to use a custom module map. I finally found that these files are expected in the deriveddata (build folder) where only the active inner framework is copied - so then I had to hard link both module map and header files for each arch.
## Changelog:
[IOS] [CHANGED] - Fail fast when pod install i f using prebuild if frameworks are not present in the disk.
Pull Request resolved: https://github.com/facebook/react-native/pull/52109
Test Plan:
Run with RN Tester. We need to remove all extra pods from RNTester pod file since none of them are yet compatible with prebuilt (they reference non-prebuilt pods)
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D76980282
Pulled By: cipolleschi
fbshipit-source-id: 6ab029d0cb06e2f0a3d99ea9fc7b375865e7a966
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52135
Update the xcframework.js script to support Swift
## Context
This PR introduces the first working version of building React Native apps on iOS using prebuilt RNCore and cocoapods.
- Added React-Core-prebuilt.podspec for installing/consuming XCFrameworks
- Added logic in react_native_pods.rb for switching between build from source and using prebuilts
- Added rncore.rb - utilities for the ReactCore prebuilts
- Updated rndependencies with some extra error handling modelled after rncode.rb
- Added support for hard linking headers and modules in each inner framework in the XCFramework in xcframework.js
## Swift:
To enable support for the objective-c types from swift, the swift compiler uses a module map to gather exports from the framework (module.modulemap). This file basically points to an umbrella header file that exports the valid objective-c types (non c++) to Swift. In addition these files are read from the DerivedData and not the project source - so it is a bit hard to control everyting.
I was initially not able to use cocoapods own module definitions (module_name, module_file props) to use a custom module map. I finally found that these files are expected in the deriveddata (build folder) where only the active inner framework is copied - so then I had to hard link both module map and header files for each arch.
## Changelog:
[INTERNAL] - Update the xcframework.js script to support Swift
Pull Request resolved: https://github.com/facebook/react-native/pull/52109
Test Plan:
Run with RN Tester. We need to remove all extra pods from RNTester pod file since none of them are yet compatible with prebuilt (they reference non-prebuilt pods)
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D76980285
Pulled By: cipolleschi
fbshipit-source-id: 4e5486b79c406ba4b375e2ada24cbe5450e2346f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52137
Update ReactCodegen to support Core prebuilds
## Context
This PR introduces the first working version of building React Native apps on iOS using prebuilt RNCore and cocoapods.
- Added React-Core-prebuilt.podspec for installing/consuming XCFrameworks
- Added logic in react_native_pods.rb for switching between build from source and using prebuilts
- Added rncore.rb - utilities for the ReactCore prebuilts
- Updated rndependencies with some extra error handling modelled after rncode.rb
- Added support for hard linking headers and modules in each inner framework in the XCFramework in xcframework.js
## Swift:
To enable support for the objective-c types from swift, the swift compiler uses a module map to gather exports from the framework (module.modulemap). This file basically points to an umbrella header file that exports the valid objective-c types (non c++) to Swift. In addition these files are read from the DerivedData and not the project source - so it is a bit hard to control everyting.
I was initially not able to use cocoapods own module definitions (module_name, module_file props) to use a custom module map. I finally found that these files are expected in the deriveddata (build folder) where only the active inner framework is copied - so then I had to hard link both module map and header files for each arch.
## Changelog:
[IOS] [CHANGED] - Update ReactCodegen to support Core prebuilds
Pull Request resolved: https://github.com/facebook/react-native/pull/52109
Test Plan:
Run with RN Tester. We need to remove all extra pods from RNTester pod file since none of them are yet compatible with prebuilt (they reference non-prebuilt pods)
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D76980283
Pulled By: cipolleschi
fbshipit-source-id: 4b120203e9e1628a63580b0b3b2e882837c0b818
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52136
Update rndependencies.rb to use the same logic of rncore.rb
## Context
This PR introduces the first working version of building React Native apps on iOS using prebuilt RNCore and cocoapods.
- Added React-Core-prebuilt.podspec for installing/consuming XCFrameworks
- Added logic in react_native_pods.rb for switching between build from source and using prebuilts
- Added rncore.rb - utilities for the ReactCore prebuilts
- Updated rndependencies with some extra error handling modelled after rncode.rb
- Added support for hard linking headers and modules in each inner framework in the XCFramework in xcframework.js
## Swift:
To enable support for the objective-c types from swift, the swift compiler uses a module map to gather exports from the framework (module.modulemap). This file basically points to an umbrella header file that exports the valid objective-c types (non c++) to Swift. In addition these files are read from the DerivedData and not the project source - so it is a bit hard to control everyting.
I was initially not able to use cocoapods own module definitions (module_name, module_file props) to use a custom module map. I finally found that these files are expected in the deriveddata (build folder) where only the active inner framework is copied - so then I had to hard link both module map and header files for each arch.
## Changelog:
[INTERNAL] - Update rndependencies.rb to use the same logic of rncore.rb
Pull Request resolved: https://github.com/facebook/react-native/pull/52109
Test Plan:
Run with RN Tester. We need to remove all extra pods from RNTester pod file since none of them are yet compatible with prebuilt (they reference non-prebuilt pods)
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D76980284
Pulled By: cipolleschi
fbshipit-source-id: a7f09d931c66e2fdf468a09da4be1d40847f472b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52133
Add React-Core-prebuild.podspec to integrate React native core prebuilds using cocoapods
## Context
This PR introduces the first working version of building React Native apps on iOS using prebuilt RNCore and cocoapods.
- Added React-Core-prebuilt.podspec for installing/consuming XCFrameworks
- Added logic in react_native_pods.rb for switching between build from source and using prebuilts
- Added rncore.rb - utilities for the ReactCore prebuilts
- Updated rndependencies with some extra error handling modelled after rncode.rb
- Added support for hard linking headers and modules in each inner framework in the XCFramework in xcframework.js
## Swift:
To enable support for the objective-c types from swift, the swift compiler uses a module map to gather exports from the framework (module.modulemap). This file basically points to an umbrella header file that exports the valid objective-c types (non c++) to Swift. In addition these files are read from the DerivedData and not the project source - so it is a bit hard to control everyting.
I was initially not able to use cocoapods own module definitions (module_name, module_file props) to use a custom module map. I finally found that these files are expected in the deriveddata (build folder) where only the active inner framework is copied - so then I had to hard link both module map and header files for each arch.
## Changelog:
[IOS] [ADDED] - Add `React-Core-prebuild.podspec` to integrate React native core prebuilds using cocoapods
Pull Request resolved: https://github.com/facebook/react-native/pull/52109
Test Plan:
Run with RN Tester. We need to remove all extra pods from RNTester pod file since none of them are yet compatible with prebuilt (they reference non-prebuilt pods)
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D76980281
Pulled By: cipolleschi
fbshipit-source-id: ce102837d6df6ab0fa2e55862cc0c954125bd362
Summary:
Introduce rncore.rb to manage the prebuilds of RNCore.
## Context
This PR introduces the first working version of building React Native apps on iOS using prebuilt RNCore and cocoapods.
- Added React-Core-prebuilt.podspec for installing/consuming XCFrameworks
- Added logic in react_native_pods.rb for switching between build from source and using prebuilts
- Added rncore.rb - utilities for the ReactCore prebuilts
- Updated rndependencies with some extra error handling modelled after rncode.rb
- Added support for hard linking headers and modules in each inner framework in the XCFramework in xcframework.js
## Swift:
To enable support for the objective-c types from swift, the swift compiler uses a module map to gather exports from the framework (module.modulemap). This file basically points to an umbrella header file that exports the valid objective-c types (non c++) to Swift. In addition these files are read from the DerivedData and not the project source - so it is a bit hard to control everyting.
I was initially not able to use cocoapods own module definitions (module_name, module_file props) to use a custom module map. I finally found that these files are expected in the deriveddata (build folder) where only the active inner framework is copied - so then I had to hard link both module map and header files for each arch.
bypass-github-export-checks
## Changelog:
[INTERNAL] - Added script to handle React Core prebuilds
Pull Request resolved: https://github.com/facebook/react-native/pull/52109
Test Plan:
Run with RN Tester. We need to remove all extra pods from RNTester pod file since none of them are yet compatible with prebuilt (they reference non-prebuilt pods)
Rollback Plan:
Reviewed By: cortinico, rshest
Differential Revision: D76979549
Pulled By: cipolleschi
fbshipit-source-id: 7a2b1809bf58b600293cc33ca2dcff0060f3fab0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52198
# Changelog:
[Internal] -
This provides an implementation of what was the RnCxx ImageLoaderModule stub inside ReactCxxPlatform, allowing the clients use dependency injection to provide the actual platform specific image loading functionality.
Reviewed By: javache
Differential Revision: D77015269
fbshipit-source-id: 7355dd75692c1f564de8c3daffd6c8a79182dc09
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52154
I wasn't able to find any meaningful usage of `EventDispatcherImpl` in OSS, therefore I'm making this class internal.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D77024759
fbshipit-source-id: e1ff3329cedf96a8c75edb9b9ccc1ce21adfab11
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52150
This is another class moving from Java to Kotlin.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D77021952
fbshipit-source-id: 0b04a10bcbe65b7dc14ddd2821f80d90a43f8610
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52195
RNTester is currently instacrashing on release due to use minifying the `ReactModalHostView`.
In that class there is a static method that is accessed by JNI so we should annotated this class
as `DoNotStrip` as otherwise we won't be able to access it.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D77148010
fbshipit-source-id: c5b2758fa2919bc1f5885433202a45b4c3f8ff99
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52185
It seems like one of the activity on the stack is not properly implementing `DefaultHardwareBackBtnHandler`.
This will make the crash more clear as it will be clear which activity is the one responsible for the crash.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D77142320
fbshipit-source-id: 1913976d1ad5d3ceafcfc0569f3b74dad9e919ae
Summary:
Splitting the CHANGELOG as it's getting too big to handle.
Changelog:
[Internal] [Changed] -
bypass-github-export-checks
Reviewed By: cipolleschi
Differential Revision: D77025333
fbshipit-source-id: cf2d54f2096f9c8c6a3fadb354d0c3065370440d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52156
Changelog: [Internal]
Fix devtoolsruntimesettings lib as it needs to be OBJECT library as it has source code included.
Reviewed By: christophpurrer
Differential Revision: D77035122
fbshipit-source-id: 27ad7fe637512afc79f3dcc6b0846dcfd4f22504
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52155
Changelog: [Internal]
Gating RN_SERIALIZABLE_STATE behind ANDROID flag so we can build ReactCommon with cmake when targeting different platforms.
This will help build reac-native-fantom for OSS.
Reviewed By: christophpurrer
Differential Revision: D77034689
fbshipit-source-id: 15f9192c90693f4743f31fcf72f593802b622c47
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52110
## Changelog:
[General] [Internal] - Add Fantom test for layout props
With this test it turns out `layoutStyleUpdated_` on PropsAnimatedNode actually can change after animation update, because its connected StyleAnimatedNodes might be changing. This bug was introduced since D74602321
Reviewed By: rshest
Differential Revision: D76753864
fbshipit-source-id: 5bebb11340086390df20c89adf80abaa63cadc90
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52143
Noticed that some of the `IndexOutOfBoundsException` crashes we've been tracking we're not being reported as soft errors because they were not running wrapped by the RN ExceptionHandler
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D77017423
fbshipit-source-id: 760297a0c5ee3d58577931829a31d312dacffdf1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52111
Changelog: [Internal]
JSRuntime integration with executor on messagequeue.
Inching closer to full integration with the rest of RN.
Reviewed By: rshest
Differential Revision: D76752667
fbshipit-source-id: 0ef8fe0c615dc1eb45355f7502e01663772ebf13
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52112
Adding `shouldForwardToReactInstance` check in Bridgeless since it was missed in https://github.com/facebook/react-native/pull/43351
**Changelog:**
[ANDROID][FIXED] - Adding `shouldForwardToReactInstance` check in ReactDelegate for Bridgeless
Reviewed By: cortinico, javache
Differential Revision: D76908041
fbshipit-source-id: 20b8fce248d8e560ab862cf325b6f8b15be870e3
Summary:
this PR makes the stale bot messages a bit clearer and fixes a grammatical issue.
# Changelog:
[INTERNAL] [FIXED] Tweak stale bot messages
Pull Request resolved: https://github.com/facebook/react-native/pull/52124
Test Plan: N/A
Reviewed By: andrewdacenko
Differential Revision: D76969503
Pulled By: cortinico
fbshipit-source-id: d030a0488b44521f61447e252bae5ded10826dbb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52130
After D73948178, Modals now need to access JNI to get the dimension of the
screen to properly position the modal on first rendering.
Before my change, the Modal was positioned in 0,0 (which is the default
behavior for CXX).
I'm suppressing this test for Android, as it will keep on running with the
previous behavior for CXX.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D76979787
fbshipit-source-id: 78675712f97baee29036f943b2a8bcd23047e4ed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52131
This class is not used in OSS and can be made internal.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D76979122
fbshipit-source-id: 2d81e3605e6c51336b3bdb2671dd9faf8f25639b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52132
This is yet another class that is getting converted from Java to Kotlin.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D76979123
fbshipit-source-id: d1fc54e61d64b78a56cf0198ae5fe588702a8698
Summary:
This PR replaces Core Graphics implementation with Core Animation for linear gradients. I came across a great [solution](https://stackoverflow.com/questions/38821631/cagradientlayer-diagonal-gradient/43176174#43176174) that makes the `CAGradientLayer`'s start and end point behaviour CSS spec compliant. This will make gradients much more performant.
## Changelog:
[IOS] [CHANGED] - Optimised Linear Gradients.
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/52096
Test Plan:
Non breaking change. Test Linear gradient example from RNTester. Compare results with web, android and iOS. Each platform should render the gradients identically.
## Note:
I will be doing a PR to use `CAGradientLayer` for radial gradients as well. The next properties that I have locally working are `background-size`, `background-position` and `background-repeat`. These will be addressed in small PRs.
Reviewed By: NickGerleman
Differential Revision: D76905215
Pulled By: javache
fbshipit-source-id: 0094bdf70869d619272d491dd496983316b0dbf0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52129
This remove all the usages of SafeAreaView from RNTester.
The problem is that we introduced a warning that SafEAreaView is deprecated and, therefore, we had a warning in debug mode.
This was causing a yellow bubble to appear and the OSS E2E test started failing.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76978227
fbshipit-source-id: c45a31bae1602bc307e4fbbd71e7987a8ed78858
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51048
Fixes https://github.com/facebook/react-native/issues/50442
Closes https://github.com/facebook/react-native/pull/50704
Users reported that Modals on Android are first renderer anchored in 0,0.
That results in them being on the top left corner of the screen for some seconds.
This is happening because the native state of the Modal on Android as width/height set at 0,0 - which we then update in a subsequent callback.
I'm fixing this by making sure we render the Modal the first time with the right screen size - the status bar size
Changelog:
[Android] [Fixed] - Fix Modal first frame being rendered on top-left corner
Reviewed By: javache
Differential Revision: D73948178
fbshipit-source-id: 055c12aa62d70acc1e4c5a2a5c4ea0c5608e22c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52127
Currently using `react.internal.useHermesNightly` is broken locally because we try to search for versions such as 0.0.0.+ while the nightlies version are of the form 0.81.0-...
This fixes it.
Changelog:
[Internal] [Changed] -
Reviewed By: NickGerleman
Differential Revision: D76901197
fbshipit-source-id: 51f7b2e7ec936aace67d4d62a8019554800347fc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52102
Changelog: [internal]
This ships the variant of IntersectionObserver that integrates directly with the Event Loop, avoiding dispatching notifications during observation and waiting for the end of the Event Loop tick instead. Also cleans up all the associated feature flags.
Reviewed By: lenaic
Differential Revision: D76892649
fbshipit-source-id: 9364b43a4d60b75c25b9a2d6ced7937b03376b04
Summary:
Static code analysis reports 18 warnings for incorrect usages of the `VisibleForTesting` annotation as some of the classes/functions/properties that are annotated are not used only in tests but also in other non-test files across the codebase. This PR cleans that up to fix those warnings.
## Changelog:
[INTERNAL] - Clean up incorrect VisibleForTesting annotation usages
Pull Request resolved: https://github.com/facebook/react-native/pull/52025
Test Plan:
```sh
yarn test-android
yarn android
```
Reviewed By: rshest
Differential Revision: D76745241
Pulled By: sbuggay
fbshipit-source-id: 4702a7258002916cc95c178dc8931c8bb471f7bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52120
It is pretty jarring for semantically different labels to be read all at once, let's comma separate them - which VoiceOver will pause at. Android does this by default with its coopting implementation
Changelog: [Internal]
Reviewed By: jorge-cab
Differential Revision: D76921000
fbshipit-source-id: afe1f93e38babde918137576d0693c1579101ef7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52093
This change updates the `BaseViewManager` implementation to drop and restore the original focus listener when a view instance has its `onDropViewInstance` method called. This is necessary to support view recycling, since the `addEventEmitters` method is called each time a recycled view is popped out of the stack. This would result in N+1 `onFocus`/`onBlur` calls for each time the view is recycled.
Changelog: [Android][Fixed] - Remove focus change listener when dropping/recycling view instances
Reviewed By: NickGerleman
Differential Revision: D76852137
fbshipit-source-id: 9e980e7a1850a952baf04724bc251ff32186c6fa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52106
Changelog: [internal]
This slightly improves the formatting of the output produced by benchmarks, so we can just copy&paste the result to share it as valid Markdown.
Reviewed By: christophpurrer
Differential Revision: D76898244
fbshipit-source-id: dc1040ee3787c7f0dcb747c9fba8eb14086a0087
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52105
Changelog: [internal]
I just learnt there's a Hermes variant that we don't support (staging) so this adds support for it.
Reviewed By: christophpurrer
Differential Revision: D76897715
fbshipit-source-id: 3113edde3c785d71ad4a57dd435f16e13ab46976
Summary:
Following up from https://github.com/facebook/react-native/pull/52064#discussion_r2151906096, this PR removes lint-java and its related files.
The codebase is moving entirely to Kotlin and a Kotlin linter is being setup as well, the usage of the Java linter will become unnecessary.
## Changelog:
[INTERNAL] - Remove lint-java
Pull Request resolved: https://github.com/facebook/react-native/pull/52092
Test Plan: Relying on CI here to be green.
Reviewed By: cortinico
Differential Revision: D76880712
Pulled By: sbuggay
fbshipit-source-id: 2736772e7347f435b17d007e0322e1afc2fb2d7b
Summary:
The alpha channel in the `rgba()` color string format should be a value between [0, 1] instead of [0, 255], as stated in the [React Native Documentation](https://reactnative.dev/docs/colors#red-green-blue-rgb).
## Changelog:
[GENERAL] [FIXED] - Fix the serialization of the alpha channel in the `rgba()` color string format.
Pull Request resolved: https://github.com/facebook/react-native/pull/52087
Test Plan: I didn't find any usage of that function in React Native, but it is part of the public API, and I just wanted to use it in Reanimated.
Reviewed By: fabriziocucci
Differential Revision: D76822560
Pulled By: javache
fbshipit-source-id: 370d9729881c1eda794c1b9fe54d258242fde814
Summary:
This PR allows to interactively close the modal using the swipe down gesture.
It fixes 5 year old issue: https://github.com/facebook/react-native/issues/29319
In short it removes `modalInPresentation` which according to the documentation causes: "UIKit ignores events outside the view controller’s bounds and **prevents the interactive dismissal of the view controller while it is onscreen.**".
It also adds another delegate event to call onRequestClose whenever modal is closed by gesture.
https://github.com/user-attachments/assets/8849ecba-f762-47ec-a28b-b41c1991a882
## Changelog:
[IOS] [ADDED] - Allow to interactively swipe down the modal.
Add allowSwipeDismissal prop.
Pull Request resolved: https://github.com/facebook/react-native/pull/51483
Test Plan: Test if swiping down the modal calls onRequestClose
Reviewed By: rshest
Differential Revision: D75125438
Pulled By: javache
fbshipit-source-id: d4f2c8b59447680f405b725d0809573a937f97cf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52103
## Changelog:
[Internal] -
This got out of sync again, causing the corresponding signal to fail.
Reviewed By: lenaic
Differential Revision: D76893994
fbshipit-source-id: e0e78cd41633972be53aa883c6015588b547b9c2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52101
Changelog: [internal]
`enableAccessToHostTreeInFabric` is enabled by default in tests, so doesn't need to be explicitly set.
Reviewed By: lenaic
Differential Revision: D76894319
fbshipit-source-id: 437a763bd9c557ecbafa53e31410da1120151b86
Summary:
`SafeAreaView` has been marked for deprecation some time ago. The [following discussion](https://github.com/react-native-community/discussions-and-proposals/discussions/827) summarizes some of the arguments for it, but in a nutshell: it is iOS-only, limited in functionality, and incompatible with Android 15's enforced edge-to-edge rendering.
~~The Android/Kotlin classes have also been deprecated.~~ Not anymore, they are internal and might stay as they are.
## Changelog:
[General] [Deprecated] - Deprecate SafeAreaView due to its iOS-only support and incompatibility with Android 15 edge-to-edge behavior; recommend using react-native-safe-area-context instead.
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/51896
Test Plan: Access `SafeAreaView` in your code and check that the deprecation warning logs exactly once in the console.
Reviewed By: rshest
Differential Revision: D76816160
Pulled By: cortinico
fbshipit-source-id: 60f539f9425f8ed8e19578a4530cb1f7d9b54488
Summary:
Due to us moving to central.sonatype.com for publishing, we cannot publish and release the Maven repository in 2 distinct invocations.
This consolidates all the publishing job to happen during build_npm_package
Changelog:
[Internal] [Changed] -
Reviewed By: fabriziocucci
Differential Revision: D76888543
fbshipit-source-id: 3cb0db6176ed2221a12b4f3f1f575232aa006a6c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52081
changelog: [internal]
# The problem in Java and Obj-C Native Animated
--------------------
Event based animations in Native Animated have one big problem: detecting when the gesture is completed. This has led to number of bugs over the years that manifest as Pressable's onPress not triggering. The root cause of the problem is disconnect between where a piece of UI is on the screen and where Fabric thinks it is. Fabric is used for hit testing, and other things like intersection observing, and if Fabric does not have up to date values, weird things start happening.
This diff implements completion detection for event based animations. Unlike previous solutions, it does not depend on sequence of events nor it uses React setState to update shadow tree.
# Completion Detection
--------------------
The key mechanism for marking event animations as completed is in the `onRender` method:
- After processing animations, if `onAnimationFrame` returns false - indicating no UI changes, the system assumes all event-driven animations have completed.
- it then:
* Collects all animated value nodes connected to event drivers.
* Updates all nodes connected to these "finished" animations.
* isEventAnimationInProgress_ to false.
* Commits final property values to the UI.
The benefits over the previous solution:
- It works across all platforms without the need to emit "completion events".
- It uses a UI frame that wouldn't animate anything to do syncing work. Using main thread IDLE time towards bookkeeping.
- No need to call into JavaScript for synchronisation.
Reviewed By: zeyap
Differential Revision: D76743467
fbshipit-source-id: b21ab5ef9c71ff93fd0250e6af6b22ded395be8d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52094
Changelog [Internal]:
- LegacyViewManagerInteropComponentDescriptor was initiaizing Module just to get the `Class` for `componentName`. This can cause deadlock issue when we have module that needs mainQueue to initialize.
Reviewed By: RSNara
Differential Revision: D76757706
fbshipit-source-id: 6fc6127b6ff472fda509364f0c3daa13b6a6df1e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52056
This prop should only be used on Views using it in Text is not very intuitive and also would require some unnecessary edge case handling on Android which we now also remove
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D76744972
fbshipit-source-id: 23113789747295ea1a306727f1e29e3ddc078ac4
Summary:
Compile out the legacy c++ core from android.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D72991984
fbshipit-source-id: 56bb6ca1c4797adb9235e982121712b11e85e109
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52073
X-link: https://github.com/facebook/yoga/pull/1820
Fixes https://github.com/facebook/yoga/issues/1819
Yoga has a fast path when measuring a node, if it thinks it knows its dimensions ahead of time.
This path has some eroneous logic, to set both axis to owner size, if *either* will evaluate to zero, while having an `YGMeasureModeAtMost`/`FitContent` constraint. This means that if a node is given a zero width, and Yoga later measures with with `FitContent`, its height will become the maximum allowable height, even if it shouldn't be that large.
We can fix this, by only allowing if both axis are this fixed case, instead of just one.
This bug has existed for about a decade (going back to at least D3312496).
Changelog:
[General][Fixed] - Fix possible invalid measurements with width or height is zero pixels
Reviewed By: yungsters
Differential Revision: D76793705
fbshipit-source-id: ea4c00e688912a58c08801e4a14ddf1b293a5d86
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52069
Noticed an E2E tests against old emulator version showed aliased Text against Facsimile. This is because non-scratch-paint path does not explicitly enable anti-aliasing (like TextView does), older versions of Android don't enable by default, and `updateTextPaint()` no longer sets, after call to `paint.reset()` was removed.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D76780749
fbshipit-source-id: 26f0de6d6558649fe08339f1ac91390bbd4cce3c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52078
This Cmake file is not imported anymore and can be removed now.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D76808417
fbshipit-source-id: 81824c7c46080bc16c891b5c11c3a8946f16c1b9
Summary:
The target needs the HERMES_ENABLE_DEBUGGER flag in debug just like .reactHermes does.
This commit fixes this by adding the define to the reactRuntime target.
## Changelog:
[IOS] [FIXED] - Added HERMES_ENABLE_DEBUGGER to debug configuration for the reactRuntime target.
Pull Request resolved: https://github.com/facebook/react-native/pull/52082
Test Plan: Prebuild React Core
Reviewed By: robhogan
Differential Revision: D76813200
Pulled By: cipolleschi
fbshipit-source-id: cb81a40fb9c5a91ca40c3a27ae4ccdf043186bac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52083
These headers were removed in D55037569 but we may have some targets still depending on them. Add redirection headers with warnings to help users migrate without this being a breaking change.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D76810433
fbshipit-source-id: 43cddcc69eefbcff0c0140e165fb893bee493c79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52077
RNTester is currently crashing on release due to a stripped `mHybridData` field.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D76808165
fbshipit-source-id: 049cca49f683c5dc92aa1f9a37dd7b4371dcbfd6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52015
Changelog: [Internal]
Add gflags to fantom_tester so we can pass in data like featureFlags
Reviewed By: cortinico
Differential Revision: D76618409
fbshipit-source-id: a18e642a02c405eef972a7418a606a5980253b6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52079
After the conversion to Kotlin (D74571782), there seems to be a synchronization issue when iterating on `viewManagers` (see T226095884).
There could a shadowing problem kicking in in a few places due to the fact that we are declaring a `viewManagers` local variable when there is already a `viewManagers` instance variable within `ViewManagerRegistry`.
To remove any ambiguity, here we are renaming the instance variable `viewManagers` as `viewManagersMap` (which also makes more sense).
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D76807070
fbshipit-source-id: 4f598700e04251409ee19b60515639e90699cc9e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52076
Changelog: [internal]
This refactors the implementation of surface creation in Fantom to make the surface ID handled in native, and treated as an opaque type the same way we do at runtime in RN.
Reviewed By: andrewdacenko
Differential Revision: D76744096
fbshipit-source-id: 1b49a1cbdf0a8d6804de3b87ede727207bc662d9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52051
In {D76368959}, I moved `react-native-fantom` from `packages/` to `private/` and missed this reference.
Changelog:
[Internal]
Reviewed By: rubennorte
Differential Revision: D76743071
fbshipit-source-id: f99d3f2ac5e14fd23f7cf208ca030541844dddc6
Summary:
This diff adds snapshot `diff-api-snapshot` script for public JS API breaking change detection.
### Motivation
Detecting if there are any breaking changes introduced in the commit. It is achieved by comparing `ReactNativeApi.d.ts` rollup from the current and previous revision.
This is a naive implementation with a three possible outcomes:
- BREAKING
- POTENTIALLY_NOT_BREAKING,
- NOT_BREAKING
The algorithm analyses exported top-level statements (after inlining) in both rollups and tries to create a mapping between them by name.
The **BREAKING** outcome happens whenever the statement is:
- removed
- renamed
- changed
- not exported anymore (private)
The **POTENTIALLY_NOT_BREAKING** outcome happens if it's not BREAKING and the new statement is added.
The **NOT_BREAKING** outcome happens if public API snapshot doesn't change.
Changelog:
[General][Added] - Add public JS API breaking change detection under `yarn diff-api-snapshot` script.
Pull Request resolved: https://github.com/facebook/react-native/pull/51972
Test Plan:
Signals, added tests.
In `react-native-github` run:
`yarn test scripts/diff-api-snapshot/__tests__/diffApiSnapshot-test.js`
Rollback Plan:
Reviewed By: j-piasecki
Differential Revision: D76430965
Pulled By: coado
fbshipit-source-id: 095a196aa4f643501db0af9262556ddefff5d30d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52054
Changelog: [internal]
This makes `OpaqueNativeObserverHandle` really opaque and fixes the problems in the observer implementation caused by it.
Reviewed By: yungsters
Differential Revision: D76744094
fbshipit-source-id: a8b6fa43ee8a5ee9d15f0171a83fe0badd46d9c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52055
Changelog: [internal]
This migrates NativeIdleCallbacks to use opaque types now that they're supported in the codegen
Reviewed By: yungsters
Differential Revision: D76744095
fbshipit-source-id: d9d1beea8df7f5635fc531a2cef001ea0aed38b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52053
Changelog: [internal]
The codegen allows us to do this already! :D
Reviewed By: yungsters
Differential Revision: D76741113
fbshipit-source-id: d460685bc6ad6ba11f7132136e8603bd57488014
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52052
Changelog: [General][Added] - Add support for Flow opaque types in codegen for native modules
This allows us to codegen native modules that expose opaque types, but the implementation sees the type the same way they're visible in the JS spec.
Reviewed By: yungsters
Differential Revision: D76741112
fbshipit-source-id: 100ca9aa7f93d35120c52153f756436c9c380b07
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52062
changelog: [internal]
- update comments to be more descriptive.
- use `#pragma mark -` to better group methods in `NativeAnimatedNodesManager`. It is nicely formatted in VSCode.
{F1979345410}
Reviewed By: mdvacca
Differential Revision: D76737257
fbshipit-source-id: c4b22ca45cd5dec2c72e7931bfec4466cda3070c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52065
1. We can crash when tapping at the boundary between two spans. Previous ReactTextView had some custom heuristic for overlapping ReactTags, assuming they could be nested, which never happens (We only have a single tag per AttributedString fragment), but spans may overlap at a single character, where one is meant to be exclusive, and the other inclusive. We add logic for that.
2. We don't incorporate the offset of the text layout within the view for hit testing, needed for padding or `textAlignVertical`.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D76764051
fbshipit-source-id: 308756c45d8ff574420dfc1c88678bae7e03e767
Summary:
While testing I notice that `types/react` was not updated in some peer depencies
## Changelog:
[GENERAL] [CHANGED] - Bump types/react to 19.1
Pull Request resolved: https://github.com/facebook/react-native/pull/52059
Test Plan: CI should be green
Reviewed By: christophpurrer
Differential Revision: D76763084
Pulled By: sbuggay
fbshipit-source-id: c078c03aa57ca04040c64986dd7957da8a6f2c2d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52043
The `hasTVPreferredFocus` prop is functionally similar to the `focusable` prop. On iOS, the props are identical. The primary difference appears on Android, where the prop attempts to request focus when set to true. Attempting to invoke imperative API calls through declarative means has been [a source of confusion](https://github.com/react-native-tvos/react-native-tvos/issues/237) and we should instead recommend requesting focus through imperative means, like calling `focus()` on a specific view's ref instead. Workarounds presented rely on lifecycle methods to request focus natively.
This change only marks these methods as deprecated on JS. In the following version, they will be removed from the public API.
Changelog: [General][Deprecated] - Deprecate `hasTVPreferredFocus`
Reviewed By: andrewdacenko
Differential Revision: D76732539
fbshipit-source-id: 64912b4dacb76cd40e79148c1082d8ed8f573879
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51949
This code is no longer necessary now that JSC support is offered via
https://github.com/react-native-community/javascriptcore
Instructions for users on how to continue using JSC are available in the README of such library.
Changelog:
[Android] [Removed] - Remove 1st party JSC support
Reviewed By: javache
Differential Revision: D76420382
fbshipit-source-id: f8e61556bb02fe4d5b34f89b40f8e5e38ac1c8d6
Summary:
When trying to implement e2e tests using maestro in a large app I ran into major performance issues. I tracked it down to the generation of recursive accessibility labels.
The maestro iOS driver uses [XCUIElement snapshot dictionaryRepresentation](https://developer.apple.com/documentation/xctest/xcuielementsnapshot/dictionaryrepresentation) [here](https://github.com/mobile-dev-inc/Maestro/blob/96e8c9a2be3430be991c13d033486d52d2001334/maestro-ios-xctest-runner/maestro-driver-iosUITests/Routes/Handlers/ViewHierarchyHandler.swift#L234) to get a representation of the view hierarchy. The problem is that will query the accessibilityLabel for every single view, starting from the root of the app. It goes without saying that this is extremely slow since it traverses the view hierarchy, executing a recursive function on each one.
I think the only way to fix this is to avoid generating these recursive labels when not needed. From my understanding these should only be needed for accessible views.
## Changelog:
[IOS] [CHANGED] - Only generate recursive accessibility label for accessible elements
Pull Request resolved: https://github.com/facebook/react-native/pull/51988
Test Plan:
- Tested using VoiceOver in RN tester to make sure it works exactly the same.
- Tested in an app using Maestro to make sure this fixes the performance issue.
- Tested in RNTester running Maestro e2e test by creating a larger view hierarchy to make the problem more apparent, and simulate a real app. Using [this code](https://gist.github.com/janicduplessis/9f6b302d92b4e22ff5e8462a8a84e237) in RNTesterAppShared.js
Before:
```
❯ yarn e2e-test-ios
yarn run v1.22.22
$ ./scripts/maestro-test-ios.sh
Waiting for flows to complete...
[Passed] flatlist (14s)
[Passed] text (28s)
[Passed] modal (16s)
[Passed] image (8s)
[Passed] button (10s)
[Passed] legacy-native-module (32s)
[Passed] pressable (32s)
[Passed] new-arch-examples (35s)
8/8 Flows Passed in 2m 55s
✨ Done in 180.26s.
```
After:
```
❯ yarn e2e-test-ios
yarn run v1.22.22
$ ./scripts/maestro-test-ios.sh
Waiting for flows to complete...
[Passed] flatlist (7s)
[Passed] text (15s)
[Passed] modal (10s)
[Passed] image (4s)
[Passed] button (6s)
[Passed] legacy-native-module (16s)
[Passed] pressable (16s)
[Passed] new-arch-examples (17s)
8/8 Flows Passed in 1m 31s
✨ Done in 97.53s.
```
Reviewed By: christophpurrer, joevilches
Differential Revision: D76581949
Pulled By: cipolleschi
fbshipit-source-id: 0689c7d43a0c865572c4ee5ea32ee9b2dcb33ad5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51986
"{}" defaults to false on C++ but the prop is not initialized which means that if accessibilityEnablesUserInteraction is set to false it will not be applied on first render. setting the default to true fixes that issue
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D76532158
fbshipit-source-id: 51cba8b89eb239e01db985d412dd2b19e482f068
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51979
Fix type checking that was left out from the last diff; D73224138
We should unify the type checking so remove uses of `java.lang.Boolean` and just use Kotlin version of `Boolean`.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D76523674
fbshipit-source-id: 293ae5998c78c98a20c7d6cf962ab7b19087fd9c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52048
This diff exports types defined in RNCodegen to be used by other codegens
changelog: [internal] internal
Reviewed By: christophpurrer
Differential Revision: D76472492
fbshipit-source-id: fa236a254a9a4211d2e00ace436f55978a262a76
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52041
After changing the publishing logic on Maven, the download logic for the artefacts published in a Snapshot was broken, because Maven does not support the redirect anymore.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76725418
fbshipit-source-id: 8bad88915d9bad96355a048486972a55f232d109
Summary:
Static code analysis reports numerous unused symbols across the codebase, which accounts for several static code analysis warnings. I've cleaned up some of them (not all of them because many of them are false positives from testing files)
The cleaned-up symbols are mostly private and from internal classes, so this should not impact users (unless they are used internally at Meta – in that case, let me know so I can revert accordingly)
## Changelog:
[INTERNAL] - Kotlin: clean up some unused symbols
Pull Request resolved: https://github.com/facebook/react-native/pull/52029
Test Plan:
```sh
yarn test-android
yarn android
```
Reviewed By: javache
Differential Revision: D76722313
Pulled By: cortinico
fbshipit-source-id: 8c7dfe204fa7c457b7484a7edd120ae45e1d604d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52035
Fixes https://github.com/facebook/react-native/issues/52014
Some OSS library is still returning null for `getViewManagerNames` especially if they're
implementing the `ViewManagerOnDemandReactPackage` in Java.
I'm adding a try-catch here so that we prevent the NPE for those scenarios.
Changelog:
[Android] [Fixed] - Fix crash on ReactInstance due to null returned for getViewManagerNames
Reviewed By: javache
Differential Revision: D76723826
fbshipit-source-id: cc159dee389257c6877b03a67840a45ee5bec165
Summary:
The OSS CI for iOS is broken because of a couple of commit that landed:
- Commit 05a61e8161 : dynamic frameworks are broken
- Commit abc8fe1c92 : pod donwload is broken
This change fixes both of them
## Changelog:
[Internal] - Fix OSS CI
Pull Request resolved: https://github.com/facebook/react-native/pull/52042
Test Plan:
Tested locally by building RNTester with Dynamic frameworks
```
USE_FRAMEWORKS=dynamic bundle exec pod install
```
Reviewed By: rshest, lenaic, GijsWeterings
Differential Revision: D76730331
Pulled By: cipolleschi
fbshipit-source-id: 71cca1f50763d24773dedcd8267130df261b01dc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52012
changelog: [internal]
On iOS, once a prop on a view is controlled by animated, the control is never released to Fabric or React. That's why it is important to use direct manipulation to commit even final value.
Reviewed By: lenaic
Differential Revision: D76601913
fbshipit-source-id: ea02219e158f28977018b34ac7152b899723b35a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52033
This change fixes the download of the artefacts for the nightlies of Hermes and React Native Dependencies after we changed the publishing logic for Maven
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76723289
fbshipit-source-id: 6b0ea6a6c35125e6fb03cecc6be893bd02abdad8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51946
This change simplified the setp disallowing to use JSC from core.
As a side effect, it simplified the setup by always falling back to hermes if the users decides not to use the third party JSC
## Changelog:
[iOS][Removed] - remove the option to use JSC from core
Reviewed By: cortinico
Differential Revision: D76342625
fbshipit-source-id: c925ab4fab1e171e289a1c5f75890c92da1b3f08
Summary:
I am not sure exactly why, but I've been getting this error when running RNTester on iOS, when it tries to build hermesc from source. We're clearing the env using `env -i` which seems to cause the issue. If I add PATH to the env we set then it builds fine.
```
++ hermesc_dir_path=/Users/janicduplessis/Developer/react-native/packages/rn-tester/Pods/hermes-engine/build_host_hermesc
++ shift
++ jsi_path=/Users/janicduplessis/Developer/react-native/packages/rn-tester/Pods/../../react-native/ReactCommon/jsi
+++ xcode-select -p
++ SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
++ env -i SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk /opt/homebrew/bin/cmake -S /Users/janicduplessis/Developer/react-native/packages/rn-tester/Pods/hermes-engine -B /Users/janicduplessis/Developer/react-native/packages/rn-tester/Pods/hermes-engine/build_host_hermesc -DJSI_DIR=/Users/janicduplessis/Developer/react-native/packages/rn-tester/Pods/../../react-native/ReactCommon/jsi
CMake Error: CMake was unable to find a build program corresponding to "Unix Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
Command PhaseScriptExecution failed with a nonzero exit code
```
## Changelog:
[INTERNAL] [FIXED] - Fix RNTester hermesc build issue on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/51989
Test Plan: Build RN tester locally
Reviewed By: cortinico
Differential Revision: D76606335
Pulled By: cipolleschi
fbshipit-source-id: f442b77aefb3afacd6d9fb1f3d515b8d63c526ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52020
Aligns the type exports of `ReportFullyDrawnView` across platforms, so that they are resilient to any changes made to `View` itself.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D76638685
fbshipit-source-id: 612b2bcd76e70751aec691a24f31beca453cea35
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52016
Upgrade the React Native monorep to use `eslint-plugin-react-hooks@6.1.0-canary`, which includes support for Flow's Component Syntax.
This does not affect production users of `eslint-config-react-native`.
Changelog:
[Internal]
Reviewed By: NickGerleman
Differential Revision: D76627448
fbshipit-source-id: 19e95e5d7f1bcd4fb6bead4e94d268d0c36a4817
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51425
# Problem
React native's new architecture will allow components to do sync render/events. That means they'll makes synchronous dispatches from main thread to the js thread, to capture the runtime so that they can execute js on the main thread.
But, the js thread already as a bunch of synchronous calls to the main thread. So, if any of those js -> ui sync calls happen concurrently with a synchronous render, the application will deadlock.
This diff is an attempt to mitigate all those deadlocks.
## Context
How js execution from the main thread works:
* Main thread puts a block on the js thread, to capture the js runtime. Main thread is put to sleep.
* Js thread executes "runtime capture block". The runtime is captured for the main thread. The js thread is put to sleep.
* Main thread wakes up, noticing that the runtime is captured. It executes its js code with the captured runtime. Then, it releases the runtime, which wakes up the js thread. Both the main and js thread move on to other tasks.
How synchronous js -> main thread calls work:
* Js thread puts a ui block on the main queue.
* Js thread goes to sleep until that ui block executes on the main thread.
## Deadlock #1
**Main thread**: execute js now:
* Main thread puts a block on the js queue, to capture the runtime.
* Main thread then then goes to sleep, waiting for runtime to be captured
**JS thread**: execute ui code synchronously:
* Js thread schedules a block on the ui thread
* Js thread then goes to sleep, waiting for that block to execute.
**Result:** The application deadlocks
| {F1978009555} | {F1978009612} |

## Deadlock #2
**JS thread**: execute ui code synchronously:
* Js thread schedules a block on the ui thread
* Js thread then goes to sleep waiting for that block to execute.
**Main thread**: execute js now:
* Main thread puts a block on the js queue, to capture the runtime.
* Main thread then then goes to sleep, waiting for runtime to be captured
**Result:** The application deadlocks
| {F1978009690} | {F1978009701} |

# Changes
This diff attempts to fix those deadlocks. How:
* In "execute ui code synchronously" (js thread):
* Before going to sleep, the js thread schedules the ui work on the main queue, **and** it posts the ui work to "execute js now".
* In "execute js now" (main thread):
* This diff makes "execute js now" stateful: it keeps a "pending ui block."
* Before capturing the runtime, the "execute js now" executes "pending ui work", if it exists.
* While sleeping waiting for runtime capture, "execute js now" can wake up, and execute "pending ui work." It goes back to sleep afterwards, waiting for runtime capture.
## Mitigation: Deadlock #1
**Main thread**: execute js now:
* Main thread puts a block on the js queue, to capture the runtime.
* Main thread then then goes to sleep, waiting for runtime capture
**JS Thread**: execute ui code synchronously:
* Js thread puts its ui block on the ui queue.
* ***New***: Js thread also posts that ui block to "execute js now". Main thread was sleeping waiting for runtime to be captured. It now wakes up.
* Js thread goes to sleep.
The main thread wakes up in "execute js now":
* Main thread sees that a "pending ui block" is posted. It executes the "pending ui block." The block, also scheduled on the main thread, noops henceforth.
* Main thread goes back to sleep, waiting for runtime capture.
* The js thread wakes up, moves on to the next task.
**Result:** The runtime is captured by the main thread.
| {F1978010383} | {F1978010363} | {F1978010371} | {F1978010379} |

## Mitigation: Deadlock #2
**JS Thread**: execute ui code synchronously:
* Js thread puts its ui block on the ui queue.
* ***New***: Js thread also posts that ui block to "execute js now". Main thread was sleeping waiting for runtime to be captured. It now wakes up.
* Js thread goes to sleep.
**Main thread**: execute js now
* Main thread sees that a "pending ui block" is posted. It executes the "pending ui block" immediately. The block, also scheduled on the main thread, noops henceforth.
* Js thread wakes up and moves onto the next task.
**Result:** Main thread captures the runtime.
| {F1978010525} | {F1978010533} | {F1978010542} |

Changelog: [Internal]
Reviewed By: javache
Differential Revision: D74769326
fbshipit-source-id: 854b83ce4e482a4030dc711834ea6c5613091537
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52000
Fixes https://github.com/facebook/react-native/issues/50338
The current JS FPS value is incorrect because the frame skipping logic hasn't been reimplemented in Fabric.
As we're looking into moving this into the performance panel, I've discussed with huntie
and agreed we'll just remove the value for now to don't show inaccurate informations.
Changelog:
[Android] [Changed] - Hide JS FPS on performance overlay as not accurate
Reviewed By: huntie
Differential Revision: D76590909
fbshipit-source-id: 90b0d9c84f9aefa9197243ebb57f4e86107d6c01
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52003
Changelog: [Internal]
This is a react common dep check that we can build and run tester.
Reviewed By: christophpurrer
Differential Revision: D76531041
fbshipit-source-id: 0a43fdb91aa61f7e6461ff8a94ea6e2732b55dbb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51982
This class should not be accessed externally. I'm making it internal.
On top of this, it was not fully reimplemented on NewArch so is not working consistently.
This is gonna break one library which is unmaintained and not properly udpated to work with NewArch
https://github.com/hannojg/react-native-performance-stats
Changelog:
[Android] [Breaking] - Cleanup and internalize FpsDebugFrameCallback
Reviewed By: huntie
Differential Revision: D76531175
fbshipit-source-id: 25598eb7c1ecf476b69bb6a2f2f8088a57b9fbc2
Summary:
This PR fixes RNTester system bars background color to match the app one (not solid black).
## Changelog:
- [Internal] [Changed] - Fix RNTester app system bars color when edge-to-edge is enforced
Pull Request resolved: https://github.com/facebook/react-native/pull/51929
Test Plan:
https://github.com/user-attachments/assets/8be0b721-6514-408f-81cd-2106ae7a17c4
Rollback Plan:
Reviewed By: javache
Differential Revision: D76352950
Pulled By: alanleedev
fbshipit-source-id: 474a81564570764a597aa995a0677617263338be
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51941
Changelog:
[Android][Fixed] - Extract out FBReactNativeSpec's core components including Unimplemented from auto-generated registry
Extracting out `FBReactNativeSpec`'s core components including `UnimplementedNativeView` from auto-generated registry. Using this `libraryName` to skip merging those modules
Reviewed By: RSNara
Differential Revision: D76371796
fbshipit-source-id: 4cfee0fe80a661f159a5f17e0d4abc60f601ea74
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52004
This is necessary because the snapshots are now going to be published on a different repository:
central.sonatype.com.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D76596802
fbshipit-source-id: 424fb1134e41502d53b76209fba325c895c79ba8
Summary:
Static code analysis shows that there are several redundant visibility modifiers across the codebase. These are most likely remnants after making different classes internal.
## Changelog:
[INTERNAL] - Kotlin: clean up redundant visibility modifiers
Pull Request resolved: https://github.com/facebook/react-native/pull/51960
Test Plan:
```sh
yarn android
yarn test-android
```
Reviewed By: javache
Differential Revision: D76503015
Pulled By: cortinico
fbshipit-source-id: e60e7aa141fc35ca2fd76335fbee791c86589e4e
Summary:
We found out that the XCFramework that is generated in CI is missing the headers.
This is happening because we run the setup script, the responsible to prepare the folder structure with the heaeders in the right place, only in the job that builds the slices. However, the headers are copied by the job that composes the XCFramework.
This change stores the header folder as an artifact in the build job and retrieves it in the compose job, so that the files are available to the XCFramework
## Changelog:
[Internal] -
Pull Request resolved: https://github.com/facebook/react-native/pull/52010
Test Plan:
Check the generated artefact in CI
<img width="292" alt="Screenshot 2025-06-13 at 15 32 02" src="https://github.com/user-attachments/assets/437333da-5848-4657-a9b3-e87fc79c69b2" />
Reviewed By: cortinico
Differential Revision: D76599834
Pulled By: cipolleschi
fbshipit-source-id: 44d74b5f8df545a825ecfe3df2e1898effe41261
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51693
This moves React Native to use the Central Portal URLs rather than the legacy OSSRH ones.
See https://github.com/gradle-nexus/publish-plugin for more context.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D75673984
fbshipit-source-id: 1de6746809eed72f232eac0c3fb4d809c2046620
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51991
This diff introduces a new parameter to customize libraryGenerators used in the codegen, since I'm adding a default object, this diff shoulnd't change any behavior
changelog: [internal] internal
Reviewed By: christophpurrer
Differential Revision: D76472495
fbshipit-source-id: 50b9095c7c554e368f65e4c0b5539be0cca51a51
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51990
In this diff I'm limiting visibility of internal objects of codegen, these objects are being exported but they are unused, let's avoid exporting them
changelog: [internal] internal
Reviewed By: christophpurrer
Differential Revision: D76470809
fbshipit-source-id: 0e168558d2d3211ab5a3a3de05e2495d7c1ae4f5
Summary:
FIXED Add index.js.flow to npm package files for Flow support
Currently, the distributed npm package for react-native does not include the index.js.flow file, which causes all exports to be typed as any when using Flow. This commit adds index.js.flow to the "files" array in package.json, ensuring Flow users receive proper type definitions out of the box. This addresses issues where type checking with Flow fails in React Native projects.
## Changelog:
[General][Added] Publish top-level Flow types for `react-native`
Pull Request resolved: https://github.com/facebook/react-native/pull/51908
Reviewed By: huntie, necolas
Differential Revision: D76292301
Pulled By: robhogan
fbshipit-source-id: e56360d3f35af30ef160470181349aac1812e7c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51966
This starts off mechanically, but needed a couple changes:
1. Some null handling changes to `TextTransform` internals
2. We type MapBuffer keys as `Int` instead of `Short`, because Kotlin does not allow the implicit widening cast that Java does. I also made these internal
3. Some shifts around casting
4. Mark TextLayoutManager internal, and remove usages of `UnstableReactNativeAPI`
I verified that there were no usages of the Java side of TextLayoutManager throughout `react-native-libraries`, so marking TextLayoutManager internal is unlikely to break 3p libraries.
Changelog:
[Android][Breaking] - Make Java Side TextLayoutManager Internal
Reviewed By: javache
Differential Revision: D76444163
fbshipit-source-id: aabb1c498c731598559f0df5c12e0ecdc266339f
Summary:
This diff adds macros around the legacy architecture core.
To compile out the legacy architecture, simply set: -DRCT_FIT_RM_OLD_RUNTIME=1.
* RCTBridge: interface kept around
* RCTRootView: interface kept around
* RCTSurface: interface kept around
* RCTModuleData: interface kept around (used by RCTProfile)
* RCTProfile: Kept around (doesn't work in bridgeless...)
* RCTCxxBridge: interface kept around
* c++ bridge: removed
* legacy components in core: kept around (for now)
## Details
I added comments to each of the #else, and #endif directives. That way, we can more easily codemod this code in the future.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D72582307
fbshipit-source-id: 018d11cc488e97e60040bebf647f24f2437a57ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51977
This will help the Kotlin migration of ReactDelegate.
Changelog:
[Internal] [Changed] -
Reviewed By: mdvacca
Differential Revision: D76518840
fbshipit-source-id: 8a24c20705aa6b04af693a6229235b11f30e0bc8
Summary:
Static code analysis shows that there are a lot of unresolved KDoc references. Also, there are a lot of functions incorrectly linked in the comments that were using `[.yourFunction]` instead of `[yourFunction]` – this diff addresses many of them.
## Changelog:
[INTERNAL] - Kotlin: fix up several KDoc annotations
Pull Request resolved: https://github.com/facebook/react-native/pull/51961
Test Plan:
```sh
yarn android
yarn test-android
```
Reviewed By: fabriziocucci
Differential Revision: D76481171
Pulled By: Abbondanzo
fbshipit-source-id: dd55e8fc3abfeaefc9c3762632a05fb7baf63530
Summary:
I've done a pass and cleaned up the changelog for 0.80 ahead of the release
Changelog:
[Internal] -
bypass-github-export-checks
Reviewed By: fabriziocucci, cipolleschi
Differential Revision: D76511997
fbshipit-source-id: 3872f9adbf16767c466e4dbb72d70fdaf2defde3
Summary:
This parameter can be null and is causing failures on some tests. This fixes
it.
Changelog:
[Internal] [Changed] -
bypass-github-export-checks
Reviewed By: lenaic
Differential Revision: D76505211
fbshipit-source-id: a23fca21daf5292bc7375e7d025d1202cc591b86
Summary:
This is to enable consuming RCTImage pod in mixed ObjC/Swift codebase. W/o this option set I get following error when building the library:
```
Installing RNScreens 4.11.1
[!] The following Swift pods cannot yet be integrated as static libraries:
The Swift pod `RNScreens` depends upon `React-RCTImage`, which does not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies.
```
I've noticed that there is also a precedent in the form of https://github.com/facebook/react-native/commit/c8fcac2765e0f79f0e7bb3a422a65698aec62536, which handled very simlar case but for `React-jsc` pod.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [FIXED] - Allow for consuming RCTImage in Swift codebase by enabling "Defines Module" option
Pull Request resolved: https://github.com/facebook/react-native/pull/51974
Test Plan: RNTester should build & run correctly
Reviewed By: cortinico
Differential Revision: D76505478
Pulled By: cipolleschi
fbshipit-source-id: bcce93ffc7e1c917da7f07db83a710575c659f45
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51965
Changes the error handling in `cli.js` scripts for `rn-tester` and `helloworld` so that the original error stack traces are preserved.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D76458284
fbshipit-source-id: 491b2bacc4becb8676a2ed4f1181192632bd808f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51962
Changelog: [Internal] - Migrate debug feature flag to be accessed in both native and JS
Reviewed By: yungsters, mdvacca
Differential Revision: D76381273
fbshipit-source-id: d4071abeb9769821e236c444f89044165cf83d92
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51944
Ahead of more refactoring, this cleans up a couple feature flags, already on by default, the newest of which added on 5/1, since these should all be validated by significant production usage at this point, so it is unlikely we would want to turn off.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D76412970
fbshipit-source-id: a2612583c060ed3f6fc559864e481d5b5a33fef2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51939
ReactRootView already reliably assigns itself a fresh root tag from its constructor. Assuming this `FabricUIManager.startSurface` method is called with a valid `ReactRoot` instance, we can just re-use the existing tag without minting a new one. This makes some native initialization that depends on root tag assumptions easier to setup.
## Changelog
[Internal]
Reviewed By: javache
Differential Revision: D76370069
fbshipit-source-id: ad9bb91eee374c911f65ebcdd395716c77881e96
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51958
There is a copy and paste mistake, from dependencies to core, when uploading artefacts to maven.
This change fixes it.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76435336
fbshipit-source-id: a829b90ba3d4cbfc5528fc9f21dcee7be6a358ff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51893
This diff adds `--validate` flag that runs snapshot validation to determine if the `ReactNativeApi.d.ts` rollup has been changed (if JS public API has been touched). There was also an issue with `sortProperties` that reordered some properties (ex. in ImagePropsBase) after removing one of them (ex. accessible) which had negative impact on the displayed result.
### Motivation
Compare previous snapshot with the one built on the current revision to determine the impact of made changes on the public API surface. Display differences in human readable format using `diff` method from the `jest-diff` library.
For now `--validate` flag is not useful on its own. It should be used with `--withSnapshot` flag (which will be removed shortly and generating snapshot will be a default mechanism).
Changelog:
[General][Added] - Add `--validate` flag to `build-types` script for JS API snapshot validation.
Reviewed By: huntie
Differential Revision: D76135158
fbshipit-source-id: 53f5b142c66e3e3931961f741c3f2fab8ccdc228
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51957
We need to rename the artifacts correctly for Sonatype to pick them up.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76428060
fbshipit-source-id: 83f1da75fbbdd4317ec791a6e782bbaa5c05fa5c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51956
While working on landing the prebuild for React Native core in CI, I forgot to add a strong dependency between the build_npm_package job and the prebuild_react_native_core job in the workflow.
It was still technically working, because there are other jobs that are slower than building react_native_core that will delay built_npm_package for enough time, but this fix will make it more robust.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76423766
fbshipit-source-id: 76d91901d63e95add62f26bbff4de0278e8609e3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51948
TSAN is showing a data race in RuntimeScheduler_Modern::updateRendering.
# Changelog:
[Internal] - Use atomic to unblock broken tests. eventTimingDelegate_ is only set once during startup, so the real fix here would be to delay runEventLoop until setEventTimingDelegate has been set.
Reviewed By: javache
Differential Revision: D76415742
fbshipit-source-id: 995d2a68d671c555f990b4f8d85ac9419ae2734c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51923
This diff publishes the Reactcore prebuilds to Maven central so that apps can use it when integrating with React Native
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76338793
fbshipit-source-id: 777c91805573b90ef15209e196cd66801908a5ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51921
Implemented the CI jobs that builds React Native core in CI and uploads the artifacts for the Debug and Release XCFrameworks and dSYMs
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76338031
fbshipit-source-id: 713fd82f3823c992c3b0fa5cf24952b793834c68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51919
Implement signing for the React Native core XCFramework
The implementation follows the same approach we used for the ReactNativedependencies archive
## Changelog
[Internal] -
Reviewed By: cortinico
Differential Revision: D76337972
fbshipit-source-id: 74f61c087b31e4087752cd60bea59db15f00321b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51920
Introduce the BuildFlavor typeand refactor the build scripts to use 'Debug' and 'Release'.
For iOS we always use capitalized Debug and Release and it will make it easier to work with CI too.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76338034
fbshipit-source-id: ae1acc740b47692ec5eee94c897b49a0e1673b93
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51931
This cleans up the whole `JSEngineResolutionAlgorithm` and all the API related to it.
As now we offer support only for Hermes and JSC is provided via a community package.
This is breaking as it affects Expo, but I'll reach out to Kudo to make sure this is integrated properly.
No other breakages other than this.
Changelog:
[Android] [Removed] - Remove and cleanup JSEngineResolutionAlgorithm
Reviewed By: mdvacca
Differential Revision: D76337620
fbshipit-source-id: e43d5d1164f368f5fa395971bca9c05821492dfe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51940
We are seeing some reports of badf00d fads (stalls), meaning we are likely doing too much work here. `accessibilityElements` gets called a lot, and is often cached so lets add that in.
Changelog: [Internal]
Reviewed By: jorge-cab
Differential Revision: D76371136
fbshipit-source-id: f9e3423e8135a47a24291b04150c4dc54afbda82
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51937
Updates the `set-versions` script to also update workspace packages in `private/*`. Unlike with packages in `packages/*`, this does not change their `"version"` fields, though. It only updates their dependencies.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D76358273
fbshipit-source-id: d0e0557d17c355828020a218083b98dd177a6732
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51922
changelog: [internal]
fix existing C++ Animated tests and align with Android on how to go from current time to applied frame.
On iOS [floor](https://fburl.com/code/7zy5e5ul) is used to decide which frame to apply. On Android, [round](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/animated/FrameBasedAnimationDriver.kt#L65) is used.
In D75813200 I chose to use `std::ceil` as I wanted to have a predictable behaviour in tests. This is not wrong but it is better to align at least with one of the existing implementations. Let's go with Android as it strikes the balance of what we want to see in tests (an animation that is running for 1000ms should finish after 1000ms, not 1000ms + one frame) and C++ Animated is closer to at least one of the existing implementations.
Reviewed By: christophpurrer
Differential Revision: D76337384
fbshipit-source-id: 444c94d88c2fa60bb4f0649f57e0e42f5cd27626
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51859
Moves `tools/apis` to `private/cxx-public-api` and cleans up a few things:
- Clean up the `BUCK` file a bit.
- Deduplicate relative paths in scripts.
- Prefix the private package name with `react-native/`.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D76091765
fbshipit-source-id: 6fac7423f9d205085b0b21465f65075a850b61e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51858
Creates a new private package for the ESLint rules that are defined in the `facebook/react-native` repository for linting the monorepo itself: `react-native/eslint-plugin-monorepo`
It resides in a new `private/` directory that will be used for all private packages. I plan to move private packages over from `packages/` and `tools/`.
This also eliminates the need for the `eslint-plugin-lint` dependency in open source.
Changelog:
[Internal]
Reviewed By: cortinico
Differential Revision: D76088698
fbshipit-source-id: 697d5d91421cda4ef3f96d0497a96954cd047296
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51881
Switches the suppression of ESLint for the generated `sort-imports` lint rule definition to using in-file comments instead of `.eslintignore`.
This makes the suppression more portable. If the path to the lint rule definition changes, we don't have to remember to update `.eslintignore`.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D76152973
fbshipit-source-id: 7cc41282931788c9e347712e7ce8bf7fefb53858
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51880
Updates the `sort-imports` lint rule.
The main change is that it enforces newlines after the last import statement.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D76149902
fbshipit-source-id: 928871655c5de0613b18334d6fc0d71b3a971a18
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51904
Replaces `chalk` with Node's `util.styleText` in `scripts/build/` and `scripts/build-types/`.
Will follow up with replacing across the entire repo at a later point.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D76037191
fbshipit-source-id: c28352853f22d455a709f4b752f566626e6fb3fe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51907
changelog: [internal]
fixes a crash that is described by the two tests. The two tests cover both changes made to Differentiator.cpp. If you revert either of the change, a test will crash.
Reviewed By: christophpurrer
Differential Revision: D76231984
fbshipit-source-id: c32ab1851844121095f1dec953befb2e77c83fd4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51875
This diff raises the logLevel of assertion LegacyArchitecture classes when minimizing of legacy architecture is enabled
Reviewed By: rshest
Differential Revision: D76080325
fbshipit-source-id: 75c92ba7fc54cfbc76bbc2fa3c3dc6a72a376c8f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51876
This diff raises the logLevel of LegacyArchitecture classes when minimizing of legacy architecture is enabled
Reviewed By: cortinico
Differential Revision: D76080324
fbshipit-source-id: 3764c0657b912db81e0dc46b6eb57cbb02b335ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51872
This converts to Kotlin and internaline MountingManager.
The only usage in OSS is react-natve-live-markdown:
https://github.com/Expensify/react-native-live-markdown/issues/693
They're using reflection to access Mounting Manager, which they shouldn't.
Other than them, I wasn't able to find meaningful usages of `MountingManager`
Changelog:
[Android] [Breaking] - Convert to Kotlin and internalize MountingManager
Reviewed By: rshest
Differential Revision: D76126338
fbshipit-source-id: 5ab491f86d697a82b8e5b02b031877020dfa3e9e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51836
Currently, `community-cli-plugin` loads the user config and then overrides parts of it - specifically `resolver.resolveRequest` and `serializer.getModulesRunBeforeMainModule`, making it impossible for a user to modify this config.
Instead, treat the CLI's resolver and serializer customisations as "Framework defaults", layered on top of `react-native/metro-config` defaults but beneath a user's `metro.config.js`.
This allows the user to obtain (via `react-native/metro-config`'s `getDefaultConfig`) and extend or override them, if they need to.
This is technically breaking because users who currently have a custom `resolveRequest` or `getModulesRunBeforeMainModule` in their `metro.config.js` will have that config respected from this change, whereas currently they won't have any effect.
Changelog:
[General][Breaking] Community CLI users: user-defined `resolver.resolveRequest` and `serializer.getModulesRunBeforeMainModule` Metro config now takes precedence over CLI defaults
Reviewed By: huntie
Differential Revision: D74811395
fbshipit-source-id: c250caf798fdaedb0822bea3d6e65c0c3ae4d691
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51844
These just redefine the existing `receiveCommand` from the ViewManagerDelegate which already has this codegen'ed
Changelog: [Internal]
Reviewed By: cortinico, rshest
Differential Revision: D75869325
fbshipit-source-id: c8ba482075c2586caf33f46a871b5b5e16fda213
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51890
changelog: [internal]
Fixing possible build failures when targets are built in different context:
- Adding includes to used std functions.
- Using explicit jsi namespace.
- Declaring dependency.
Reviewed By: javache
Differential Revision: D74878821
fbshipit-source-id: 9dfd7ba94651280331be6c9fe6948fce50955589
Summary:
Minor Typo correction.
## Changelog:
[INTERNAL][FIXED] updated description of Maestro E2E Android.
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/51887
Test Plan: NA
Reviewed By: cipolleschi
Differential Revision: D76253803
Pulled By: cortinico
fbshipit-source-id: 16e8b793de4f7bb4eba03f20e09c3cf3d05115b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51806
Correct the type of args, which is always non-null. This is backwards-compatible as subclasses can override this method with a more permissive nullable type and still be substitutable.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D75869317
fbshipit-source-id: 8f6c9119140794447eca55be24483a35450d7bb6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51873
After [51865](https://github.com/facebook/react-native/pull/51865), the path were the apk are generated changed. That broke the e2E tests in ci and the local script to test E2E, because the artefacts were not uploaded to CI properly.
This change should fix it
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76133191
fbshipit-source-id: 70d8567dee8dc2a8bcc656cca7e94ad19101fe28
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51850
This change refactors the last compose-xcframework step to intgrate with the cli.js script to coordinate the build process.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76046443
fbshipit-source-id: 4740bb0869c688611a03d5085771aa6222132e7e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51845
This change refactors the build step of SwiftPM to use the cli.js script to coordinate it.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76046444
fbshipit-source-id: 7aa4ba55e46c2e4502687f035ba1e7bf772b3079
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51848
This change refactors the script by moving the step to setup the repo properly in a separate `setup.js` file.
This allows to simplify the main script by using the cli task.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76046441
fbshipit-source-id: 1da6f8dabf75640e455fcb2f543164c6a242abe0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51849
This simple change refactors the code of reactNativeDependencies to have more accurate logging when the step fails in CI
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76046440
fbshipit-source-id: 2a1105285b0b1d5208a99c30d6ec2859bb8a0187
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51846
This change introduces a cli script to simplify handling of tasks when building React Native with Swift PM
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76045574
fbshipit-source-id: 334d0502e781710f3744d9a3585ccfe7f2fa0038
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51847
This change introduces a types.js to add some useful flow types to build React Native with Swift PM.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76045454
fbshipit-source-id: 352e9f1a2845106c49461c3ac66188f49b520eb3
Summary:
This commit adds support for building XCFrameworks from the prebuild-script
- Added build script to help build xcframeworks
- Added full header file structure
- Added calling the build script from the main prebuild script
TODO: We need to add resources / privacy bundles
## Changelog:
[IOS] [ADDED] - Added building XCFframework from the prebuild script
Pull Request resolved: https://github.com/facebook/react-native/pull/51596
Test Plan: Run prebuild script and verify that XCFrameworks are successfully built.
Reviewed By: cortinico
Differential Revision: D75869879
Pulled By: cipolleschi
fbshipit-source-id: 7da1dfe2bea34966b88bdb0c31bf7c6ada420c57
Summary:
This commit adds building the swift package from the prebuild script:
- Added swiftpackage.js for building the swift package
- Added calling building from the main script
- Added configurable build type from the main script.
- Removed params in jsdoc from the link method
## Changelog:
[IOS] [ADDED] - Added building swift package from the prebuild script
Pull Request resolved: https://github.com/facebook/react-native/pull/51595
Test Plan:
Run prebuild script and verify that the Swift package is successfully built.
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D75865275
Pulled By: cipolleschi
fbshipit-source-id: d4d9f26c817eb15c16f6be52ffa4b9f060e789da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51840
Bumps the minimum version of Node.js in React Native to the current active LTS release (22.x, upgraded from 18.x which is now out of support).
- CI configurations are reduced from `[22, 20, 18]` to `[24, 22]`.
{F1978909878}
See https://nodejs.org/en/about/previous-releases.
Changelog:
[General][Breaking] - Our new minimum Node version is Node.js 22
Reviewed By: yungsters, cortinico
Differential Revision: D76037015
fbshipit-source-id: b6e4b3ee279a9a93d716a13297420bba73f45250
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51866
We're not really running those tests in OSS. They would require an emulator in OSS CI which
is costly and flaky. I'd rather remove the build logic for them and rely on Fantom for those kind
of tests in the future.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D76050039
fbshipit-source-id: 29789a9c7db5c7108c4536db620d83640819874f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51865
As in 0.81 we're stopping 1st party support for JSC, we can now cleanup the RNTester
flavor for JSC and simplify the setup here.
Changelog:
[Internal] [Changed] -
Reviewed By: rshest
Differential Revision: D76051319
fbshipit-source-id: 79b01cc64af2466a0be47ceaa0cd211cb6b02f53
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51854
AGP 8.10.x comes with a source breaking change:
https://issuetracker.google.com/issues/416890061
This shoudl fix it and unblock us for the 0.81 release.
Changelog:
[Android] [Changed] - Bump AGP to 8.10.x
Reviewed By: huntie
Differential Revision: D76053989
fbshipit-source-id: b0fe19544c79d65002127176f2722cdfd85f0a3c
Summary:
PR https://github.com/facebook/react-native/issues/51078 Implemented finding disabled libraries but the code (below) didn't actually filter any libraries out because destructured name is `undefined`. This pr adds the name to codegenEnabledLibraries so filtering would work.
```js
const libraries = codegenEnabledLibraries.filter(
({name}) => !disabledLibraries.includes(name),
);
```
## Changelog:
[IOS] [FIXED] - Skip codegen for selectively disabled libraries in react-native.config.js
Pull Request resolved: https://github.com/facebook/react-native/pull/51838
Test Plan:
1. Install a library that has the componentProvider field set in the codegen config (for example: react-native-safe-area-context and react-native-screens or see [reproducer](https://github.com/aattola/rn-codegen-exclude))
2. Exclude library with react-native.config.js
3. install pods / run codegen
4. Check that codegen actually excluded the specified dependencies from: `ios/build/generated/ios/RCTThirdPartyComponentsProvider.mm`
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D76044622
Pulled By: cipolleschi
fbshipit-source-id: 9e70c2a263c750edb1ea95305c9e5e178e2ce8d8
Summary:
When building Android in cloud environments, it turns out that in some of the environments, `sdkmanager` is not in any of the paths checked in `packages/react-native/ReactAndroid/hermes-engine/build.gradle.kts`, so the build fails.
I have added the path for the Linux cloud build environments I have been using (EAS).
I have also added the ability to insert a custom value for the path, in case this problem occurs again in future.
## Changelog:
[Internal][Fixed] - Allow more sdkmanager paths in hermes-engine Android build.
Pull Request resolved: https://github.com/facebook/react-native/pull/51829
Test Plan: Tested the changes in CI builds in EAS.
Reviewed By: rshest
Differential Revision: D76117000
Pulled By: cortinico
fbshipit-source-id: 2c8aff1ba4f03dbe77935992a774ed71f85264a3
Summary:
Part of https://github.com/facebook/metro/issues/1480
This PR adds a check in `HMRClient.js` that prevents processing `registerBundle` calls coming from different origin than the one declared in HMR `setup()`.
This is useful in a Module Federation setup, where we have multiple HMRClients present in runtime - when Host loads external remote, the requestURL will have different origin, but it will be processed by the HMRClient from the Host which in turn causes a runtime error.
## 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
-->
[GENERAL] [ADDED] - Process HMR registerBundle calls from the same origin only
Pull Request resolved: https://github.com/facebook/react-native/pull/51821
Test Plan: TBD
Reviewed By: christophpurrer
Differential Revision: D76044353
Pulled By: huntie
fbshipit-source-id: 3928347b1e9a90355d02b87b07fde812479bcb67
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51808
Pull Request resolved: https://github.com/facebook/react-native/pull/50292
## This diff
Generates types via `yarn build-types` and verifies them on the basis of react-native/types/__typetests.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D71902007
fbshipit-source-id: 43cb2321e9feea11b0caa4362140c86b1847db85
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51856
Enables the `enableEagerAlternateStateNodeCleanup` feature flag in the open source React Native renderers that are currently targeting React 19.1, by manually patching them in the React Native repository.
This feature flag has been found to significantly improve memory management of parent alternate fibers in persistent modes (i.e. Fabric), and we want this to be available to open source users of React Native before the next scheduled public version release of React.
For more details about the fix, see: https://github.com/facebook/react/pull/33161
Changelog:
[General][Changed] - Reduces memory usage, by improving memory management of parent alternate fibers. (Previously, a parent fiber might retain memory associated with shadow nodes from a previous commit.)
Reviewed By: rickhanlonii
Differential Revision: D76073900
fbshipit-source-id: 6779ea0862d4a1e25354b12ef3d1363dc12d26cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48783
## Overview
This is the final boss of the new owner stacks feature. With owner stacks, we don't need to parse message strings to find the component stack for logbox. Instead, we can access the component stack directly with `captureOwnerStack`.
This means we don't need to install the LogBox console.error patch and can greatly simplify the process of handling errors and make it more reliable.
To do this, we rely only on adding LogBox to the ExceptionManager:
- `reactConsoleErrorHandler` -> `LogBox.addConsoleLog`
- `reportException` -> `LogBox.addException`
Changelog:
[General][Fixed] - Remove LogBox patch, de-duplicating errors
## Benefits
As a side effect, this removes a lot of duplicate errors. For example, currently if a component throws, you get 2 errors:
{F1974436906}
After this, there's just the one you expect:
{F1974436908}
## Followups
After this lands and doesn't need reverted for some reason, we can delete a ton of code from logbox for finding and detecting stacks from errors.
Reviewed By: javache
Differential Revision: D68380668
fbshipit-source-id: 68112f1e3992fada4d6aaffdf9bd618ce1834f7b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51843
Changelog: [Internal]
To avoid corrupting the React fiber tree when committing from multiple threads this diff only updates shadow node references within the fiber tree for commits originating from React.
This guarantees that during the update of the references no React render will start or is running, making the update of the shadow node reference safe to execute.
S527994
Reviewed By: sammy-SC
Differential Revision: D76043845
fbshipit-source-id: bfcbeaae7fc8b976a1c2db6682330cef9ca25ab8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51725
This change builds upon the focus/blur portion showcased in ViewExample but showcases several more components all in one spot. This can be shared with additional platforms or expanded to include more component examples like Image, but the goal is to target Android and not distract from the primary use cases.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D75747410
fbshipit-source-id: 7d53366d9f32192ca6b3da45dd127836fb6efdf6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51724
Moves focus change listener logic from `ReactViewManager` to `BaseViewManager` so all view managers that extend the class can get focus/blur event dispatching for free. This does so by applying event listeners where `addEventEmitters` is called, so any extending classes must try to call `super.addEventEmitters` or implement it themselves. In the case of TextInput, this logic is re-implemented because the component emits an additional event when the text input is blurred and I wanted to avoid duplicate calls to get the event emitter for the view instance.
In addition, I've added logic and a test case to ensure that any preexisting focus change listeners set on the view instance are called. There can only ever be one focus change listener tied to a view instance, so this ensures that ones created during view instantiation are retained. However, this does not guarantee that events are emitted for downstream users who overwrite the focus change listener later in the view's lifecycle (i.e. in response to a prop change or an extending view manager that doesn't call `super.addEventEmitters`). There is no clean way to enforce that the `BaseViewManager` focus change listener is always set without changing the generics and introducing a significant breaking change.
Changelog: [Android][Added] - Adds support for onFocus/onBlur event dispatching logic to all native views that implement `BaseViewManager`
Reviewed By: NickGerleman
Differential Revision: D75579321
fbshipit-source-id: 02e1e6d0e78e9d05e4ec5bb59789f3097b73b3f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51791
On iOS the <Image> shadow node was expecting a layout call for every clone. With `passChildrenWhenCloningPersistedNodes` <Image> components may have the image source updated without layout being called on it due to the re-use of the previous layout data thanks to the improved handling of layout invalidation.
This diff triggers the image request as soon as possible if the cloned shadow node has a clean layout. The request will be made as soon as the image manager is set on the shadow node.
Changelog: [iOS][Fixed] - Fix RCTImageComponentView image loading after source props change with no layout invalidation
Reviewed By: NickGerleman, sammy-SC
Differential Revision: D75919671
fbshipit-source-id: 8b92a9c63b6ff4a62c7eb7b0dbe18dd2be989b81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51827
TextLayoutManager has an optimization today, where it reuses a scratch TextPaint throughout layouts.
This is not safe in Facsimile, since the paint is included as part of `Layout`, and the `Layout` escapes the TextLayoutManager, to later be drawn. I.e. every `PreparedLayoutTextView` right now is sharing this same scratch Paint.
This change makes it so that we only ever use a scratch paint for the purpose of measurements, where the layout is short-lived.
A simpler approach could be to just abandon the scratch TextPaint, since they do not seem wildly expensive at a glance (though not trivial).
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D75987605
fbshipit-source-id: 3fe3519c6164828a25cb4e2b0ee6eded73695a95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51853
While testing D75988059 with D76047973, I noticed a few opportunities to improve the script used by `yarn lint-ci`:
- The exit code does not currently propagate, meaning `lint-ci` will succeed when it shouldn't.
- The shell script uses some non-idiomatic practices, so this improves it.
Changelog:
[Internal]
Reviewed By: kassens, cipolleschi
Differential Revision: D76049502
fbshipit-source-id: ebefddf0909edc89cd97de756b93bfaaa3d7cdef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51670
As the title suggests, forwards `onBlur`/`onFocus` props into the Pressability config that the component creates
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D75238328
fbshipit-source-id: ebc955ab603012362b6fd021333ab61c54ef3f72
Summary:
https://github.com/facebook/react-native/pull/49927 introduced a regression where a Ruby script would read compilation artifacts and fail, when the user has relative build directories set in XCode.
After successful compilation `build/` dir and `DerivedData/` dir have `.plist` files that aren't in UTF-8 encoding and shouldn't be read by the script. If the user tries to reinstall pods at this point, he gets the following error:

This is how you enable relative build directories in XCode.

## Changelog:
[IOS] [FIXED] - Ignore `build/` and `DerivedData/` directories when reading `.plist` files.
Pull Request resolved: https://github.com/facebook/react-native/pull/51833
Test Plan: After applying this patch the problem doesn't occur anymore on my machine.
Reviewed By: cortinico
Differential Revision: D76030133
Pulled By: cipolleschi
fbshipit-source-id: 7ae8c2d0ce28b6925245a9172154e3dcafee126f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51826
changelog: [internal]
To make this possible, we "fake" a UI tick whenever `flushMessageQueue` is called. This was, after every JavaScript task a UI tick happens.
Result:
- Animations are setup right after mounting automatically.
- Animation happens after Fantom.scrollTo is called.
Reviewed By: lenaic
Differential Revision: D75899915
fbshipit-source-id: 1ccb86df6741ff9124f16073c6d61ba716d7cfe6
Summary:
Migrate com.facebook.react.views.text.ReactTextViewManager to Kotlin.
In this diff, `ReactTextAnchorViewManager` is made public again as it's extended by `ReactTextViewManager`.
## Changelog:
[INTERNAL] - Migrate com.facebook.react.views.text.ReactTextViewManager to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/51721
Test Plan:
```bash
yarn test-android
yarn android
```
Reviewed By: mdvacca
Differential Revision: D75829457
Pulled By: NickGerleman
fbshipit-source-id: 425e9ec14f17de5470677b73d68873647bf28675
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51824
Configures ESLint to require `flow` (or `noflow`) annotations for JavaScript files in the React Native repository. This ensures that we uphold a high bar for type safety and correctness, or intentionally deviate when it makes sense.
Changelog:
[Internal]
Reviewed By: NickGerleman
Differential Revision: D75985490
fbshipit-source-id: 56f9fe7666a02c796ceb9cf076677e81b164b65e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51822
Adds `flow` to the remaining files without it, in React Native.
After this, every `*.{flow,js}` file in React Native will have either `flow` or `noflow`.
Changelog:
[Internal]
Reviewed By: NickGerleman
Differential Revision: D75980238
fbshipit-source-id: 84cd88e4eb0b0b1dc69df247de79a75c2119bf96
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51759
Builds upon the changes in the last diff, to let Facsimile support `ReactTextViewManagerCallback`. We use the same new mechanism, of using `RCTTextViewManager` as the callback, if present, instead of relying on view manager measure function.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D75830964
fbshipit-source-id: 435798e6be08f579579eb0f2d30a67d4b1fcaf10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51758
ViewManager’s may implement a measure function (using MapBuffer, or ReadableMap). This isn’t used automatically, but may instead be used, by calling into FabricUIManager via JNI, and passing the component name of the view manager to use.
This is only ever called manually, through specific C++ ShadowNodes. Confusingly, for some cases, like `TextInput`, we use the measure function on `RCTText` instead, because this call to FabricUIManager is hidden behind `TextLayoutManager`. This ends up really breaking Facsimile, since we want to measure these in a different way, while still measuring `TextInput` without preparing a layout.
This mechanism is also used to inject `ReactTextViewManager` from the Text View Manager, into the measurement process, for both Text, and TextInput.
I think we would ideally remove and replace the current View Manager measurement mechanism entirely. The interface doesn’t do what it claims to, and requires calling private Java methods via JNI, which we shouldn’t be encouraging external libraries to do. Only a single 3p librar (react-native-picker) uses this, but we have a lot of internal usages, and the current facility is valuable, for translating surface ID into a context. Ie we could not deprecate it without a well thought out replacement.
Instead, this change:
1. Removes the "generalized" version of this for MapBuffer, only ever used by Text
2. Given ourselves a `measureText` function, that will use a spannable processor provided, but go through TextLayoutManager, instead of trying to use this generalized path
3. Documents some of the weirdness of the current setup, without yet deprecating it
This will let the Facsimile View Manager:
1. Provide a ReactTextViewManagerCallback, like the previous version allowed, that influences measurement of both Text, and TextInput (which is... strange, but... not trying to boil the ocean here)
2. TextInput can now measure text, even if Facsimile View Manager doesn't implement this traditional measure interface
Changelog:
[Android][Breaking] - Remove FabricUIManager.measureMapBuffer() and MapBuffer measure functions on ViewManager. Please use ReadableMap variant.
[Android][Breaking] - Remove FabricUIManager.measure overload which accepts attachment positions
Reviewed By: javache
Differential Revision: D75826792
fbshipit-source-id: 6739b1e2e214351b9b95ba782d73cf4278211ab8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51692
The original algorithm for accessibilityOrder on Android had unexpected bugs. For some reason `.traversalAfter()` and `traversalBefore()` have unexpected behaviors when dealing with ancestor/descendant relationships getting more and more unexpected the further apart they are.
So we are ditching that approach entirely.
Now we have the view with accessibilityOrder create a virtual view hierarchy. We create a virtual node for each child that is in the order, and set the virtual node's position to be the same as the View it is trying to represent.
We then also populate that node with the same stuff we populate regular ax nodes with the `populateAccessibilityNodeInfo()` function and the content description of the view it is backing so we get matching descriptions with what would otherwise be the normal announcement.
**We have no way to exhaustively check every accessibility use case so we'll have to fine tune this as bugs come up, I'm expecting there to not be many issues since we populate the node the exact same way we populate every other node but anything that happens before React Native handles the node might miss some things**
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D74766296
fbshipit-source-id: 5e77c17bed1644bc5fbf5c1e19c3c6908cc1e3e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51762
Apple requires Xcode 16 or later to submit to the app store. Let's bump the minimum checked for in build logic as well. https://developer.apple.com/news/upcoming-requirements/?id=02212025
GHA is already only testing against 16.2.0 as of D73924819
Changelog:
[iOS][Breaking] - Bump min Xcode to 16.1
Reviewed By: cipolleschi
Differential Revision: D75835304
fbshipit-source-id: a7ce22f958be3a5448a279439e27b615e9b20a2f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51794
Adds `flow` to the remaining mocks and tests that are lacking it in the `packages/react-native` directory.
This required adding numerous type annotations and suppressions.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D75930095
fbshipit-source-id: ebb1280adc656680e00fd579701e31521826b55c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51792
Adds `flow` to the remaining files that are lacking it in the `packages/react-native/Libraries/Alert` directory.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D75921478
fbshipit-source-id: e277cf8241b136da1409af2592fda6ec1f7e9502
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51790
Adds `flow` or `noflow` to the remaining files that are outside of `packages/react-native/{Library,src}`.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D75904614
fbshipit-source-id: cb2c0969065cf443c3a6e74da0fa3708fda67d18
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51789
Adds `flow` or `noflow` to the remaining files that are lacking it in the `packages/helloworld` directory.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D75899853
fbshipit-source-id: 43990adb0827f35a8ca8c49c1787140ff47b8abb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51788
Adds `flow` to the remaining files that are lacking it in the `packages/rn-tester` directory.
This also adds any necessary type annotations and fixes lint warnings.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D75899307
fbshipit-source-id: 27a74ed0007b3b754446a45931c2c148312d5e3a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51785
Adds `flow` to the remaining files that are lacking it in the `packages/virtualized-lists` directory. In one of the Jest tests, there are so many failures that for now, I just added `noflow`.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D75888514
fbshipit-source-id: 29d96292f3d59fd5cf2f5ba09b58fdfb9eabab2e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51784
Adds `flow` to the remaining files that are lacking it in the `packages/react-native-fantom` directory.
This also adds any necessary type annotations (using comment syntax).
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D75886119
fbshipit-source-id: 6045b4037da21791db2a8960fbdb83aa2fb5bbf2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51782
Adds `noflow` to a test in `packages/react-native-compatibility-check`.
In the future, this file should be migrated to use `flow strict-local` or `flow strict`. However, it currently has way too many type errors. Adding `noflow` makes it explicit that this is known to not be typechecked.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D75885038
fbshipit-source-id: d0eccda52d39e7cb1938d395c44e4441918f7fcb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51781
Adds `flow` to the remaining files that are lacking it in the `packages/react-native-codegen` directory.
This also adds any necessary type annotations (using comment syntax).
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D75884727
fbshipit-source-id: 69e880b2dc63c3d6430f841652506e57436544a8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51780
Adds `flow` to the remaining files that are lacking it (or `noflow`) in the `scripts` directory.
This also fixes what I believe to be a typo in one of the files.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D75883851
fbshipit-source-id: 928b7a12a08269b6643379d46de888f2c61dcb29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51779
Adds `noflow` to a bunch of Node.js script files.
In the future, these files could be migrated to use `flow strict-local` or `flow strict` using comment syntax for type annotations. But for now, adding `noflow` makes it explicit that these are known to not be typechecked.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D75883703
fbshipit-source-id: a8fed3aaa9c55ecda919a705940f8b34504cb07c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51778
Adds `noflow` to a bunch of ESLint and Babel files that are expected to be evaluated using Node.js without Babel. Additioanlly, these files tend to depend on ESLint and Babel type definitions that are not currently readily available.
In the future, these files could be migrated to use `flow strict-local` or `flow strict` using comment syntax for type annotations. But for now, adding `noflow` makes it explicit that these are known to not be typechecked.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D75883642
fbshipit-source-id: 54236d123ca8773de42bce81189dfb5c0671563e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51777
Just adding `flow` to these two libdefs that aren't sourced directly from `flow-typed/flow-typed`.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D75877692
fbshipit-source-id: 0ee0ec08e2046fdba38480cddca3686109e8ca45
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51814
changelog: [internal]
introduce Fantom.unstable_getDirectManipulationProps to make it possible to inspect what is changed by C++ Animated module before animation finishes.
Reviewed By: zeyap, rubennorte
Differential Revision: D75816105
fbshipit-source-id: 681829ca9d3f77e57213e9f88f4f24b340a982ed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51680
Right now there are 2 flavors of vertical text alignment: `verticalAlign` and `textVerticalAlign`. Both do the same thing currently. For Facsimile, we actually want to "properly" implement `verticalAlign` so that it matches the web version, while leaving `textVerticalAlign` the same. That will take some time, however, so for now we are just going to implement the way it currently works, while fixing some issues with inline View's
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D75475915
fbshipit-source-id: ba6ff7c831bf769e9e60831ed215ab64faf143a4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51712
This prop only works on top level text components, yet it is stored as a TextAttribute. It should be a ParagraphAttribute, so I moved it there.
Changelog: [Android] [Breaking] - Move textAlignVertical to paragraph attributes instead of text attributes
Reviewed By: NickGerleman
Differential Revision: D75684576
fbshipit-source-id: 8ad2496f8a043a6a64924a6c43c7bad4593cf1db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51711
This is needed to support textVerticalAlign as we are storing that offset in the prepared layout and need to read it from the new text view
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D75643360
fbshipit-source-id: 03620ecf09f525c45d0a60daad1dc1d9a5937362
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51810
Tweaking the visiblity of some of the fields `NativeModuleRegistry` after the Kotlin migration
of that class.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D75959962
fbshipit-source-id: b3d53fc29af3b0fe32a7bd6a61898814acf90123
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51807
Remove unneeded deps from the build graph. Especially `//xplat/folly:logging_logging` ends up adding 418KB in development which is unused here.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D71316272
fbshipit-source-id: 39a73e26728cee23d4ffbdd5e4760de2029e671b
Summary:
There is an edge case in the codegen `findRCTComponentViewProtocolClass` function where the parsing of the Component Class will fail if there is another `.class` call in the same file after the `Class<RCTComponentViewProtocol>` function. This ends up resulting in a `RCTThirdPartyComponentsProvider.mm` file that looks like the image bellow
<img width="1052" alt="image" src="https://github.com/user-attachments/assets/26ce93be-0370-4852-a949-9da21762ff7f" />
You can reproduce this with the following
```
Class<RCTComponentViewProtocol> XYZCls(void)
{
return XYZ.class;
}
// this comment breaks codegen .class
```
## Changelog:
[IOS] [FIXED] - Fix codegen extracting `.class` from complex component classes
Pull Request resolved: https://github.com/facebook/react-native/pull/51813
Test Plan: Run codegen locally, use this patch in the expo/expo repo and CI should be green
Reviewed By: cipolleschi
Differential Revision: D75964424
Pulled By: cortinico
fbshipit-source-id: 50e45aa2ac6e43c75ee6fdd76791c591d81d4df7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51811
changelog: [internal]
after a bit of discussion it was clear the name of this method was confusing. Let's rename it to `produceFramesForDuration` to make it more obvious what happens under the hood.
Reviewed By: rubennorte
Differential Revision: D75953355
fbshipit-source-id: a62933894f9d42fbb3692134d117c05208c62699
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51800
Changelog: [internal]
This adds support for printing the cause of errors thrown in tests in Fantom, if available.
Reviewed By: lenaic
Differential Revision: D75946044
fbshipit-source-id: 579a2fc547cae92d2a65a4023ba1fb2e34a1f735
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51805
changelog: [internal]
this overload of transferRuntimeShadowNodeReference is only used within ShadowNode, let's make it private.
Reviewed By: lenaic
Differential Revision: D75903646
fbshipit-source-id: 1ea86b6d0771cdffaff2d425d591f1e58da330ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51803
The `flow strict` annotation was accidently removed in D74574293. This diff brings it back and fixes flow errors caused by this change. This makes generated TS types for `composeStyles` more relaxed but the main idea of inferring inputs base on output type annotation is preserved.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D75945388
fbshipit-source-id: c24ff8ad5d286e16bca3522e82f02e14f660c0dd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51802
changelog: [internal]
avoid conversions when dealing with time in C++ Animated. This makes tests more predictable.
Reviewed By: christophpurrer
Differential Revision: D75813200
fbshipit-source-id: b8934848237e5ea7c350d9a5f0175ac0f9202ffd
Summary:
Migrate com.facebook.react.bridge.NativeModuleRegistry to Kotlin.
In this diff, `JavaModuleWrapper` and some of its functions/properties had to be made public again as they are exposed by the migrated class – and if the functions are kept internal, there are crashes in legacy arch due to the C++ usages.
## Changelog:
[INTERNAL] - Migrate com.facebook.react.bridge.NativeModuleRegistry to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/51734
Test Plan:
```bash
yarn test-android
yarn android
```
Reviewed By: rshest
Differential Revision: D75938404
Pulled By: cortinico
fbshipit-source-id: 088286d4b100d1013cff43b81db39c6aec10f4e1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51653
Changelog: [Internal]
Adds a transform that ensures no types and interfaces named `Props` end up in the generated TypeScript definitions. Those are not descriptive and cause duplicate types in the rollup.
Reviewed By: huntie
Differential Revision: D75508800
fbshipit-source-id: 8d64ec19cbabe57495d6462df9d372ba42cda618
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51797
Changelog: [internal]
Fantom tests are generally very reliable, but a source of flakiness seems to be coming from `result.stderr` being `undefined` and throwing in this callsite. We just add a check to work around it, hoping it's just being set to `undefined` because there really are no errors.
Reviewed By: rshest
Differential Revision: D75942405
fbshipit-source-id: d8920cc2573f029de6bb108310c31f1992e74301
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51774
Changelog: [internal]
Just a small refactor to remove some unnecessary `using namespace` directives for code in the `facebook::react` namespace.
Reviewed By: javache
Differential Revision: D75874213
fbshipit-source-id: e63a91b412b2865eb05961d2174b14230ff35e88
Summary:
This is similar to https://github.com/facebook/react-native/issues/51590, but way better as it improves indirectly the flakiness for tests in the API tab. When the logbox is shown in debug mode, it interferes and sometimes makes that test fail, so this prevents that.
Android also takes more advantage of the improvement with this change, the previous PR only improved significantly iOS.
All the screens inside the RNTester seem to have a deeplink, which makes it easier to open the tests as the test cases are intended to check mostly specific behaviour of RN, and it is not necessary to have a middle step to find the specific components.
Maybe it would be good to run this a few times in CI to see if there are no side effects or flakiness added by opening deep links on CI builds.
## Changelog:
[INTERNAL] - Improve e2e times by using deep links to open examples
Pull Request resolved: https://github.com/facebook/react-native/pull/51786
Test Plan:
```sh
yarn e2e-test-android
yarn e2e-test-ios
```
iOS:
| Before | After |
|--------|-------|
| <img width="387" alt="image" src="https://github.com/user-attachments/assets/03ccd957-d401-4944-bb5c-d3e7db957b2e" /> | <img width="364" alt="image" src="https://github.com/user-attachments/assets/40a14c95-63f8-441d-b718-b5f57a506393" /> |
Android:
| Before | After |
|--------|-------|
| <img width="455" alt="image" src="https://github.com/user-attachments/assets/c71da8d0-df69-44af-b1b2-580995ce55c7" /> | <img width="449" alt="image" src="https://github.com/user-attachments/assets/7357e670-3510-4bbe-8543-68d3bd8c4bea" /> |
Reviewed By: cipolleschi
Differential Revision: D75938844
Pulled By: cortinico
fbshipit-source-id: c7d4063af561e7b0e583eddefcbb289786f3805a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51776
changelog: [internal]
testing animation must be predictable.
When animation takes 1 second and test calls `unstable_advanceAnimationsByTime(1000)`, the expectation is that the animation would have completed.
Previously it was necessary to wait for at least 38ms over the time it took to complete animation. This diff reduces the delta to 22ms.
Reviewed By: andrewdacenko
Differential Revision: D75813087
fbshipit-source-id: 1a27e5c227a0f3f1183ebdf41dc8c18149d68be0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51757
These both have a boolean flag `hasBeenMeasured_` which is never set to true, so the cached measurement is never used, but it would be wrong if it was used, since the cache doesn't respect the content, or measure constraints. Delete the broken code.
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D75817999
fbshipit-source-id: eb062f523840bbac7099b28f7e9b25cf9ad302aa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51773
Changelog: [internal]
(This isn't a public API yet so not marking it as a bugfix).
This fixes a crash in the `offsetParent` DOM API when called on a node whose parent is the `documentElement`.
Reviewed By: andrewdacenko
Differential Revision: D75876349
fbshipit-source-id: d90fcc3cb98f592c396cb0f5ee6ec80c9570745a
Summary:
This PR makes sure React Native still builds with USE_HERMES=0.
## Changelog:
[IOS] [FIXED] - make RNTester build with USE_HERMES=0
Pull Request resolved: https://github.com/facebook/react-native/pull/51772
Test Plan: CI Green
Reviewed By: andrewdacenko
Differential Revision: D75876484
Pulled By: cipolleschi
fbshipit-source-id: 72f3a7d33c19063b52c4c3e577ad2c5eae049d90
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51771
This made build_android fail because the parameter name mismatched between class and one of the implementation.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D75869827
fbshipit-source-id: a40dd1fb914e0694f1958c8b19eb9672de683c75
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51748
Changelog: [Internal]
Implements the first RNDT shell-specific feature based on https://github.com/facebook/react-native-devtools-frontend/pull/168 - namely, the ability for RNDT to foreground itself when certain events occur. This is most noticeable when pausing on a breakpoint.
Reviewed By: huntie, vzaidman
Differential Revision: D75795689
fbshipit-source-id: a073bf8ea96ba70d835007f5af6069d49a693d81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51767
This is going to convert the last class inside `com.facebook.react.views.view` to Kotlin.
I still need to assess if this is going to be breaking or not for our users. Potentially some
breakages for Kotlin consumer could happen (see changes on ReactViewManager).
I'll follow-up with an investigation on that one.
Changelog:
[Android] [Changed] - Convert ReactViewGroup to Kotlin
Reviewed By: mdvacca
Differential Revision: D75797215
fbshipit-source-id: 5d58faa651d5959909a4b0237aad9c4209895083
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51752
changelog: [internal]
Introduce a way to test animations: `unstable_advanceAnimationsByTime`. An API that fakes passage of time and triggers UI ticks to simulate how animations are run on iOS and Android.
The API is marked as unstable because it might evolve as we write more tests for C++ Animated.
Reviewed By: mdvacca
Differential Revision: D75787082
fbshipit-source-id: 24e29732bbbf581871e7868289257ab60d891ddf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51751
changelog: [internal]
these asserts are not correct with C++ Animated or anything that overrides pull transaction. When pull transaction is overriden, the modified mounting instructions are not stored in shadow tree. Therefore, these asserts fail.
Reviewed By: rshest
Differential Revision: D75787083
fbshipit-source-id: ac08b96f6dea89a9f127b179a5d05e351b281c35
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51750
changelog: [internal]
inline call `onRender()` instead of calling it from `startRenderCallbackIfNeeded`. This has identical functionality but allows to use Fantom to test C++ Animated. In Fantom, there is only one thread the existing mechanism in C++ Animated uses thread locals to capture which thread in the UI thread. Therefore, some assumptions are broken. This is just an easy workaround around the problem.
Reviewed By: javache, zeyap
Differential Revision: D75787084
fbshipit-source-id: 8d70ef2d13e4ab14807deb7ca4cb0844980f5901
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51749
changelog: [internal]
Make it possible to inject time via `now` argument to C++ Animated. This will be used in testing.
Reviewed By: javache
Differential Revision: D75710463
fbshipit-source-id: 2d6da875c7379c4b229f8b7af0fa665cebc2ca8b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51726
Previously we were spreading the searchPath on the FBLazyVectorPath everywhere, but that's not needed.
This change ensure that only the targets that nedds visibility over the FBLazyVectorPath depends on them.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D75756304
fbshipit-source-id: 41abe073bf271fd5059f9cb8536cc4a8948a03dd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51727
Previously we were spreading the searchPath on the ReactFBReactNativeSpecPath everywhere, but that's not needed.
This change ensure that only the targets that nedds visibility over the ReactFBReactNativeSpecPath depends on them.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D75756302
fbshipit-source-id: 41680b98dd07ea1abb09cebb1a1b8321f08929a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51728
Previously we were spreading the searchPath on the CallInvoker everywhere, but that's not needed.
This change ensure that only the targets that nedds visibility over the CallInvoker depends on them.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D75756303
fbshipit-source-id: d6fe70e43f65d8e9da5f1d18dc58491217575734
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51729
Previously we were spreading the searchPAth on the Runtime Executor everywhere, but that's not needed.
This change ensure that only the targets that nedds visibility over the runtimeExecutor depends on them.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D75756305
fbshipit-source-id: e54f1939d72049e7f4e8d3d14f7a33eacd5ac46f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51730
This change cleans up the header search paths that are now mostly computed starting from other informations of the target.
There are still some execptions, for example for header only target for which we can't have a SwiftPM target. Therefore targets that depends on header only targets need to specify them in their search path.
Plus there are a small number of other exceptions, such as some circular dependencies on header only files.
We will fix them later on, by introducing separated targets
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D75756307
fbshipit-source-id: 53f24dcb08947648c8fce5c520a949b3b896c2fa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51731
With this change, we are computing the headerSearchPaths starting from the path, and the source's path. In this way we can greatly reduce the amount of searchPaths we have to manually specify, making it much easier to maintain the SwiftPM package in the long run.
## Changelog:
[Internal] -
## Facebook:
The next diff in the stack proceeds with the cleanup.
Reviewed By: cortinico
Differential Revision: D75756306
fbshipit-source-id: 411ba6b598e568648488921c3ee62b8111f76749
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51691
In cocoapods infrastructure, Scrollview is part of ReactFabric.
In the SwiftPM implementation we erroneously moved that to reactFabricComponents. However, the new view culling features in reactFabric imports scrollview and that was broken in Swift PM.
This change fixes it.
## Changelog:
[Internal] - move scrollview to reactFabric
Reviewed By: lenaic
Differential Revision: D75638510
fbshipit-source-id: 00828956093aaa87e15c22d15ca3a647876182f5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51760
This API is evil.
Yoga's public API never allows a dirty node to become clean again, until its laid out, but this API requires doing that, since we will otherwise automatically dirty by default.
Let's replace it with `YogaLayoutableShadowNode::shouldNewRevisionDirtyMeasurement()`, which lets individual ShadowNodes represent whether a new revision's state and props should cause dirtying, defaulting to true.
Changelog:
[General][Removed] - Remove `YogaLayoutableShadowNode::cleanLayout()`
Reviewed By: lenaic
Differential Revision: D75479902
fbshipit-source-id: a40aa531522a76dc49feb7d12bae5a8d877c6c06
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51719
When `Animated` traverses props for instances of `AnimatedNode`, it flattens `props.style` before traversing it so that we correctly ignore any `AnimatedNode` instances that may be shadowed by static values:
```
{
style: [
{transform: [{translateX: new Animated.Value(0)}]},
{transform: [{translateX: 100}]},
],
}
```
However, there is a bug that occurs when *every* `AnimatedNode` instance is shadowed. In this case, `AnimatedProps` assumes that there are *no* `AnimatedNode` instances in the entire `props.style`.
It then incorrectly operates on the unflattened `props.style`, which *does* have `AnimatedNode` instances. When this is passed to `View`, the `AnimatedNode` instances are encountered and can cause a crash in `processTransform`, as reported by: https://github.com/facebook/react-native/issues/51395
The fix for this was originally attempted by riteshshukla04 in https://github.com/facebook/react-native/pull/51442. This diff reuses the same unit test case, but it applies a different fix that does not involve re-traversing the `props.style` object.
The fix is gated behind a feature flag, `alwaysFlattenAnimatedStyles`. This will enable us to validate correctness of the new behavior before enabling it for everyone. (Beyond fixing the bug described above, this also causes styles to flatten more aggressively, so production testing is important to ensure stability.)
Changelog:
[General][Changed] - Creates a feature flag that changes Animated to no longer produce invalid `props.style` if every `AnimatedNode` instance is shadowed via style flattening.
Reviewed By: javache
Differential Revision: D75723284
fbshipit-source-id: 504f63e8edf836243d615783e119137a920ad271
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51718
## what
the current removing listeners code is not working. in prod, when removeScrollListener is called, it creates a new weakReference of the scroll listener and it would never match any existing weakreference listeners in the list. The remove action would end up removing nothing from the list.
This diff fixes the issue by iterating through the list and compare the obj
reference: https://stackoverflow.com/questions/6296051/how-to-remove-a-weakreference-from-a-list
Changelog: [Internal]
Reviewed By: Abbondanzo
Differential Revision: D75716993
fbshipit-source-id: af9eed218deb44e87317c19ffca7d227b96de8e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51716
Adds a feature flag to experiment with different `prerenderRatio` values from the `VirtualView` native component. Notably, this is the first time that the a feature flag has a non-boolean type.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D75713594
fbshipit-source-id: ff3feb8d8bb3292fea6e04a4cfccd87e8249144e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51713
Changes the React Native Feature Flags system so that numeric feature flags are represented in native languages as double instead of int, in order to avoid loss of precision for non-integral JavaScript numbers.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D75709111
fbshipit-source-id: d4b2d553ce1e719a5f4b136a4f8d2e46446ef8d8
Summary:
Following up the announcement made at AppJS, this change stops testing the legacy architecture in our CI
## Changelog:
[Internal] - Stop testing the legacy architecture in CI
Pull Request resolved: https://github.com/facebook/react-native/pull/51738
Test Plan: waiting for GHA
Reviewed By: cortinico
Differential Revision: D75791359
Pulled By: cipolleschi
fbshipit-source-id: cb3159338835f49589fa6f495cfb9f47750825fe
Summary:
I'm writing some tests for some APIs/components, and I see some opportunity for improvement in the way how we can write e2e cases for the RNTester.
This diff improves two things:
1. e2e execution times: right now as we are using the `scrollUntilVisible` functionality, it takes quite some time *for some cases*, as some of the items are not very up in the lists and getting to them it's not always very fast.
2. Flakiness: I ran the tests multiple times locally, and in multiple occasions, the `scrollUntilVisible ` did not find anything as the scroll was too fast so the test ended up failing.
Instead of using `scrollUntilVisible` for all cases, we can simply use the search bar which we have in both Components and APIs tabs. This runs faster and we can also share the search flow across multiple test cases, so writing the tests becomes a bit simpler as well.
Initially, I did this for all cases but not all cases benefit from this change as some of them are easier to find than others – the improvement was most notable in iOS (keyboard visibility seems to make a big difference), but I still think it is a good baseline to use the search as if more test cases are added, likely, many of them are not going to be so easy to find.
## Changelog:
[INTERNAL] - Improve e2e times and flakiness by using the search
Pull Request resolved: https://github.com/facebook/react-native/pull/51590
Test Plan:
These are the differences in the time it takes to pass the tests locally.
iOS:
| Before | After |
|--------|-------|
| <img width="336" alt="image" src="https://github.com/user-attachments/assets/6bc80de6-5a10-4c0c-b6b0-f7850d746781" /> | <img width="329" alt="image" src="https://github.com/user-attachments/assets/de47a7ff-84cf-4916-abce-9b3df96a03e1" /> |
<details>
<summary>Android (no significant difference):</summary>
| Before | After |
|--------|-------|
| <img width="328" alt="image" src="https://github.com/user-attachments/assets/73023669-af8e-410c-aee2-529d1cce7acf" /> | <img width="336" alt="image" src="https://github.com/user-attachments/assets/3fb868a9-36f5-43c3-9261-6f2753e28e5f" /> |
</details>
Reviewed By: cortinico
Differential Revision: D75389138
Pulled By: cipolleschi
fbshipit-source-id: cf9d11ab0f84c91eaa20ee5c4441766729925571
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51746
I observed that when continue-on-error is set to true, Github reports the outcome of a job as success even if it fails.
With this change, we should ensure that when an E2E test fails, the pipeline fails, so that we can retry the jobs properly.
## Changelog:
[Internal] - Remove continue-on-error from e2e tests in GHA
Reviewed By: cortinico
Differential Revision: D75796284
fbshipit-source-id: 0e769f53d7355ae6c985aace334b23205780673a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51745
Changelog: [Internal]
1. Updates debugger-frontend's sync-and-build script to include a simple Markdown changelog inline and -mention authors who are Meta employees.
2. Also adds a `--no-build` flag that is mainly helpful for iterating on changelog generation logic.
Reviewed By: hoxyq
Differential Revision: D75789680
fbshipit-source-id: b30b49a9c50e93e7161a2dad012b92ef124a3a16
Summary:
- This is similar to https://github.com/facebook/react-native/pull/43566, but include also updated `StackFrame` type.
The current `Devtools.d.ts` doesn't match the `parseErrorStack.js` and `symbolicateStackTrace.js` implementations.
I've tried to run `build-types`, but only `symbolicateStackTrace.d.ts` was generated. I've not checked why.
## 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
-->
[GENERAL] [FIXED] - Devtools TS Types
Pull Request resolved: https://github.com/facebook/react-native/pull/51737
Test Plan: Call `parseErrorStack` and `symbolicateStackTrace` in TS.
Reviewed By: rshest
Differential Revision: D75782013
Pulled By: huntie
fbshipit-source-id: 91fe560f079731af2a5834c8de8eafb723d00bf9
Summary:
## Changelog:
[General] [Changed] - Remove native animation fabric sync in JS and infinite animation loop workaround, when cxxNativeAnimated is enabled
when cxxNativeAnimated is enabled, we'll sync native animation props back to Fabric in native, when that happens we can remove the code in JS for same purpose
Reviewed By: sammy-SC
Differential Revision: D75789100
fbshipit-source-id: 966e2b187f43e8743ccbf7ba97b8e8a27273fe0c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51743
Noticed some of these were missing, which may lose us useful test signal, or prevent tests from being ran at all.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D75789456
fbshipit-source-id: 75645866c672c77d3dac34383105955ef6d25e60
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50317
`rncore`, `FBReactNativeSpec` and `FBReactNativeComponentSpec` contain the same symbols, which leads to conflicts when we try to merge them into a single shared library. Cleanup the duplication and standardize on `FBReactNativeSpec` everywhere. I've left the Android OSS targets names as is, to avoid breaking deps.
This aligns react-native's package.json with the codegen tooling supported across iOS and Android, which is a single target for all all type-derived codegen.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D55037569
fbshipit-source-id: dbf3c0a427c9d0df96e439b04e5b123cd1069c51
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51708
Changes `yarn featureflags` to default to `--update` when no options are supplied.
Provides a way to display the available options with a new `--help` option.
Changelog:
[Internal]
Reviewed By: sammy-SC
Differential Revision: D75692119
fbshipit-source-id: 50d25c5f12c7646159872661c93ebe8c42f44788
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51707
Currently, the feature flag system does not properly support non-boolean feature flags. The type definitions and generated code make assumptions about the value type being `boolean`.
This diff fixes these assumptions so that non-boolean feature flags are supported.
Changelog:
[Internal]
Reviewed By: sammy-SC
Differential Revision: D75690997
fbshipit-source-id: 870063ff979d0650ce6d0a2f6b340d97c28d7d0b
Summary:
After testing the latest RC and nighly builds, crash appeared when emitting events from turbo modules on 32bit Android devices. The crash is always reproducible only on 32bit devices on signed production builds. Fore more details and the crash log, check the [related issue](https://github.com/facebook/react-native/issues/51628#issue-3094045077).
From what I found, the variadic functions like CallVoidMethod are unsafe on 32bit due to not type checking the passed arguments at compile time. As far as I understand the 64bit cpus and ABIs are more forgiving with alignment and calling conventions. On 32bit the ABIs are strict as arguments are passed on the stack and if there is type/size/alignment issue it reads the wrong memory, which causes the SIGEGV crashes.
## Changelog:
[ANDROID] [FIXED] - emitting event from turbo module crashes on 32bit android
Pull Request resolved: https://github.com/facebook/react-native/pull/51695
Test Plan:
1. Pull the [reproduction demo](https://github.com/vladimirivanoviliev/rn079eventcrash), install the dependencies (v `0.80` is on PR)
2. Run codegen on android
3. Build signed apk. To create it you will need to create new demo key-store.
4. To install the build apk in 32bit mode you can use `adb -s YOURDEVICE install --abi armeabi-v7a android/app/release/app-release.apk`
5. Run the app, create key, save it. Than update the key and save it again. The app crashes when try to emit event from the turbo module.
6. Patch the related `JavaTurboModule.cpp` file with the changes from this PR and enable build from source.
7. Rebuild and reinstall the apk and test again - the issue is now fixed
## Additional notes:
I have tested the app on android using the `rn-tester` demo app, everything works as expected. I also patched our production app and tested more complex scenarios and they works as expected. I have run the tests and linter and they passed.
One thing that I didn't able to setup and run is the iOS `rn-tester` app, due to Hermes engine error `Command PhaseScriptExecution failed with a nonzero exit code`. I haven't found any information how to fix it. I have followed [this guide](https://github.com/facebook/react-native/blob/main/packages/rn-tester/README.md) and installed node modules using yarn and started the `yarn prepare-ios`. I also haven't found any information with what node version and ruby version the react native package is build on CI so I use the same versions locally. If you provide me with updated instructions for those I can contribute by updating the related guides and including `.npmrc`, `.ruby-version` files.
Reviewed By: cortinico
Differential Revision: D75782377
Pulled By: javache
fbshipit-source-id: b94998be6dd51e90ad4137b1d2e38a6850bc3cb2
Summary:
Fixes https://github.com/facebook/react-native/issues/51548
## 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
-->
[General][ADDED] Added more Pending Decleration for ScrollView
Pull Request resolved: https://github.com/facebook/react-native/pull/51613
Test Plan: Can be tested on RNTester with ScrollView
Reviewed By: cortinico
Differential Revision: D75516801
Pulled By: rshest
fbshipit-source-id: 87d6f68ab0a3ffd50af57b5eeaf313da4bf7ed98
Summary:
The retry mechanism introduced in [this commit]() works for iOS e2e failures but it is skipped if android e2e tests fails.
This change should fix that
## Changelog:
[Internal] - Fix retry for Android E2E tests
Pull Request resolved: https://github.com/facebook/react-native/pull/51684
Test Plan: GHA
Reviewed By: rshest
Differential Revision: D75719890
Pulled By: cipolleschi
fbshipit-source-id: 0c2a22268bb655617eaf27f61227a46650878b4e
Summary:
D75596329 disabled many, many rules that we previously explicitly enabled over the codebase, due to a specific rule causing crash in linter when specifically linting some files like RCTDeviceInfo.mm.
Let's revert the change, and remove the specific problematic rule from our list of manually enabled rules instead.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D75734557
fbshipit-source-id: 9d6ee401bfa5d1efc8de993d366839c740aa0bdc
Summary:
The Image component in Android now supports the same cache control behaviour as in iOS, the examples needed to be separated in the past because the support was not the same for iOS and Android, but now that it is, we can unify the example.
## Changelog:
[INTERNAL] - Unify RNTester Cache Policy Image example
Pull Request resolved: https://github.com/facebook/react-native/pull/51580
Test Plan:
<details>
<summary>RNTester Screenshots</summary>
| iOS | Android |
|--------|-------|
|  |  |
</details>
Reviewed By: yungsters
Differential Revision: D75538812
Pulled By: Abbondanzo
fbshipit-source-id: 7705c8f824cb18cebc39e84b6f48979035dc104c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51705
changelog: [internal]
use if/else instead of unordered_map to map types of nodes/drivers from string to a class. This is faster and improves binary size.
Reviewed By: javache
Differential Revision: D75676701
fbshipit-source-id: be9b8b646ebd9472382e6f692768b8fe9703d88f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51704
Changelog: [internal]
If you create a Fantom test that throws an error during its setup (not during the execution of specific tests), Fantom fails with an error saying there are no tests defined, which isn't useful.
This fixes the problem and shows where the error in the test setup happened exactly.
Reviewed By: javache
Differential Revision: D75689283
fbshipit-source-id: 54dd2382868dda0d284f46743ed94ba94aa3afdc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51702
We have no need for C++ bridging in this TurboModule, as the generated code matches the base codegen exactly.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D75681901
fbshipit-source-id: 4b6caafe0bcd08a06686e0a44112bdb99a64a1cf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51699
Re-expose **all `"./src/*"` paths via `package.json#exports`.
Follows D72228547 — as we'd attempted to be proactive with hiding `src/`, but are now reverting — essentially reducing this change as much as possible (read: most defensive/safer effect on OSS).
**Motivation**
Mitigates a warning emitted by Metro that may surface in new bare React Native template projects.
{F1978757796}
This is due to a 1P reference to `'react-native/src/private/featureflags/ReactNativeFeatureFlags` in `react-native/virtualized-lists`.
This is enough motivation to undo part of our change with introducing `"exports"` on `react-native` in 0.80.
**Especially**, to avoid confusion with other warnings we've intentionally introduced in 0.80 around subpath imports.
- The key difference is the above screenshot is from Metro and covers **any** import from any `node_modules` file — as opposed to just the immediate project.
Changelog:
[General][Changed] - Re-expose `src/*` subpaths when not using the Strict TypeScript API
The net breaking change for 0.80, once picked, is simply the presence of `"exports"` (only very edge case effects on expanding per-platform extensions, which we've mitigated). **All exported paths equivalent**.
Reviewed By: robhogan
Differential Revision: D75682566
fbshipit-source-id: f90c7298279c6be3a4eab70f2dfdc618ffcf1124
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51696
Changelog: [internal]
I realized that the Fantom module was being initialized before the execution of the test module itself (as part of the code generated by the runner), which could have problems if the test sets up the global environment that Fantom consumes. For example, if Fantom needs to use the `EventTarget` type from the global scope, it needs to wait until the initialization of the runtime so it can use it safely.
This refactors all the code calling into Fantom as part of our infra to always initialize it lazily, so the first thing that runs as part of the test execution is the test itself (apart from our test setup, which is supposed to be side-effect free).
Reviewed By: sammy-SC
Differential Revision: D75681181
fbshipit-source-id: 91e4b903a49fcee59c5875e73db314cde0adea03
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51697
changelog: [internal]
as a general rule of thumb, do not call outside of your class when holding a mutex. It is easy to cause a deadlock because the outside code may end up trying to acquire the mutex down the stack, leading to deadlock.
Here, it happens because `startRenderCallbackIfNeeded` may end up calling onRender and in onRender, we try to acquire the mutex again
Reviewed By: javache
Differential Revision: D75675465
fbshipit-source-id: 46168ee154a54ae5cccaa74728b41f027519db59
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51694
Changelog: [Internal]
D74820232 was missing an `exports` entry for `debugger-shell/package.json`, which is needed for some of our build tooling.
Reviewed By: hoxyq
Differential Revision: D75679347
fbshipit-source-id: 8deaf55ce354afcff410104948cad1b9a30093b7
Summary:
This React Native Android fix hardens the Fabric `InteropUiBlockListener` against `ConcurrentModificationException` crashes in `willMountItems` and `didMountItems`. By iterating over a shallow copy of the UI‐block lists and catching any mid‐iteration mutations, we ensure the listener never throws during a UI frame and always clears its pending blocks.
The issue was first reported in [React Native Issue https://github.com/facebook/react-native/issues/49783](https://github.com/facebook/react-native/issues/49783), and although [React Native PR#50091](https://github.com/facebook/react-native/pull/50091) was closed and not merged, the work in that PR did make it to React Native in [commit 17da3cb](https://github.com/facebook/react-native/commit/17da3cbbf4687f86226c4a80297c4d8abfc9c4f5). However, the fix didn't go far enough. We saw intermittent examples of this exception being thrown when swiping through a carousel from `react-native-reanimated-carousel`. This fix goes right to the exception site itself.
## Changelog:
[ANDROID] [FIXED] - Hardened the Fabric `InteropUiBlockListener` against `ConcurrentModificationException` crashes in `willMountItems` and `didMountItems`
Pull Request resolved: https://github.com/facebook/react-native/pull/51631
Test Plan:
The only way to test this is to develop a standalone app that emulates what we've been seeing in our commercially available RN app. We have done extensive testing of before (intermittent crashes) and after the fix (no crashes) and things have been standing up very well for us.
Here is a the Red Box we see right at the time of the crash, before this fix:
<img width="414" alt="image" src="https://github.com/user-attachments/assets/8d1b6c6d-42f7-48a0-9574-2f05436547d4" />
And here is the beginning of the logcat crash log:
```
2025-05-07 16:01:49.212 unknown:BridgelessReact com.aura.suite W ReactHost{0}.handleHostException(message = "null")
2025-05-07 16:01:49.212 unknown:ReactNative com.aura.suite E Exception in native call
java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:1111)
at java.util.ArrayList$Itr.next(ArrayList.java:1064)
at com.facebook.react.fabric.internal.interop.InteropUIBlockListener.willMountItems(InteropUiBlockListener.kt:72)
at com.facebook.react.fabric.FabricUIManager$MountItemDispatchListener.willMountItems(FabricUIManager.java:1235)
at com.facebook.react.fabric.mounting.MountItemDispatcher.dispatchMountItems(MountItemDispatcher.java:184)
at com.facebook.react.fabric.mounting.MountItemDispatcher.tryDispatchMountItems(MountItemDispatcher.java:122)
at com.facebook.react.fabric.FabricUIManager$3.runGuarded(FabricUIManager.java:820)
at com.facebook.react.bridge.GuardedRunnable.run(GuardedRunnable.java:29)
at com.facebook.react.fabric.FabricUIManager.scheduleMountItem(FabricUIManager.java:824)
at com.facebook.react.fabric.FabricUIManagerBinding.reportMount(Native Method)
at com.facebook.react.fabric.FabricUIManager$MountItemDispatchListener$1.run(FabricUIManager.java:1282)
at android.os.Handler.handleCallback(Handler.java:959)
at android.os.Handler.dispatchMessage(Handler.java:100)
at android.os.Looper.loopOnce(Looper.java:232)
at android.os.Looper.loop(Looper.java:317)
at android.app.ActivityThread.main(ActivityThread.java:8592)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:580)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:878)
```
All of this goes away with this fix. We're using React Native 0.79.2 and this is the first time we've open a PR for react-native. I hope this is enough info as far as testing goes.
Can we see a 0.79.x release with this fix, please?
Reviewed By: Abbondanzo, cortinico
Differential Revision: D75594791
Pulled By: javache
fbshipit-source-id: 982ae27e89756fdb290a24b0bdfa67c2e47c04e3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51688
Changelog: [Internal]
# Context
See D74904547.
## This diff
Creates the `react-native/debugger-shell` package, containing a basic implementation of an Electron-based shell for React Native DevTools. At this point, there is no direct dependency on the new package from the rest of React Native - it's designed to be used as part of a Meta-internal experimental rollout of the new debugger shell via the `BrowserLauncher` interface in `dev-middleware`.
Reviewed By: huntie
Differential Revision: D74820232
fbshipit-source-id: cb06ea9e2ed8c8822019cad8296cc19e69f9db0b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51687
Changelog: [Internal]
# Context
This is the first of several commits that aim to implement a **standalone shell for React Native DevTools**. This will be a lightweight desktop app designed to host the debugger frontend, in much the same way as we currently use Chrome or Edge. The launch flow will otherwise remain **very similar** to the one that exists today.
## What's changing for users?
1. With this commit, nothing; we're merely setting up an experiment flag (for stage 1 - Meta-internal testing) and will make separate plans for open source rollout, coordinated with our framework maintainer partners.
2. If the experiment is successful, we aim to *eventually* phase out the use of Chrome/Edge in React Native DevTools and ship the standalone shell as standard to all React Native developers. This is to enable further improvements that will rely on the standalone shell to work.
3. The first iteration of the standalone shell aims to solve some concrete pain points such as the "dead window problem" - the fact that opening DevTools multiple times for the same target will leave behind a now-dead window (that would ideally have been reused).
## This diff
We amend the `unstable_experiments` and `unstable_browserLauncher` APIs in `dev-middleware` to add basic support for launching a standalone shell based on a frontend URL and a *window key* - the latter being an opaque string that the shell process can match against previous launches in order to reuse and foreground existing windows.
We leave it up to `BrowserLauncher` implementers ( = frameworks) to provide a working implementation of `unstable_showFuseboxShell`, and do not provide one with `DefaultBrowserLauncher`. This will effectively allow us to dependency-inject the actual shell implementation at stage 1 so we don't increase the download size of React Native unnecessarily.
Reviewed By: rickhanlonii, robhogan
Differential Revision: D74904547
fbshipit-source-id: fbc6eac97923062bda8892bc130b39051845ea82
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51679
## Problem
I noticed that clang-tidy was crashing in some of our native modules.
This diff fixes the crash. And it blocklists all the warnings that got raised when I ran clang tidy for react native.
## Fix
This rule would crash clang tidy:
```
cppcoreguidelines-avoid-const-or-ref-data-members
```
I disabled it in the .clang-tidy file via:
```
-clang-analyzer-*,
```
## Why disable existing warnings?
We need to double check which checks make sense to enable for react native github. Until we have that understanding, I don't think we should prompt people to adjust their code. After we have that understanding, it should be really easy to enable the checks: just run the linter on react native, and fix the code.
Reviewed By: lunaleaps
Differential Revision: D75596329
fbshipit-source-id: 757a8d38f203d7fb4403bbda3703fda7b44923b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51676
Changelog: [internal]
This replaces all existing usages of `shadowNodeFromValue` (previously defined in `primitives.h`) to use the new bridging method to automatically convert `ShadowNode::Shared` from and to JS.
It also deletes the old method.
Reviewed By: javache
Differential Revision: D75597543
fbshipit-source-id: ab4e307dad80c7507b7ebd1cfa6621d020473d89
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51675
Changelog: [internal]
This defines a new bridging method to convert ShadowNode::Shared from and to JS. This has some benefits over the existing `shadowNodeFromValue` and `valueFromShadowNode` functions:
1. It's more convenient, as we can just use `ShadowNode::Shared` in classes implementing the codegen, and the runtime will do the conversion automatically.
2. It's safer, as it checks for nullability and throws JS exceptions except of having segmentation faults down the line.
Reviewed By: javache
Differential Revision: D75597542
fbshipit-source-id: 37c0c43cbde0f4de9a740d9da910f215ae50efbd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51660
We should be able to clean this up as we're not using it directly.
It would be used via the NDK logging utilities from Android, that we don't use.
Changelog:
[Internal] [Changed] -
Reviewed By: mdvacca
Differential Revision: D75531640
fbshipit-source-id: e96932b6e77b159683728194ac2e856cb868e06f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51671
Adds `flow` (or `noflow`) to all files in this directory and ensures that Flow succeeds (by adding type annotations, using minor refactors, or suppressing errors due to intentionally dynamic logic).
This will help improve type safety when making changes both in these files as well as files that these depend on.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D75581879
fbshipit-source-id: 6dcd8cc55d0021973eeae2670c1ebceb6d69fa8f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51669
Refactors the default mocks initialized in `packages/react-native/jest/setup.js` so that each mock is defined in its own file.
This provides several benefits, including:
- The ability to use `import` statements without worrying about eager initialization of dependencies before `globals` is setup.
- The ability to verify mocks export the same types as the actual module, using a new Flow-typed `mock` helper function.
- The ergonomic of implementing mocks with more complex logic, without having to split them out into a separate module (e.g. `mockModal`, `mockScrollView`).
As part of this migration, I also fixed any minor discrepancies to match the actual type definition. For more involved discrepancies (e.g. missing methods), I added type suppressions for now to minimize breaking changes.
Changelog:
[General][Changed] - Improved default mocking for Jest unit tests.
Reviewed By: javache
Differential Revision: D75575421
fbshipit-source-id: 98d60e10b753f1505ffdccf5f12f5d3ef306ebb5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51674
changelog: [internal]
just a clean up of code in AnimationDriverUtils and removal of unused headers.
Reviewed By: mdvacca
Differential Revision: D75549612
fbshipit-source-id: a8ad63622478d06318b6304b886554478b43d19b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51673
Fixes a lint warning that seems to inconsistently fire, by improving the code that it complains about.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D75583443
fbshipit-source-id: b6df191e2e51dee688df3f3c960704dea28a4ece
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51634
Creates an example in the ViewExample setup for how onBlur/onFocus behave when using keyboard navigation
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D75238317
fbshipit-source-id: e69122ca17727fc7f71e9bb7a09098a2771b098e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51570
As the title suggests: adds support strictly to `View` components on Android for `onFocus` and `onBlur` events. This is especially helpful for apps that respond to controller or remote inputs and aligns with existing support for the `focusable` prop.
In order to make this change cross-compatible with text inputs, `TextInputFocusEvent` has been deprecated in favor of the `BlurEvent`/`FocusEvent` types now available from core. Their type signatures are identical but `BlurEvent`/`FocusEvent` should be the type going forward for all views that intend to support focus/blur. Text inputs intentionally do not forward information about their state upon focus/blur and docs specifically call out `onEndEditing` as a means of reading state synchronously when blurring. Therefore, the changes to the native side to remove the event type specifically for text inputs is not breaking.
Changelog: [Android][Added] - Support for `onFocus` and `onBlur` function calls in `View` components
Reviewed By: mdvacca
Differential Revision: D75238291
fbshipit-source-id: b991d1f24fc094ba9d5d466201ecd058f59258e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51666
The platforms handle this in pretty different ways right now. Let's add a test showing the differences.
Android also adds a bunch of unicode zero width spaces in there...
Changelog: [Internal]
Reviewed By: mlord93
Differential Revision: D75567210
fbshipit-source-id: 98cac7d3fd23451868b55b69478e2667a2de3716
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51654
Facsimile may or may not use a global measure cache. Adding flags to let us run experiment, to understand real-world performance impact, now that we have fixed some (but not all) of the issues which may lead to measurement invalidation in Fabric.
Also does some quick cleanup th `SimpleThreadSafeCache` to remove the cache key as part of the lambda, which is never used, and makes this change mildly less efficient, and to accept lambda by generic type instead of repacking into std::function which has runtime overhead.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D75509799
fbshipit-source-id: 165c08d626ab1f2758f0203d3a0d527a1a5106a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51627
This cdhanges are inspired by https://stackoverflow.com/a/78314483 and they should help with the stability of E2E tests on main.
Most of the time, those tests fails because of flakyness in the E2E infrastructure on GHA. Usually, rerunning the tests manually makes the workflow pass.
These couple of jobs automatically reruns the workflow up to 3 times in case one of the E2E tests fails
## Changelog:
[Internal] - improve CI by rerunning the workflow if the E2E tests fails
Reviewed By: cortinico
Differential Revision: D75449445
fbshipit-source-id: d9c235c76007a3bda048ec76b62710ca930cf252
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51662
## Changes
DeviceInfo: Deafult fontScale to 1 when accessibility manager isn't available
# Analysis
**The problem:** For reasons that we don't understand, accessibility manager is sometimes nil, when deviceinfo needs it. This is a long-standing issue in react native.
```
_constants = @{
@"Dimensions" : [self _exportedDimensions],
// Note:
// This prop is deprecated and will be removed in a future release.
// Please use this only for a quick and temporary solution.
// Use <SafeAreaView> instead.
@"isIPhoneX_deprecated" : @(RCTIsIPhoneNotched()),
};
```
```
- (NSDictionary *)_exportedDimensions
{
RCTAssert(!_invalidated, @"Failed to get exported dimensions: RCTDeviceInfo has been invalidated");
RCTAssert(_moduleRegistry, @"Failed to get exported dimensions: RCTModuleRegistry is nil");
RCTAccessibilityManager *accessibilityManager =
(RCTAccessibilityManager *)[_moduleRegistry moduleForName:"AccessibilityManager"];
if (!accessibilityManager) {
return nil;
}
CGFloat fontScale = accessibilityManager ? accessibilityManager.multiplier : 1.0;
return RCTExportedDimensions(fontScale);
}
```
**The crash:** When accessibility manager is nil, device info tries to insert nil into an NSDictionary, and crashes.
We found a possible repro of this issue: [launch facebook, log out, and log back in](https://www.internalfb.com/diff/D72020801?transaction_fbid=982516293994114).
**Why this surged now:** Recently, we started initializing device info during react native init. That means this code-path just runs much more often.
# Mitigation
Remove the return nil in `[self _exportedDimensions]`. Instead, just default the fontScale to 1 when the accessibility manager isn't available.
**This should be safe:** If we assume that accessibility manager eventually becomes available, the fontScale will eventually become correct. Device info will send the updated fontScale to js when it becomes available: [native](https://www.internalfb.com/code/fbsource/[ec6fd664a9cd]/xplat/js/react-native-github/packages/react-native/React/CoreModules/RCTDeviceInfo.mm?lines=231-232), [js](https://www.internalfb.com/code/fbsource/[ec6fd664a9cd]/xplat/js/react-native-github/packages/react-native/Libraries/Utilities/Dimensions.js?lines=120-125).
# Long-term fix
Understand why accessibility manager is nil.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D75537894
fbshipit-source-id: 921cc573fdfd7e5c340ac3a4ada268caadb9e382
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51549
This is copied from `ReactTextView`, with a comment explaining the shenanigans.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D75248328
fbshipit-source-id: b325cf05e0000ee0b0c5fb82f0e7412a680e5d01
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51575
Before we were relying on absolute focus direction to determine the next focusable view inspired by Recycler View's implementation. This turned out to be inaccurate since FocusForward and FocusBackward do the ordering differently.
For FocusForward and FocusBackwards the children of the root node are ordered first from top to bottom then, row groups are created by getting views with the same vertical position and then everything else is sorted left to right.
Android creates an array with this order and then just focuses the next or previous element of this list. We don't do this but now FocusForward and FocusBackward follow the some comparisons used to build this array on Android.
Also, there was an issue with nested children within an accessible view, this just needed a bit of refactor on the focusSearch function so that we can tell when we actually need to trigger our custom focus search
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D75301251
fbshipit-source-id: 93b708092299afa778ba5938b093c2c38209b497
Summary:
Adds `flow` (or `noflow`) to all files in this directory and ensures that Flow succeeds (by adding type annotations, using minor refactors, or suppressing errors due to intentionally dynamic logic).
This will help improve type safety when making changes both in these files as well as files that these depend on.
Changelog:
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/51652
Test Plan:
Ran Flow and Jest tests successfully:
```
$ yarn flow
$ yarn test
```
Ran a Jest unit test internally to make sure they work with our internal environment setup:
```
$ cd ~/fbsource
$ js1 test /View-test.js
```
Reviewed By: javache
Differential Revision: D75488160
Pulled By: yungsters
fbshipit-source-id: 536cef9699acfa1edcd3dcf61c53ebcd92f560f9
Summary:
This PR adds a new cloning method, allowing for updating multiple nodes in a single transaction. It works in two phases:
1. Find which nodes have to be cloned (i.e. nodes given on input and all their ancestors)
2. Clone nodes in the bottom up order - so that every node is cloned exactly once
So the idea is that when we want to update all the red nodes in this picture, we first find the nodes in the green area and the clone only them in the correct order (children are cloned before parents):

Adapting this method [brought a huge performance gain to reanimated](https://github.com/software-mansion/react-native-reanimated/pull/6214). I want to upstream it, so that:
1. we can optimize it further, because making it a part of the `ShadowNode` class gives us access to the parent field in `ShadowNodeFamily` so we can traverse the tree upwards, allowing for a optimal implementation of the first phase (in reanimated we repeatedly call `getAncestors`, which revisits some nodes multiple times)
2. the community can use it
A naive approach that calls `cloneTree` for every node is much slower, as it has to repeat many operations.
## Changelog:
[GENERAL] [ADDED] - Added `cloneMultiple` to `ShadowNode` class.
Pull Request resolved: https://github.com/facebook/react-native/pull/50624
Test Plan:
I tested it with the following reanimated implementation and everything works fine:
<details>
```c++
const auto callback =
[&](const ShadowNode &shadowNode,
const std::optional<ShadowNode::ListOfShared> &newChildren) {
return shadowNode.clone(
{mergeProps(shadowNode, propsMap, shadowNode.getFamily()),
newChildren
? std::make_shared<ShadowNode::ListOfShared>(*newChildren)
: ShadowNodeFragment::childrenPlaceholder(),
shadowNode.getState()});
};
return std::static_pointer_cast<RootShadowNode>(
oldRootNode.cloneMultiple(families, callback));
```
</details>
I would like to add tests for it, but I'm not sure what's the best approach for that in the repo.
Reviewed By: mdvacca
Differential Revision: D75284060
Pulled By: javache
fbshipit-source-id: 0704c4386c3041eb368adf6950d46de197479058
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51657
changelog: [internal]
Introduce a new ShadowNodeTraits: `Unstable_uncullableView` and `Unstable_uncullableTrace`. As the name suggests, this is not stable API yet.
When a shadow node sets this trait, it will be opted out of view culling together with its ancestors all the way to the root.
The trait is propagated to its parent in 4 different places:
1. When node is first created.
2. When node is cloned.
3. When child is appended.
4. When child is replaced.
we can safely do it only in those places because React constructs nodes from bottom up. We are leveraging this implementation detail here but if that changes in the future, a traversal will be required.
Alternative solution considered here was a traversal of shadow tree during commit phase to propagate `Unstable_uncullable` trait. This could be done in a separate traversal or as part of layout phase where layout information is copied out of Yoga tree. Leveraging the fact that React is cloning bottom up makes the implementation simpler.
If React changes its cloning approach in the future, this will be caught by tests.
Reviewed By: lenaic
Differential Revision: D75476847
fbshipit-source-id: f1e98804565c140c64945662af0247b1bd0e1882
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51656
This fixes an issue with the internal networking layer when `enableModuleArgumentNSNullConversionIOS` is enabled, as we'd try to pass `NSNull` as trackingName instead of omitting it.
`
Changelog: [Internal]
Reviewed By: fabriziocucci
Differential Revision: D75516619
fbshipit-source-id: 91a3bba32772fdd66edde1e24b7edd977918f727
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51639
changelog: [internal]
### Fix Crash in View Culling
This diff fixes a crash that occurs when a view is unflattened or flattened in a deep hierarchy where each node has a top offset.
The problem is that nodes passed to *calculateShadowViewMutationsFlattener* via argument *unvisitedOtherNodes* have their positions calculated in a different coordinate space and the view culling algorithm does not have the correct data to determine visibility of a node. To fix this, we pass another argument to *calculateShadowViewMutationsFlattener* which does have original view culling context with which these nodes had their position calculated.
Reviewed By: javache
Differential Revision: D75455704
fbshipit-source-id: 925f14dfdc6c2b669c89e100629291921f27cd1e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51622
We currently support an optional 3rd params for `target_compile_reactnative_options` which allows to specify a LOG_TAG macro.
No one is actually reading that Macro. The only usage would be logging from the Android SDK which we don't explicitely use.
Here I'm updating our build to specify a LOG_TAG as `ReactNative` for all the targets without allowing to customize it as it just complicates our build setup.
Changelog:
[Internal] [Changed] -
Reviewed By: mdvacca
Differential Revision: D75445577
fbshipit-source-id: a426ce77ba6d1dfd0800e874d9f7838bfdc5b877
Summary:
RuntimeExecutor.h has sync ui thread utils:
* executeSynchronouslyOnSameThread_CAN_DEADLOCK
The ios platform has js -> ui sync calls. This util, when it executes concurrently with those sync calls, deadlocks react native.
On ios, we're going to resolve these deadlocks, which'll involve customizing this util: D74769326. Therefore, this diff forks an implementation of these sync ui thread utils for ios.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D74901907
fbshipit-source-id: f502df4216e9ba57f458435c696a2f086becf24f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51633
To fully support props diffing for a component, the component's Props implementation needs to implement the prop diffing for the derived class.
Because all Props classes extend the ViewProps, all Props classes implement the `getDiffProps` function. To support testing that the props diffing implementation support all properties of the derived Props class for the component being mounted, this diff adds the virtual function `getDiffPropsImplementationTarget` which returns the `ComponentName` that the `getDiffProps` function supports.
This removes the need for a hard-coded list of components that support props diffing and enables the use of codegen to conditionally enable props diffing.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D75465020
fbshipit-source-id: 2850a76f1036cfe930c3c69b98d478ef86a2d457
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51650
This diff adds support to diff props with Point type
changelog: [internal] internal
Reviewed By: mlord93
Differential Revision: D75469451
fbshipit-source-id: a6844b691d8e32326d04c2bd51e6509980feb611
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51642
This diff asserts that ImageRequest won't be used as prop type
changelog: [internal] internal
Reviewed By: mlord93
Differential Revision: D75469453
fbshipit-source-id: e9e46bc8806e00c104b76825445fe72779106220
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51551
This allows hit RN's hit testing to find nested spans, and click them.
This mechanism is fully separate from the one used by a11y virtual views, and ClickableSpan, such as those added for links via dataDetectorType (and also the `link` role).
When we do have a link accessibilityRole, that ClickableSpan hit test seems to prevent the React one, and we only activate the onPress once (but then add keyboard interaction, press visual, and add to the a11y tree).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D75257326
fbshipit-source-id: 0c693f581ec121cf4b4e3e2040d141985118224f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51635
Enables a feature flag by default, that reduces the memory usage of`Animated`. For more details, see: https://github.com/facebook/react-native/pull/49184
Changelog:
[General][Changed] - Enabled a feature flag that optimizes `Animated` to reduce memory usage.
Reviewed By: jehartzog
Differential Revision: D75466724
fbshipit-source-id: 3fdb57f394448bbd0530dcb558a58958010d0edd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51514
This util can execute arbitrary runtimeWork, which can throw.
In the future, we'll also make these utils execute ui blocks posted from the javascript thread. And those will be able to throw.
Therefore, let's remove the noexcept. Otherwise, if an exception bubbles up to this util, it will just crash this app.
Changelog: [General][Changed] - RuntimeExecutor: Remove noexcept from sync ui thread utils
Reviewed By: javache
Differential Revision: D75183993
fbshipit-source-id: 6c3a319fe3a76165a265815e6343220cf9db6fde
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51429
If we use promises, I believe the code is just easier to understand.
Changelog: [Internal]
Reviewed By: javache, yungsters
Differential Revision: D74941734
fbshipit-source-id: a9bc5ac715c84a5a92f8f1c6635ebef9fe538377
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51626
This just migrates the `MapBuilder` file to Kotlin.
Users on Kotlin should still use the built-in collection extensions rather than using this class that will go away at some point in the future.
Changelog:
[Internal] [Changed] -
Reviewed By: fabriziocucci
Differential Revision: D75448739
fbshipit-source-id: 2bfa24ad9bd37bd571ea4551bd9a10e848841e0a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51629
Changelog: [internal]
The native module will never be defined in tests, so there's no point in logging this warning there.
Reviewed By: rshest
Differential Revision: D75451414
fbshipit-source-id: cdc1f674d01fcaf58c1c2342c994d95e6b3b6847
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51623
This fix relaxes some dependencies on React-hermes that should not be in the code.
## Changelog:
[Internal] - Remove dependencies from React-Hermes when they are not needed.
Reviewed By: cortinico
Differential Revision: D75447910
fbshipit-source-id: 6d7695f0e2b6c936b4c5ed9e70261f1d3b28a3d0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51625
This just migrates this class to Kotlin, which is also the last class in this package.
Changelog:
[Internal] [Changed] -
Reviewed By: rshest
Differential Revision: D75448161
fbshipit-source-id: d5457dd8017fd459d166d2945ff440c303943db2
Summary:
As I reviewed some examples, I noticed that this one's dark mode could be improved, and the code could be modernised a bit as well by converting its classes into functional components.
## Changelog:
[INTERNAL] - Fix InputAccessoryView example in dark mode and convert to functional components
Pull Request resolved: https://github.com/facebook/react-native/pull/51583
Test Plan:
<details>
<summary>Screenshots</summary>
| Dark | Light |
|--------|-------|
|  |  |
</details>
Reviewed By: fabriziocucci
Differential Revision: D75404561
Pulled By: cortinico
fbshipit-source-id: 3318e9869919e99055e47b59c89de0b22976f142
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51619
RNTester Android is currently instacrashing in OSS due to 3rd-party packages not having the `RN_SERIALIZABLE_STATE` definition.
That's because the `INTERFACE` definition is not properly propagated on the prefab boundaries.
This was happening for `react-native-popup-menu-android` and `react-native-test-library` and will also happen for Codegen libraries.
This fixes it. 3p developers with custom CMake files will also have to use the `target_compile_reactnative_options` functions to make sure the compilation flag are properly populated.
Changelog:
[Android] [Breaking] - Correctly propagate RN_SERIALIZABLE_STATE to 3rd party CMake targets. Users with custom CMake and C++ code should update to use `target_compile_reactnative_options` inside their CMakeLists.txt files. See the 0.81 release notes for more information.
Reviewed By: cipolleschi
Differential Revision: D75441245
fbshipit-source-id: 3855fdf11cbe7f4b01f68e0dde68b63b3240ad35
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51616
changelog: [internal]
doesn't seem to be used by anything. let's delete it.
Reviewed By: javache
Differential Revision: D75218695
fbshipit-source-id: eeb3a826f06456be8de6941fa95d6ffc7917dcf8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51615
changelog: [internal]
rename methods to reflect that they are getters and mark them as noexcept const
Reviewed By: rshest
Differential Revision: D75217535
fbshipit-source-id: c7d77060d0f54f8043a7552eec7e2b231cb5b7bf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51618
Changelog: [internal]
This sets the argument to `pullTransaction` to `true` in the cases where the call is done from the JS thread and the transactions are mounted asynchronously in the UI thread (basically platforms using the push model for mounting coordinator).
It was missing on an experiment for Android (compatibility mode for Props 2.0)
Reviewed By: lenaic
Differential Revision: D75439105
fbshipit-source-id: a106a3a674e44b0cf2603782302343f60ee5450e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51620
The spirit of "Decouple Hermes from JSI nd simplify dependencies" is good, but the problem is that when we ships prebuilds of hermes-engine, it tries to load `libjsi.dylib` and that library is not available.
{F1978594163}
I'll have to investigate more how to properly decouple Hermes prebuilds and how to pass jsi to Hermes and react-native. We might have to decouple it further and have a separate job that builds jsi and feed it to hermes.
This problem will go away with SwiftPM, though, so probably not worth solving this.
## Changelog:
[Internal] - Fix nightlies with a backout
Reviewed By: cortinico
Differential Revision: D75442056
fbshipit-source-id: f1085be8247c0974854254c6bd631ca258488beb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51614
`JSEventLoopWatchdog` is not used in react-native package. This diff moves it to rn-tester which previously deep imported it from react-native (which we want to avoid).
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D75410548
fbshipit-source-id: d4996742578e3b068e7acad9479394388b1907ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51603
In `rn-tester` TextAncestor was used to create a inlineView wrapper:
```js
function InlineView(props) {
return (
<TextAncestor.Provider value={false}>
<View {...props} />
</TextAncestor.Provider>
);
}
```
however, it is already done in View.js and TextAncestor shouldn't be used outside of react-native package:
```js
if (hasTextAncestor) {
return <TextAncestor value={false}>{actualView}</TextAncestor>;
}
return actualView;
```
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D75408231
fbshipit-source-id: 7f12278296dcfe56246f6b7065f5a094e4099f7a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51602
Changelog: [GENERAL][FIXED] - Fixed the generated type definitions for `Animated.FlatList` and `Animated.SectionList` to correctly infer item types.
Current definitions for animated list components cast away their generic definitions, preventing the types to be inferred from usage. This diff addresses that.
Reviewed By: huntie
Differential Revision: D75407762
fbshipit-source-id: c86f20298ded707971c05a78d025a63e82fe2a64
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51611
changelog: [internal]
AnimationDriver does not use enable_shared_from_this, let's remove it. Also mark a few methods as noexcept and const.
This helps with C++ binary size.
Reviewed By: rshest
Differential Revision: D75172851
fbshipit-source-id: d6552cd577371a51c3fa3b394b451d7ed2b61e44
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51610
changelog: [internal]
No need to store uiManagerBinding in a shared_ptr. Let's just get it, pass it to classes that need it and not store it.
This helps with C++ binary size a little bit.
Reviewed By: rshest
Differential Revision: D75174567
fbshipit-source-id: 1d4e5a9f89ba2f2d2eb733eac9d103ee97550d0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51609
changelog: [internal]
NativeAnimatedNodesManagerProvider is not subclassed. Let's remove virtual methods and make it a final class.
Reviewed By: lenaic
Differential Revision: D75169108
fbshipit-source-id: 32121cf372ba94c8a7b86c61fd96efd75560f789
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51517
The Props 2.0 implementation for ScrollView added two missing props which were Android specific.
This diff moves these to a separate HostPlatformScrollViewProps class so that other platforms wouldn't include them
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D75183132
fbshipit-source-id: 44d0e0aa974e69f8584ad6bd681fad100c3493d8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51605
changelog: [internal]
folly::dynamic can be constructed with nullptr and it creates a null folly::dynamic. Let's use that to indicate missing value instead of std::optional to lower C++ binary size.
Reviewed By: rshest
Differential Revision: D75174590
fbshipit-source-id: f2dfef00975686f6ac4c14b42539e700e967075b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51606
changelog: [internal]
When native module is destroyed, ui queue is also torn down.
this helps with C++ binary size a little bit
Reviewed By: rshest
Differential Revision: D75149437
fbshipit-source-id: 1df061db26b4fb5026114e00bbc6846bf38d83a9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51600
The `infoLog` is a `console.log` wrapper to separate ad-hoc console debug logging, however console logs are already used in some files in rn-tester (ex. RNTesterAppShared.js). The same applies to files in react-native package.
Changelog:
[General][Changed] - Removed `infoLog` from react-native package
Reviewed By: huntie
Differential Revision: D75402930
fbshipit-source-id: 1a14a9122552130415f058d3647d715225321ab8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51591
This change decouples Hermes from JSI and simplify the dependency graph.
Prior to this change, Hermes was building and providing JSI to React Native.
Hermes and React Native shares the same version of JSI, so that's was not a problem, but this choice added an unnecessary dependency on hermes-engine for some pods. For example, `React-utils` was depending on hermes, although it only needs JSI.
## Changelog:
[Internal] - Decouple hermes-engine from jsi
Reviewed By: cortinico
Differential Revision: D75374285
fbshipit-source-id: 3af6846032e81b6461420dd4f4a9c34b741f31ae
Summary:
Running `yarn prepare-ios` creates some build artifacts folders, which can be added to the .gitignore as they are generated.
## Changelog:
[INTERNAL] - Update iOS RNTester build artifacts in .gitignore
Pull Request resolved: https://github.com/facebook/react-native/pull/51579
Test Plan: N/A
Reviewed By: cortinico
Differential Revision: D75389176
Pulled By: cipolleschi
fbshipit-source-id: ecb59051f5bb25b6be8fca9ac2ebf408adc5c7b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51599
Adds `deprecated` to 2x API exports via `index.js.flow`. This will flag these APIs appropriately to the developer under TypeScript.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D75403796
fbshipit-source-id: 670c4bd0c262a58413e7703f09d6db2927d51408
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51261
Cleanup to use the new public type / API exports from `metro` landed in Metro 0.82.3, which is RN's minimum as of D74181990 / [PR](https://github.com/facebook/react-native/pull/51122), in preference to deep imports.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D74141939
fbshipit-source-id: 9405f88a85e248abe8a92be1dd5a5f1ea6ceeb87
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51124
Metro 0.82.3's `runBuild` API now supports retrieving assets and passing through `unstable_transformProfile`, and fine control of output paths via `bundleOut`/`sourcemapOut`, so we can use it directly in the implementation of `community-cli-plugin`'s `bundle` command with no loss of function or API change.
This simplifies the implementation by re-using Metro's, and removes use of Metro internal APIs.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D74151840
fbshipit-source-id: 3dcadaf8d38e7e77d21bacdf29e5d40467139d88
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51497
It removes `prepare-flow-api-translator` which is no longer needed as `flow-api-translator` version was bumped already and it blocks `build-types` script from running on CI (due to reference to `flow-api-translator` source). It also removes "Experimental" annotations.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D75138541
fbshipit-source-id: 897009c91adeeeaae21603dbf90020b52b61c5d5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51589
changelog: [internal]
With D75140890, there is a guarantee that `startOnRenderCallback_` won't be called after the owning class is destroyed.
There shouldn't be any events flowing through Fabric when the RN instance is torn down. Passing this to eventEmitterListener_ should be safe.
This helps with C++ binary size a little bit.
Reviewed By: rshest
Differential Revision: D75148616
fbshipit-source-id: 5110736c2ddcff738fce395bd0b9844d44e8dcb2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51588
changelog: [internal]
AnimatedNode never outlive NativeAnimatedNodesManager. We can safely use raw pointer here instead of shared_ptr.
This improves a C++ binary size a little bit.
Reviewed By: rshest
Differential Revision: D75148487
fbshipit-source-id: 4c2f6dc6e4de670be37dd3b65dc3a8d63d546150
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51587
changelog: [internal]
use unique_ptr instead of shared_ptr to manage memory of activeAnimations_.
Active animations are only owned by NativeAnimatedNodesManager and their ownership isn't shared with any other class.
This saves a little bit of C++ binary size.
Reviewed By: rshest
Differential Revision: D75142643
fbshipit-source-id: c09753b68e70e95fedcb7b2b8fb19a0fd7010059
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51586
changelog: [internal]
using shared_ptr here is not necessary because AnimatedNodes are not shared between multiple entities, they are only owned by NativeAnimatedNodesManager.
This saves a little bit C++ binary size.
Reviewed By: rshest
Differential Revision: D75148952
fbshipit-source-id: 18b8231061cda970ad96842ee6ca3135c2ec5d68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51566
changelog: [internal]
Expose [revision](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactCommon/react/renderer/core/ShadowNode.h#L229) of shadow node in Fantom tests. This makes it possible to write tests verifying that shadow nodes are only cloned when they should.
Even though excessive cloning does not usually lead to bugs, it may lead to performance problems.
Also introduce a test showing a performance problem where changing height of "Sibling" view from 1 to 2 will lead to component `D` being cloned by Yoga. Component D is not affected by the size change of Sibling and the clone is unnecessary.
```jsx
<ScrollView>
<View id="Sibling" style={{ height: 1 }} />
<View id="A">
<View id="B">
<View id="C">
<View id="D" ref={ref} />
</View>
</View>
</View>
</ScrollView>
```
Reviewed By: rshest
Differential Revision: D75287261
fbshipit-source-id: ea5acb2f5d7ba6e1e5bf895d8f82a16471122ec5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51576
This is causing some internal test failures for now, so disabling the behaviour to prevent further rollout.
Changelog: [iOS][Removed] Disable fix for #51103 until more testing can be done.
Differential Revision: D75320842
fbshipit-source-id: 39c115afd11e5b1aca6cdc1fc18ec7e83eb10382
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51508
For now, we are opting to not auto-focus `PreparedLayoutTextViews` if they have links. The reason being this would not work well with Text nested in a View which is also accessible. If that Text had links, and was set to focusable, then TalkBack would individually focus that Text, which users may not want.
So this diff removes that link detection, and fixes up accessibility in general. Since this isn't a TextView, we need to explicitly set the `text` on the `AccessibilityNodeInfo` object in the delegate so TalkBack know what to annouce.
In the future we aim to bring back auto-focusing with links, but only if a screen reader is not on, so that keyboard users can benefit from this.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D75103779
fbshipit-source-id: 05e17f4eb8d5d79ed1d84458f6d5fc6d1571e382
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51563
changelog: [internal]
Throwing errors in C++ is expensive and slow. Let's replace it with logging.
This is to reduce binary size of C++ Animated.
Reviewed By: mdvacca
Differential Revision: D75140875
fbshipit-source-id: 32909572141d8e1b51b60f317716f783aa760265
Summary:
Fixes https://github.com/facebook/react-native/issues/51083. Turbo stripped out the dictionary when the value is null. The old architecture transforms null to NSNull. The null seems useful in cases like #51803 for removing the storage of the key. cipolleschi can you please help to review?
## Changelog:
[IOS] [FIXED] - Turbo module: Fixes dictionary stripped out when value is null
Pull Request resolved: https://github.com/facebook/react-native/pull/51103
Test Plan: Repro please see https://github.com/facebook/react-native/issues/51083.
Reviewed By: rshest
Differential Revision: D74208525
Pulled By: javache
fbshipit-source-id: 53d630c265fba15d25309a3e1deb19dca24f298c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51558
changelog: [internal]
we must call stopRenderCallbackIfNeeded to prevent UI tick from being called when
`NativeAnimatedNodesManager` is deallocated.
Reviewed By: mdvacca
Differential Revision: D75140890
fbshipit-source-id: 9ad32956a877f9ee8256790ba32cb5982a5b0c2f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51519
# Changelog: [Internal]
Hermes Sampling Profiler doesn't require debugger to be enabled - we can use it in fallback Hermes Runtime target delegate. That's probably the last thing to make Hermes really run in `opt` mode.
When Hermes Target is compiled with no Debugger support, we can still define implementation for sampling profiler methods and call them on Hermes Runtime.
Reviewed By: huntie
Differential Revision: D75188276
fbshipit-source-id: e3e0dccd09e0870264e8abc65f96052735d63ad8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51556
Excludes `packages/react-native/flow/` from being published to npm.
**As far as I know**, we already axed open source Flow support with a similar change in D46313482 (Jun 2023).
Changelog:
[General][Breaking] - The `react-native` package no longer ships with the `flow` directory
Reviewed By: cipolleschi
Differential Revision: D75060845
fbshipit-source-id: 3cb81820499383bf095abc97a9ab7e9061c870d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51559
Changelog: [internal]
Improves the support for multi-config benchmarks in Fantom by printing the Fantom configuration summary in the header of the table with the benchmark results for each variant.
Reviewed By: rshest
Differential Revision: D75281972
fbshipit-source-id: 80caf2e668a30ea1454cb932e91dac91192323bf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51541
Changelog: [internal]
Now that we have support for tests with multiple configurations in Fantom, we can configure the test for IntersectionObserver to run with all the flag configurations that affect its behavior, and make sure it doesn't break for anyone while we're rolling out the changes.
Reviewed By: rshest
Differential Revision: D75231300
fbshipit-source-id: e7addf51cffad8c94bb3bf34e99272ee1dd9da2a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51543
Changelog: [internal]
For `ReactFabricPublicInstance-itest` we used a specific pattern to be able to run the same test with different feature flags (having multiple entrypoints with the configuration and a single implementation file). We can simplify this now that we have support for multiple configurations per test file in Fantom.
Reviewed By: rshest
Differential Revision: D75231301
fbshipit-source-id: ffd047b23217c06b1b15ba07da8b5c191cc652e7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51542
Changelog: [internal]
This adds support for Fantom to run specific test suites with different combinations of options/flags, using wildcards as values.
See the new documentation for this feature in this diff for more details.
Reviewed By: rshest
Differential Revision: D75231299
fbshipit-source-id: 0e953e6de68f004944ee29206af49770c8b7dd9b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51528
Changelog: [internal]
This adds some logic to the Fantom runner to display the test configuration with the test results.
Reviewed By: lenaic
Differential Revision: D75063176
fbshipit-source-id: 8371e90247c1a0c24f29a13ead25fa5dbf98ec10
Summary:
ReactPerfLogger target now has an include file that wasn't in the search path.
This commit fixes this by adding "ReactCommon" as search path to the target.
## Changelog:
[IOS] [FIXED] - Added missing search path to swift package
Pull Request resolved: https://github.com/facebook/react-native/pull/51555
Test Plan: No tests yet.
Reviewed By: cortinico
Differential Revision: D75279320
Pulled By: rshest
fbshipit-source-id: b4d217bdcdb45d4b2decee0aeee155b829cdec9d
Summary:
I've been digging into memleaks in RN for some time and noticed that instances of `FabricUIManager` are leaking on reload action even on an empty app. I managed to pinpoint it to [ContextContainer](https://github.com/facebook/react-native/blob/36df97f500aa0aa8031098caf7526db358b6ddc1/packages/react-native/ReactAndroid/src/main/jni/react/fabric/FabricUIManagerBinding.cpp#L522) (which holds `FabricUIManager` on the cpp side) not being deallocated after reload. After much much digging (since contextContainer is passed around in many places) I found that destructor of `ImageFetcher` never runs on reload, and its instance holds `contextContainer`. It turns out that `ImageManager`, which holds `ImageFetcher`, was calling `free` instead of `delete` and the former does not call destructor. After applying it, `contextContainer` does not leak making `FabricUIManager` instances not to leak too 🎉.
## Changelog:
[ANDROID] [FIXED] - Change `free` to `delete` to call destructor of `ImageFetcher` and release `contextContainer`.
Pull Request resolved: https://github.com/facebook/react-native/pull/51492
Test Plan: Run empty RN app in AS, do reload multiple times and see in AS profiler that instances of `FabricUIManager` are kept in memory without this change.
Reviewed By: Abbondanzo
Differential Revision: D75141983
Pulled By: javache
fbshipit-source-id: f13eea96cb7b614c1d6b53184498ef6294614986
Summary:
This PR removes extraneous blank space at the bottom of multiline `TextInput` when using nested `Text` with different font sizes on iOS with the New Architecture enabled.
| Before | After |
|:-:|:-:|
| <img width="283" alt="Screenshot 2025-05-15 at 12 16 05" src="https://github.com/user-attachments/assets/47256267-86ff-45f9-9e60-162d444a4b9d" /> | <img width="286" alt="Screenshot 2025-05-15 at 12 01 32" src="https://github.com/user-attachments/assets/43ce4b0b-6410-4ca5-be37-59c6374ea15c" /> |
The proposed solution is to call `RCTApplyBaselineOffset` separately for each line of text.
Ideally, we would call it separately for each part of text with different font size.
## Changelog:
[IOS] [FIXED] - Fixed blank space at the bottom of multiline TextInput on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/51344
Test Plan:
```tsx
<TextInput
multiline
style={{borderWidth: 1, width: 300, fontSize: 20}}
ref={ref}
placeholder="Type here...">
First line{'\n'}
<Text style={{fontSize: 30, lineHeight: 60}}>Second line</Text>
{'\n'}Third line{'\n'}Fourth line
{'\n'}
Fifth line
</TextInput>
```
Reviewed By: NickGerleman
Differential Revision: D74802648
Pulled By: j-piasecki
fbshipit-source-id: 30f02ae8af66264c1776d241ed8542899e9cdf99
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51550
`adjustsFontSizeToFit` will adjust font size so that given text fits in both veritcal and horizontal bounds. The algorithm to mutate text to fit is executed during TextLayoutManager during layout creation for Fabric, and then re-executed in `TextView.onDraw()`. See D56134348 which introduced the logic.
In Facsimile, we were not seeing font size adjusted when text is too tall. This is because we are only incorporating the height constraint during Spannable mutation during draw, but not the original layout, which Facsimile uses directly.
This could potentially fix other bugs, where width may not corredpond to the final font size we settle on during drawing.
Changelog:
[Android][Fixed] - Fix missing height constraints when creating Fabric layout for `adjustsFontSizeToFit`
Reviewed By: mdvacca
Differential Revision: D75251391
fbshipit-source-id: 77d90c49d48911e63131f9f088cfce13946c67d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51546
A bit of housekeeping: this constructor is deprecated and unused as the class is internal
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D75233988
fbshipit-source-id: 8272ef4a9465c447d04b377b42071f9834092709
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51484
In this diff I'm avoiding a reflection call to ReactInstanceManager.handleCxxError when MINIFY_LEGACY_ARCHITECTURE is enabled, to help proguard to compile-out this method when MINIFY_LEGACY_ARCHITECTURE is enabled
changelog: [internal] internal
Reviewed By: mlord93
Differential Revision: D75085524
fbshipit-source-id: c80246fdb5940c549cc1d310f7ad042cc0482f0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51540
The view culling `CullingContext` depends on the ScrollView component. This adds the dependency to the mounting target in CMakeLists
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D75233669
fbshipit-source-id: 8342ed791082174ac6d5c6f21270b0cd0adcc95f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51539
Follow up to D70322032. Relocates some of our newly added Flow library definitions into the package level `flow/` directory, to help disambiguate their use.
**Types directories after changes**
`packages/react-native/`
- `flow/` — Longstanding location for Flow package/global library definitions. Not imported by source code.
- `src/types/` — Contains public typedefs useful to 3P consumers (TypeScript) (today, just `globals.d.ts` as one module). Not imported by source code.
- `src/private/types/` — Source type modules **in Flow**, that **are imported** by other files in `src/private/`.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D75060846
fbshipit-source-id: 750a31e11b8f65579ce0831273df4d3b86335bdc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51512
Pull Request resolved: https://github.com/facebook/react-native/pull/50585
# Changelog: [Internal]
Replaces `DOMHighResTimeStamp` alias completely in `ReactCommon` with `HighResTimeStamp`.
`DOMHighResTimeStamp` as a type is now expected to be used only in JavaScript.
I didn't update places where we explcitly use `std::chrono::high_resolution_clock`, since it is platform-specific and there is no guarantee that `std::chrono::high_resolution_clock` == `std::chrono::steady_clock`.
Also, places that are isolated and not part of the Web Performance APIs, such as Telemetry for Fabric, are not updates as part of this diff. Although these subsystems are also using `std::chrono::steady_clock` as a low-level representation, they are not sharing it with other parts of the React Native core.
Reviewed By: rubennorte
Differential Revision: D75185613
fbshipit-source-id: 889719368de163e6f529689df6cc16d816fde66c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51511
# Changelog: [Internal]
There are multiple changes:
1. `PerformanceTracer` class, `TraceEvent` struct are moved to `tracing` namespace. These are parts of the Tracing subsystems of the jsinspector, this should bring more clarity and make things more explicit.
2. Added `Timing.h` class which defines conversion logic from `HighResTimeStamp` to absolute units that are expected by CDP.
3. `PerformanceTracer` will receive timestamps for Performance Web API entries in `HighResTimeStamp`.
Also, we will explicilty define a Tracking Clock time origin that will be epoch of the `steady_clock`. This aligns with the approach in Chromium and saves us from aligning custom DOMHighResTimeStamps that can be specified in performance.mark / performance.measure calls: these should not extend the timeline window. I've confirmed that this is the current behavior in Chromium.
Reviewed By: rubennorte, huntie
Differential Revision: D75185467
fbshipit-source-id: 37444392f12e8c9c4479c47c42b2c4badca7ecfd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51532
This change adds documentation to the SwiftPM structure to simplify changing it, especially if we have to port some changes from the cocoapods infra to the Swift PM implementation.
## Changelog:
[Internal] - Add docs
Reviewed By: cortinico
Differential Revision: D75217331
fbshipit-source-id: 153e87883d10ceed5a899c9a7dc362b4d2b7e510
Summary:
To reduce reduntant code by repeating the logging functionality in each JS module, this commit introduces a factory for creating a logger with a given prefix.
- Create factory `createLogger`
- Remove redundant log implementations
- Changed to use factory in hermes.js and ios-prebuild.js
bypass-github-export-checks
## Changelog:
[IOS] [CHANGED] - simplified logging in prebuild scripts
Pull Request resolved: https://github.com/facebook/react-native/pull/51527
Test Plan: No tests so far.
Reviewed By: cortinico
Differential Revision: D75213656
Pulled By: cipolleschi
fbshipit-source-id: 8403cfb8ed76ca3a30cfaaeabcd61ac790e7f0a1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51534
Aims to give us CI coverage of React Native's Jest preset, preventing future bugs like https://github.com/facebook/react-native/pull/51525.
Changes:
- Add a basic "it renders" Jest test to helloworld
- Add "Run Helloworld tests" step to `test-ios-helloworld` job in CI
- Also convert helloworld's `App.tsx` to TypeScript, as easiest way to unblock Jest JSX behaviour.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D75218901
fbshipit-source-id: 601155c59c4483696971df4c29d51549d97f49f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51533
Motivation:
- These fail, when ran from `packages/helloworld/` with the available `jest.config.js` file.
- These aren't currently run in CI.
- Don't seem high value (only covers `set-version` behaviour).
In the next diff, I will be adding a missing basic ReactTestRenderer test.
{F1978505710}
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D75218694
fbshipit-source-id: b22f725aeea49deac069a3268bcf30d4981d44b6
Summary:
The current `URLSearchParams` is missing the readonly `size` property defined in the [whatwg spec](https://url.spec.whatwg.org/#interface-urlsearchparams), and attempting to use it returns `undefined`. This PR adds it.
## Changelog:
[GENERAL] [FIXED] - Added size property to URLSearchParams implementation
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/51507
Test Plan: I've modified the [tests](packages/react-native/Libraries/Blob/__tests__/URL-test.js) to assert the `size` property is correct.
Reviewed By: cipolleschi
Differential Revision: D75205273
Pulled By: rshest
fbshipit-source-id: 4b773dfc95693a5e084663258de50d161d6facff
Summary:
Sometime ago Fabric specific root view tag allocator was added to the codebase: https://github.com/facebook/react-native/commit/7dec625ecabdc23cbae37e0034d29bb7bff17755 This PR makes sure to use it on iOS. It removes the need for additional conversions.
## Changelog:
[INTERNAL] [CHANGED] - use getNextRootViewTag() on new architecture
Pull Request resolved: https://github.com/facebook/react-native/pull/51522
Test Plan: CI Green
Reviewed By: javache
Differential Revision: D75204499
Pulled By: rshest
fbshipit-source-id: 12927887ae229c9fe89fa680f2bd55b5e378f9ae
Summary:
On windows, not all PlatformColors are convertible directly into colorComponents. For PlatformColors, the Color.isColorMeaningful may need to do something other than check the alpha component of the color.
Here I'm moving the implementation of isColorMeaningful into the HostPlatformColor implemantion to allow the host platform to customize the implemenation of isColorMeaningful.
## Changelog:
[INTERNAL] [ADDED] - Allow platforms to override isColorMeaningful
Pull Request resolved: https://github.com/facebook/react-native/pull/51478
Test Plan: No behavior change in core. -- Will be used in react-native-windows to fix https://github.com/microsoft/react-native-windows/issues/14006
Reviewed By: NickGerleman
Differential Revision: D75088378
Pulled By: javache
fbshipit-source-id: 0a456bfe6be93098e3d8fa22390a971e14a4312b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51530
Alternative to https://github.com/facebook/react-native/pull/50784.
`__mocks__` (and other underscored dirs) are correctly excluded from our npm package via `package.json#files`. But in this instance, this is a source file for the `jest/` directory (Jest preset within `react-native`), and should be included — fix by relocating.
Changelog:
[General][Fixed] - Fix missing RefreshControlMock source in Jest preset
Reviewed By: rshest
Differential Revision: D75215731
fbshipit-source-id: 1240344c4236288f31b16513f4df16766ad1e571
Summary:
# Changelog:
[Internal] -
Based on review discussions in on a previous PR, it's a better style to use native Kotlin's `.isNaN` instead of `java.lang.Float.isNaN()`.
This makes sure that we uniformly do so throughout the codebase.
Reviewed By: fabriziocucci
Differential Revision: D75215199
fbshipit-source-id: 3c73638caa26717feb6bf0b08d1d79df6a6c58b2
Summary:
When checking if we should download hermes artifacts, the path to the folder we're checking was wrong, causing hermes to always be downloaded.
This commit fixes this by renaming it from `Libraries` -> `Library`
bypass-github-export-checks
## Changelog:
[IOS] [FIXED] - fixed wrong path in prebuild hermes check
Pull Request resolved: https://github.com/facebook/react-native/pull/51526
Test Plan: Test to run the prebuild script twice with the same hermes version. Hermes should only be downloaded the first time.
Reviewed By: rshest
Differential Revision: D75213331
Pulled By: cipolleschi
fbshipit-source-id: 6eab6befa8f6a15b2215ec5ec9446063ec395ef7
Summary:
Added missing module React-RCTSettings to the Swift package.
This was found when testing intergrating with a bare bones React Native project.
## Changelog:
[IOS] [FIXED] - add missing React-RCTSettings to Swift package
Pull Request resolved: https://github.com/facebook/react-native/pull/51523
Test Plan: Run against a bare bones React Native project (not available in repo yet)
Reviewed By: rshest
Differential Revision: D75204445
Pulled By: cipolleschi
fbshipit-source-id: d9fcb27cc532846eece591152462ff9c88f82302
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51505
to simplify how we download and manage the `ReactNativeDependencies.xcframework`, we added a script that is specular to the `hermes.js` script to handle the download of ReactNativeDependencies.
## Changelog:
[Internal] - Add script to automate the download of ReactNativeDependencies
Reviewed By: mdvacca
Differential Revision: D75151884
fbshipit-source-id: 2938c2919a24e496f5287e7ba31f87970c923d5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51504
This change simplify testing building React Native core using SwiftPM.
It let you use the HERMES_VERSION env var to automatically fetch the latest nightly.
To do so, just call:
```
HERMES_VERSION=nightly node script/ios-prebuild
```
## Changelog:
[Internal] - Handle the `HERMES_VERSION=nightly` case for iOS prebuilds
Reviewed By: rshest
Differential Revision: D75146936
fbshipit-source-id: 1933979b12d80eff005c9a1349df52602b254978
Summary:
Calls to create timers should return sequential ids (integers greater than zero in the spec's words). This regressed in the `TimerManager` implementation, which instead starts at zero inclusively.
This has two side-effects for code assuming a spec-compliant implementation of `setTimeout` and `setInterval`:
- Calls to `clearTimeout(0)` or `clearInterval(0)` will potentially cancel scheduled timers, although it's supposed to be a noop
- Predicates like `if (timeoutId)` will fail since they assume non-negative ids
The change in this PR is to align with WHATWG HTML 8.6.2 (Timers): https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timers
> otherwise, let id be an [implementation-defined](https://infra.spec.whatwg.org/#implementation-defined) integer that is **greater than zero** and does not already [exist](https://infra.spec.whatwg.org/#map-exists) in global's [map of setTimeout and setInterval IDs](https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#map-of-settimeout-and-setinterval-ids).
Specifically,
- we should return `0` to indicate that no timer was scheduled
- we should start generating timer IDs at `1` instead of `0`
This was previously raised in review comments here: https://github.com/facebook/react-native/pull/45092/files#r1650790008
The spec-incompliant behaviour was raised in an issue here: https://github.com/apollographql/apollo-client/issues/12632#issue-3075269978
This PR does not,
- add bounds checking on `timerIndex_` and add a search of an available id that isn't in the unordered map
- exclude `0` from being an accepted `TimerHandle` in `TimerManager::createTimer` or `TimerManager::deleteTimer` since the above bounds checking hasn't been added either
## Changelog:
[GENERAL] [FIXED] - Align timer IDs and timer function argument error handling with web standards.
Pull Request resolved: https://github.com/facebook/react-native/pull/51500
Test Plan:
- Run `setTimeout` / `setInterval`; before applied changes the timeout for the first timer will be `0`
- Run `setTimeout(null)`; before applied changes the timer ID will be non-zero
- Run `setInterval(null)`; before applied changes an error will be thrown rather than `0` being returned
Reviewed By: cipolleschi
Differential Revision: D75145909
Pulled By: rshest
fbshipit-source-id: 6646439abd29cf3cfa9e5cf0a57448e3b7cd1b48
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51496
Fixes problem with generics passed to `VirtualizedSectionList` in generated types. The `flow-api-translator` creates a re-declaration for `export default` variables which shadows generics.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D75141051
fbshipit-source-id: 260ef066038320eee3ffa93692f77f1eff5c9205
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51524
Links in error suppressions will point to the announcement post in Flow FYI.
Changelog: [Internal]
drop-conflicts
Reviewed By: marcoww6
Differential Revision: D75188177
fbshipit-source-id: 27ea1fbee848e9371e679cf423e30bc9608edea0
Summary:
The Flow team is improving the way Flow infers type for primitive literals. This diff prepares the codebase for the new behavior by adding type annotations, or annotations of the form `'abc' as const`.
Changelog: [internal]
Reviewed By: marcoww6
Differential Revision: D75188179
fbshipit-source-id: be50990f23f79cf2d8dae7576af5190218adcafe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51502
While working on a case for Editor on mac, it took me a while to figure out what enum was the root cause:
{F1978470518}
Adding the blaming enum name in the error message would have made my life much easier.
## Changelog:
[GENERAL][Added] - Improve error messages when enum members are missing
Reviewed By: rshest
Differential Revision: D75141414
fbshipit-source-id: 3625d817b218788891252add225f8fffb99e3145
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51481
# Changelog: [Internal]
This is replaced by `HighResTimeStamp::now()`, which is available in a dedicated smal `react/timing` module.
Reviewed By: lenaic
Differential Revision: D75006354
fbshipit-source-id: d41bf73238e9c6bf5c5a9509d60713ce11e6ea4a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50585
# Changelog: [Internal]
Replaces `DOMHighResTimeStamp` alias completely in `ReactCommon` with `HighResTimeStamp`.
`DOMHighResTimeStamp` as a type is now expected to be used only in JavaScript.
I didn't update places where we explcitly use `std::chrono::high_resolution_clock`, since it is platform-specific and there is no guarantee that `std::chrono::high_resolution_clock` == `std::chrono::steady_clock`.
Also, places that are isolated and not part of the Web Performance APIs, such as Telemetry for Fabric, are not updates as part of this diff. Although these subsystems are also using `std::chrono::steady_clock` as a low-level representation, they are not sharing it with other parts of the React Native core.
Reviewed By: rubennorte
Differential Revision: D72649815
fbshipit-source-id: 96bcfaf909d4a7a5bb2ecfdd76f9939f1645fb69
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51454
# Changelog: [Internal]
There are multiple changes:
1. `PerformanceTracer` class, `TraceEvent` struct are moved to `tracing` namespace. These are parts of the Tracing subsystems of the jsinspector, this should bring more clarity and make things more explicit.
2. Added `Timing.h` class which defines conversion logic from `HighResTimeStamp` to absolute units that are expected by CDP.
3. `PerformanceTracer` will receive timestamps for Performance Web API entries in `HighResTimeStamp`.
Also, we will explicilty define a Tracking Clock time origin that will be epoch of the `steady_clock`. This aligns with the approach in Chromium and saves us from aligning custom DOMHighResTimeStamps that can be specified in performance.mark / performance.measure calls: these should not extend the timeline window. I've confirmed that this is the current behavior in Chromium.
Reviewed By: rubennorte
Differential Revision: D74892330
fbshipit-source-id: 514ca23dde8e23fbe07faf673e765674f328f60e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51455
# Changelog: [Internal]
The main idea is that subsystems who might use a different time origin (the starting point of the whole timeline of events), can use `toChronoSteadyClockTimePoint` method to get raw `std::chrono::steady_clock::time_point` and then offset it by some arbitrary epoch: be it unix time origin or `std::chrono::steady_clock::epoch`.
`fromChronoSteadyClockTimePoint` can be used to convert time stamps from external systems, like Hermes.
Reviewed By: rubennorte
Differential Revision: D74892329
fbshipit-source-id: 70f34ce99aead6e0552d87d310c4d6ea4653b8fe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51506
ReactRawTextManager is not used in new architecture, this diff marks it as so
changelog: [internal] internal
Reviewed By: mlord93, cortinico
Differential Revision: D75150100
fbshipit-source-id: 868420e87dc80185d5a51299736ce2ed6a855fe9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51488
The Flow team is improving the way Flow infers type for primitive literals.
Announcement: https://fb.workplace.com/groups/flowlang/permalink/1725180268087629/
This diff prepares the codebase for the new behavior by codemoding `as const` annotations.
## Repro steps
1/ Used steps in D73610163 to produce the code changes.
2/ Reverted files where `flow` errored:
```
flow status --show-all-errors > errors.log
node ~/fbsource/fbcode/flow/facebook/error-analyzer.js errors.log |
awk -F':' '{ print $1 }' | sort -u | grep -v 'Total Error Count' |
xargs hg revert --rev .
```
3/ Reverted files that did not improve error count in new Flow mode
```
# Run Flow before change
~/fbsource/fbcode/flow/facebook/flowd status --show-all-errors > errors-0.log
# Run Flow after change
~/fbsource/fbcode/flow/facebook/flowd status --show-all-errors > errors-1.log
# Compute error counts before and after
node ~/fbsource/fbcode/flow/facebook/error-analyzer.js errors-0.log | sort > errors-counts-0.log
node ~/fbsource/fbcode/flow/facebook/error-analyzer.js errors-1.log | sort > errors-counts-1.log
# Revert files with no change in error count
comm -12 errors-counts-0.log errors-counts-1.log | awk -F':' '{ print $1 }' | xargs hg revert --rev .~1
```
## Note to code owners
Due to the large number of errors involved in this rollout, adding `as const` was the most feasible large-scale automated solution. Ideally, a lot of these errors would be fixed by adding other appropriate type annotations. For example instead of annotating
```
type Shape = {type: 'circle', radius: number} | {type: 'square', side: number} | ...;
type ShapeKind = 'circle' | 'square' | 'triangle';
const circle = {
type: "circle" as const, // <-- annotation added here
radius: 42,
};
shape.type as ShapeKind;
takesShape(circle);
```
a more appropriate annotation would be
```
const circle: Circle = { type: "circle"; radius: 42 };
...
```
Changelog: [Internal]
drop-conflicts
Reviewed By: SamChou19815
Differential Revision: D75114154
fbshipit-source-id: 67ee5673816da9625431e2a2466a1e0038386151
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51487
The Flow team is improving the way Flow infers type for primitive literals. This diff prepares the codebase for the new behavior by adding type annotations, or annotations of the form `'abc' as const`.
Changelog: [internal]
Reviewed By: SamChou19815
Differential Revision: D75114156
fbshipit-source-id: e3175af85cdd2388c3b45af4beb314f334e3f9b5
Summary:
Running with
```
DEBUG=Metro:InspectorProxy DEV=1 js1 run --no-tty-print
```
When a message larger than 100kb is send over the cdp, log it.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D75000887
fbshipit-source-id: 6f426ed4db7ac1996c4f26461a6e0d13c096e5cd
Summary:
As next step of the JSC deprecation, we are removing the CI testing for the JSC engine
## Changelog:
[Internal] -
Pull Request resolved: https://github.com/facebook/react-native/pull/51475
Test Plan: GHA
Reviewed By: NickGerleman
Differential Revision: D75089216
Pulled By: cipolleschi
fbshipit-source-id: 3839914cb58e872ddd82089bd7cb1391ddda20c1
Summary:
Migrate com.facebook.react.views.text.TextAttributes to Kotlin.
`TextTransform` is exposed in the `textTransform` var setter, and there doesn't seem to be a clean way to avoid having to make the `TextTransform` class public again. I have limited its companion to keep it internal as much as possible.
## Changelog:
[INTERNAL] - Migrate com.facebook.react.views.text.TextAttributes to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/51448
Test Plan:
```bash
yarn test-android
yarn android
```
Reviewed By: cortinico
Differential Revision: D74978129
Pulled By: rshest
fbshipit-source-id: ea0594f01738b8c8f4696434fe76974bbb9ff661
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51486
Original commit changeset: 5b313a5e8c07
Original Phabricator Diff: D74198568
Fix the issue that dropdown menus in HSR worlds menu are not clickable.
Reviewed By: xieswufe
Differential Revision: D75108344
fbshipit-source-id: d134ff9287929f8e1fc0995acf2b884d6a67131c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51428
Just refactoring the control flow in these functions (in a separate diff). So, that the logic in subsequent diffs is easier to read: D74769326.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74940681
fbshipit-source-id: 7aabc722948666a13993a1feff7eeca8ef1403cf
Summary:
In https://github.com/facebook/react-native/pull/50734, `LayoutAnimationController` was migrated to Kotlin and all of its methods are now marked as final.
However, this class is used and extended by `react-native-reanimated` in order to provide Layout Animations for Android on the Old Architecture. With all its methods being marked as final, the builds are failing.
This PR restores the possibility to extend `LayoutAnimationController`.
## Changelog:
[ANDROID] [FIXED] - Restored the possibility to extend `LayoutAnimationController`
Pull Request resolved: https://github.com/facebook/react-native/pull/51479
Test Plan: I've checked that this PR fixes build errors caused by `LayoutAnimationController` in react-native-reanimated.
Reviewed By: cipolleschi, mdvacca
Differential Revision: D75079557
Pulled By: cortinico
fbshipit-source-id: beeb700cbad87362dda4b60941124562c4753815
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51477
changelog: [internal]
when using C++ Animated, no need to send events to Objective-C Native Animated.
Reviewed By: lenaic
Differential Revision: D75066259
fbshipit-source-id: 224d15ba2f707f2272a4fec56e5b2685694c7809
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51379
Changelog: [General][Fixed] Fix incorrect flattening / non-rendering of views with backgroundColor set to `rgba(255, 255, 255, 127/256)`
Fixes#51378.
## Context
When testing some unrelated things with Fantom is realized that the color for some text that I wasn't explicitly defining was being set to `rgba(255, 255, 255, 127)`, like here:
https://github.com/facebook/react-native/blob/249a24ac756275eadbe3b4df1ff9c974af1671d2/packages/react-native-fantom/src/__tests__/Fantom-itest.js#L540-L542
When digging a bit more about why, I realized that was actually the value for `UndefinedColor`. When looking a bit deeper, I saw that the value for that constant was being set like this:
```
using Color = int32_t;
namespace HostPlatformColor {
static const facebook::react::Color UndefinedColor =
std::numeric_limits<facebook::react::Color>::max();
}
```
I'm not sure what the logic could've been here:
- Defining it as a value out of bounds for all valid colors? In this case, it's a 32 bit value so all the range of values are actually valid RGBA colors.
- Defining it as a fully opaque white? Seems dangerous for a default because you wouldn't be able to distinguish a explicitly set white color from a non-set color, relevant if you're seeing a white background color in a view on top of another view with any other background color.
The result of this existing logic was actually setting `UndefinedColor` to `rgba(255, 255, 255, 127)` because the alpha channel is defined in the first bits of the value, and `Color` being a signed int with 32 bits, the largest value is `01111....1`, so extracting the first 8 bits, you get 127.
## Changes
This changes the value set for the `UndefinedColor` constant (which is used, among other things, to determine if a view sets a background color, or otherwise could potentially be flattened).
The new value, instead of white with a 127/256 opacity, is black with 0% opacity (or simply the number 0 in `int32_t`).
Reviewed By: javache
Differential Revision: D74869311
fbshipit-source-id: 5582b4803b0b5c72cb3c1b33720c4542c5e3f1de
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51476
Changelog: [internal]
When we added integration of IntersectionObserver in the event loop by default, we changed the timing of the observer notification:
- Before, it was scheduled synchronously from the `observe` call. That means that, if you schedule another task immediately after the observe call, the order is IO callback then task.
- After, it was scheduled at the end of the current event loop tick. That means that, if you schedule another task immediately after the observe call, the order is task then IO callback.
This change in order wasn't accounted for in the tests for IO (which it's added here) and made a test for `structuredClone` break because it was using incorrect assumptions.
This fixes that test.
Reviewed By: rshest
Differential Revision: D75073118
fbshipit-source-id: 38ad2d03686891daf4caa836e1f597917910ddd0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51337
changelog: [internal]
When C++ Native Animated is used, we can't be using TurboModuleAnimated native module. This diff just add the check to make sure that if C++ Native Animated is used, it will be correctly referenced from JS.
Reviewed By: lenaic
Differential Revision: D74490166
fbshipit-source-id: 1b6de3227707168618052ff4ca6a02ca11337607
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51470
changelog: [internal]
To support C++ Native Animated and prevent unnecessary conversion between `folly::dynamic` <-> and `NSDictionary`, a method to apply `folly::dynamic` changes needs to be exposed on RCTMountingManager.
Previously I tried to change existing method `synchronouslyUpdateViewOnUIThread` to take folly::dynamic instead of `NSDictionary`. However this requires a change where we would expose C++ API to Objective-C class only, breaking build system in open source. This approach was backed out in D74881580.
In this diff, I take an alternative approach and expose two methods to apply animation changes:
- Keep the existing API `synchronouslyUpdateViewOnUIThread` as is. This way, Objective-C Native Animated does not need to change.
- Introduce new method for `[RCTSurfacePresenter schedulerDidSynchronouslyUpdateViewOnUIThread]` which accepts `folly::dynamic`. This is used by C++ Native Animated only
Reviewed By: javache
Differential Revision: D74885607
fbshipit-source-id: 124b8800c01deeb6d57af8f4c47bea46cc1bcd66
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51472
Changelog: [internal]
This enables the integration of `IntersectionObserver` with the Event Loop by default.
Reviewed By: rshest, javache
Differential Revision: D74991641
fbshipit-source-id: 7f12d7d5413d12a6a7de53e9d6701195d48996dc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51452
Changelog: [internal]
This implements a long planned refactor of `IntersectionObserver` to have a proper integration with the Event Loop, which unblocks `FragmentRef` in React Native.
The existing integration doesn't integrate with the Event Loop, so the intersection determination doesn't happen as a step in the event loop but in 2 different moments:
1. When you start observing a new target, we check if there are any pending transactions for that target, and otherwise determine the intersection immediately and queue the notifications.
2. Using mount hooks, when a transaction for a surfaceId is mounted, we check intersections for all the observers in that surface.
This has an important problem:
* If you attach a observer on a target before the target is attached to the tree (something that `FragmentRef` will start doing soon), we don't have a pending transaction so we determine intersections immediately. In that case, it's always "not visible" because it's not attached, and then we immediately trigger a transition when mounted in the same tick.
To fix this, we can implement a step in the Event Loop the same way that `IntersectionObserver` does on Web. We would still wait for pending transactions to be mounted to determine intersection timing (the same way we do now, but now checking at the end of the current Event Loop tick), but the dispatch of initial notifications for target that won't change is done at the end of the tick instead of synchronously.
It also refactors the list of active observers as a list of shared pointers to `IntersectionObserver` objects, instead of as list of `IntersectionObserver` objects directly. This is necessary to build the list of pending observers (with stable references) while making sure the ownership stays in the list of active observers.
Reviewed By: javache
Differential Revision: D74883214
fbshipit-source-id: 24accf1dba48d13b5773950a5cbf9ea38f4a1745
Summary:
This PR improves `RCTScreenSize` to handle horizontal orientations. This was causing a flicker whenever opening a Modal in horizontal orientation. Currently, `RCTScreenSize` is used to supply initial state for `ModalHostViewState`:
https://github.com/facebook/react-native/blob/f1697544cd720df21bd7dc8ca993d95a41321e3f/packages/react-native/ReactCommon/react/renderer/components/modal/ModalHostViewState.h#L31
This works great in portrait mode, but causes onLayout the be called twice in horizontal orientation (first with screen size and then with actual size..)
## Changelog:
[IOS] [FIXED] - make RCTScreenSize take horizontal orientation into account
Pull Request resolved: https://github.com/facebook/react-native/pull/51444
Test Plan: Open modal in horizontal orientation
Reviewed By: cipolleschi
Differential Revision: D74978651
Pulled By: rshest
fbshipit-source-id: f026e727b3529766de38dd31059c51b255f33e78
Summary:
Hermes build-type was hardcoded to 'release' in the previous version of the prebuild scripts.
This commit fixes this so that we can provide a build-type for hermes when downloading prebuilt tarballs.
- Cleaned up parameters in hermes.js
- Updated with buildType parameter when suitable
- Fixed some function names
- Updated version file so that it contains build type
- Removed version file when using a local tarball
## Changelog:
[IOS] [FIXED] - Fixed resolving build type when downloading hermes artifacts
Pull Request resolved: https://github.com/facebook/react-native/pull/51283
Test Plan: No test-plan yet
Reviewed By: cortinico
Differential Revision: D74882001
Pulled By: cipolleschi
fbshipit-source-id: cfeed934023712e70f7d04c137e8611164120cec
Summary:
Our Cocoapods config has a list of defines that are used mostly when setting up pods:
- RCT_FABRIC_ENABLED
- USE_HERMES
- RCT_AGGREGATE_PRIVACY_FILES
- RCT_NEW_ARCH_ENABLED
- APP_PATH
- REACT_NATIVE_PATH
- RCT_SKIP_CODEGEN
- SWIFT_ACTIVE_COMPILATION_CONDITIONS
- USE_FRAMEWORKS
- USE_THIRD_PARTY_JSC
- HERMES_ENABLE_DEBUGGER
- REACT_NATIVE_DEBUGGER_ENABLED
- REACT_NATIVE_DEBUGGER_ENABLED_DEVONLY
Out of these, only the following are used in objective-c/c code:
- USE_HERMES
- HERMES_ENABLE_DEBUGGER
- REACT_NATIVE_DEBUGGER_ENABLED
- REACT_NATIVE_DEBUGGER_ENABLED_DEVONLY
This commit adds the required defines to the correct targets.
## Changelog:
Pick one each for the category and type tags:
[IOS] [FIXED] - fixed defines in package.swift
Pull Request resolved: https://github.com/facebook/react-native/pull/51284
Test Plan: No test-plan yet
Reviewed By: cortinico
Differential Revision: D74872272
Pulled By: cipolleschi
fbshipit-source-id: 5d9a68c1d819409bc7400ade622f62bb332d0896
Summary:
When running the prebuild script:
`node scripts/ios-prebuild.js`
The script will now try to resolve and download a prebuilt version of hermes:
1. Hermes artifacts will be extracted to the `./build/artifacts/hermes` folder to ensure that Package.swift can find a version to link against.
2. The script checks the environment variable `HERMES_ENGINE_TARBALL_PATH` and tries do expand the tarball into the artifacts folder from 1
3. If not found, the script reads the hermes version from either the hidden environment-variable `HERMES_VERSION` and tries to download a release-tarball or a nightly tarball for this version. If the version does not exist, the script will fail.
Also added some extra logging features to the script.
bypass-github-export-checks
## Changelog:
[IOS] [ADDED] - Added downloading of hermes artifacts when pre-building for iOS.
Pull Request resolved: https://github.com/facebook/react-native/pull/51216
Test Plan:
1. Delete the `packages/react-native/.build` folder
2. Run the build script (provide a valid HERMES_ENGINE_TARBALL_PATH or a valid Hermes version (or nightly version)
3. Verify that the script successfully exits
4. Build the Package.swift in Xcode and verify that it finds and links the relevant Hermes files, verifying is done by the build succeeding.
Reviewed By: NickGerleman
Differential Revision: D74565936
Pulled By: cipolleschi
fbshipit-source-id: 5bd231999da24cfcce446150ac0fc1b5a4b6a4ae
Summary:
Found an issue with the legacy native module calls in old architecture (https://github.com/facebook/react-native/issues/51443) and got the idea of adding some simple e2e tests for the native modules so regressions like this can be captured moving forward.
This doesn't cover all methods, as not all of them are available for both Android and iOS, and also some of them are currently crashing, so it makes no sense to cover them all yet – but this can be used as a good starting point to increase coverage for essential APIs.
## Changelog:
[INTERNAL] - Legacy Native Module e2e test
Pull Request resolved: https://github.com/facebook/react-native/pull/51449
Test Plan:
```sh
cd packages/rn-tester && maestro test .maestro/legacy-native-module.yml -e APP_ID=com.facebook.react.uiapp
```
<img width="594" alt="image" src="https://github.com/user-attachments/assets/6237613d-f5dc-4d8a-9b12-0980177793eb" />
<img width="740" alt="image" src="https://github.com/user-attachments/assets/8bdef368-13ac-494c-a506-88fff01dc8d6" />
Reviewed By: cortinico
Differential Revision: D74978093
Pulled By: rshest
fbshipit-source-id: f9c7ba3ca5177eb3d3863d2b8252ac17f3d07aa0
Summary:
I noticed the link to networking in new app screen is wrong. So correcting it here
## Changelog:
[GENERAL][FIXED] - Fix Networking URL in New app screen
Pull Request resolved: https://github.com/facebook/react-native/pull/51396
Test Plan: Click on the link to open
Reviewed By: arushikesarwani94
Differential Revision: D74886240
Pulled By: cortinico
fbshipit-source-id: 19ccf63e64f0e40df4a0ab4082299c654926e35d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51465
Prior to D63303709 AttributedString could not represent formatting on an empty string, and so some text content was forcefully added to empty strings during measurement.
This is problematic in combination with Facsimile, where we directly render the layout we used during measurement, since empty text now has a random "I" in it.
Android's TextLayoutManager already knows how to interpret `baseTextAttributes`, and the placeholder is not needed. Other platforms should be updated to do the same, but that may be non-trivial to validate everywhere.
This diff removes logic from ShadowNodes to always inset a placeholder, and instead shims it in platform TextLayoutManagers which have not yet been updated to use `BaseTextAttributes`. That way, we don't force placeholders during measurement, and different platforms can incrementally unjank their code.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D74770916
fbshipit-source-id: 7cf19db1a9a5cf68137bbff81b14ce5288235b2b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51464
Add a module of shared examples, like `TextInputSharedExamples`, to avoid copy/paste between these.
Modifies the empty test example a bit and adds an E2E test.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D74780847
fbshipit-source-id: 30c2830ef0b638680fe75b4bcf9f138f5c01e190
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51389
# Changelog: [Internal]
This is the pre-requisite for the diff on top, which migrates performance-related classes to start using `HighResTimeStamp`.
We should be throwing `SyntaxError` if the specified mark name is not buffered. Like Chromium does:
{F1978032319}
In this diff:
- `PerformanceEntryReporter::getMarkTime` is now public, ca be called by `NativePerformance` and returns `std::optional`.
- `NativePerformance` is responsible for validating that marks are present in the buffer, if their names are specified in `.measure()` call.
- Mark names take precedence over `startTime` and `endTime` values, so if they are specified and not available, then we will throw Error over `jsi` that will be catched on JavaScript side in `Performance.js`.
Reviewed By: rubennorte
Differential Revision: D74837812
fbshipit-source-id: ca2ba198c4c9e6e2d8d37f852affea667f1c174c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51461
We are trying to minimize the amount of non-determinism in flushing Animated operation queues. Initially the `ReactNativeFeatureFlags.animatedShouldSignalBatch` handled non-determinism on the native side, eliminating the use of native mount hooks to trigger operation batch flushes in the native module. However, there is additional non-determinism introduced by JS, where the set of pending Animated operations may be flushed as a result of an effect.
This change eliminates the flushing of Animated operations in the `useEffect` for `createAnimatedPropsHook.js`.
## Changelog
[Internal]
Reviewed By: yungsters, zeyap
Differential Revision: D75003751
fbshipit-source-id: 73c7bb02355b5f634f4a800f46ca5f529cd15ebd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51459
When using `animatedShouldSignalBatch` in combination with `animatedShouldUseSingleOp`, we were seeing an issue where the queue is not flushed deterministically. It would be flushed in an ad-hoc manner by `createAnimatedPropsHook.js`, but this was only if a mount happened to occur in the same frame.
Adding a deterministic queue flush mechanism to the logic handling `animatedShouldUseSingleOp` appears to resolve the issue.
## Changelog
[Internal]
Reviewed By: javache
Differential Revision: D75002657
fbshipit-source-id: 51f50af0f22becf152da15a720ba70dfc158cdbf
Summary:
I noticed a missing debugging text while working on https://github.com/facebook/react-native/issues/50496. It was a typo. I though I might as well send a PR.
## Changelog:
[Android] [Fixed] - Fixing a typo in InterpolationAnimatedNode for debug text.
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/51460
Reviewed By: cortinico, shwanton
Differential Revision: D75005096
Pulled By: javache
fbshipit-source-id: 390452b2b0c6eabfa003b9c95719649c79444d3a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51390
# Changelog: [Internal]
Ideally, these should not be optional, but these values are set at runtime.
Assertions added to validate that these values are set before reporting to `PerformanceEntryReporter`.
Reviewed By: rshest
Differential Revision: D74811439
fbshipit-source-id: 5e95931848263a58d977c07bac0eb18e53b91140
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51420
The checked and unchecked state of the accessibility state property has to be serialized as `{ "checked": true }` and `{"checked": false}`.
This diff updates the serialization of the `accessibilityState` prop for the prop diffing on the View component.
This fixes the e2e test selectors for radio buttons.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D74910744
fbshipit-source-id: 212b78e29a007744ac9283c7ec9b96ce80fd5681
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51451
This diff adds the `fantom_hermes_variant` pragma which can be set to:
- `hermes` for the default Hermes runtime used by RN
- `static_hermes` for the stable version of Static Hermes
- `static_hermes_trunk` for the "trunk" version of Static Hermes
Each variant will set up the correct build options for the runner and the correct compiler to use for the bundle.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D74959718
fbshipit-source-id: 5d30c8e15ab052eb5686f26632f08ab42b5e68c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51393
In D74738548 we copied RCTFollyConvert to Follyconvert and we moved it to a separate file.
The problem is that when we build react native, we now might have duplicated symbols, especially with prebuilds where the symbols are "flattened" together.
To fix this, we can have the old file point to the new file in order not to break our suers and have a single symbol anyway.
## Changelog:
[Internal] -
Reviewed By: sammy-SC
Differential Revision: D74883143
fbshipit-source-id: 98361307286cdc19c57b8f5c9f066aebea992896
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51441
Refactors `RNTesterPlatformTestEventRecorder` so that it does not use `useMemo` from an instance method.
Instead, this diff changes the module to export a hook by the same name, `useRecorderTestEventHandlers`.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D74950333
fbshipit-source-id: 6cb222a6ec077abadbdc7008e822645aba3d07f6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51439
Migrates the `BackHandler` mock to use ESM to mitigate the existing lint warning.
I'm actually not sure this is even used anywhere… and the unmocked `BackHandler` is already using ESM.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D74949885
fbshipit-source-id: 7f37212db2125bb7afdbd342175e3beae6c7c14f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51438
The `ReactNativePrivateInterface` module needs to continue using `module.exports` in order to lazily import dependencies.
For now, we just suppress the `lint/no-commonjs-exports` lint rule.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D74949839
fbshipit-source-id: 295853be7fb988b879b6fd0b15ef31dd6e47cf85
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51434
Migrates files to use ESM to mitigate the existing lint warning.
I am suppressing `RelativeImageStub` to preserve compatibility with the dynamic asset exports generated by Metro (i.e. not ESM with `default` exports).
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D74943031
fbshipit-source-id: ac4b2afd96fe5446acb4452395d7cb42bb5a6c17
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51433
This `ErrorUtils` mock is dead code.
There is no `ErrorUtils` module in React Native. (Maybe there was once upon a time...)
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D74942884
fbshipit-source-id: 893458c4bc6f9ed29452579ce81915a52e6cd649
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51426
Fixes a bunch of ESLint warnings across the codebase.
The only remaining warnings are from the `lint/no-commonjs-exports` rule.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D74942686
fbshipit-source-id: 384de34c7297f7f7fcff1827c8b2e46714a5cda7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51415
Adds the `format` annotation to all files that were missing them.
Also, adds `noformat` to generated files, and removed it from files that no longer need them.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D74901034
fbshipit-source-id: 7e0b85ca8ee2de41278f3aa23cb03e9c266d9c28
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51413
Prefers using this as a destructured import instead of as a member expression of `React`.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D74895841
fbshipit-source-id: c1d3af40134a3721c9a7b676ee1f2c4a18612e4d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51409
Prefers using this as a destructured import instead of as a member expression of `React`.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D74895837
fbshipit-source-id: b9d6082e4882d95f0d2aa1eed13b725edeb854cd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51410
Prefers using this as a destructured import instead of as a member expression of `React`.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D74895844
fbshipit-source-id: 67f334981a1effce051c89e3d4643232aa22b4e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51411
Prefers using this as a destructured import instead of as a member expression of `React`.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D74895840
fbshipit-source-id: 0a3d78d2871c3334b6e1b570744962a4d0168a9e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51408
Prefers using this as a destructured import instead of as a member expression of `React`.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D74895838
fbshipit-source-id: 2cc369e168a7ee10aa4374717f817636841c372c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51412
Prefers using this as a destructured import instead of as a member expression of `React`.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D74895839
fbshipit-source-id: 9ab9fc8bdee6d1764ad86fa2165da32cb266174e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51407
Prefers using this as a destructured import instead of as a member expression of `React`.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D74894324
fbshipit-source-id: 7179f27f8ff1fb1b67745650b38d87cb2ea982b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51406
Prefers using this as a destructured import instead of as a member expression of `React`.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D74894207
fbshipit-source-id: 00286b3dbaa6ce1e4d8d0f0f6c0dfef6505824c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51405
Prefers using this as a destructured import instead of as a member expression of `React`.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D74894042
fbshipit-source-id: 93fbadb32e4a1225836db9d729d7bf502ebddd84
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51404
Prefers using this as a destructured import instead of as a member expression of `React`.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D74893440
fbshipit-source-id: 9032f1e867a34b9cfa808f920a38f2630046eed7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51403
Prefers using this as a destructured import instead of as a member expression of `React`.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D74891875
fbshipit-source-id: 981e85b5da84950c9e66e8d6b6496019e536711d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51401
Prefers using this as a destructured import instead of as a member expression of `React`.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D74889277
fbshipit-source-id: 0d42921758c5d6e108a4c82dbd52b7de89fbef00
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51400
Prefers using this as a destructured import instead of as a member expression of `React`.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D74888314
fbshipit-source-id: 9224c7c371471fe1fc42c8d42d4b37a4edadcacf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51399
Prefers using this as a destructured import instead of as a member expression of `React`.
Changelog:
[Internal]
Reviewed By: rubennorte
Differential Revision: D74888097
fbshipit-source-id: a22ca4b791153ff0c2f4ab34ff8e3ce5e9280e0d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51252
# Changelog: [Internal]
Removes usage of `DOM_HIGH_RES_TIME_STAMP_UNSET` stub contstexpr.
Instead, all events that were using it will now declare timestamps as optional. This is the pre-requisite before migrating these raw `double` values to `HighResTimeStamp`.
Reviewed By: javache
Differential Revision: D74248998
fbshipit-source-id: 9ef223420823d036db815f956e91ff3a712c9833
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51251
# Changelog: [Internal]
Replaces `RuntimeSchedulerClock`, which was an alias for `std::chrono::steady_clock` with previously defined single timestamp abstraction.
Reviewed By: rubennorte
Differential Revision: D74246459
fbshipit-source-id: 2f5e31eb2299856e7eb69f3915fec6597963a3b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51253
# Changelog: [Internal]
Defines bridging template for `HighResTimeStamp` and `HighResTimeDuration`.
When these values are passed to JavaScript over bridge, they will be converted to [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).
Also the other way around, when we list `HighResTimeStamp` or `HighResTimeDuration` as a type of TurboModule spec, it will expect number value from JavaScript.
Reviewed By: rubennorte
Differential Revision: D74506516
fbshipit-source-id: b5893cef4525793eb6fb6326055c261c7b84a724
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51254
# Changelog: [Internal]
Defines single timestamp abstraction that will be used in C++ layer of React Native core:
Key primitives include:
- `HighResTimeStamp`: A class representing a specific point in time with high precision.
- `HighResDuration`: A class representing a duration of time with high precision.
Right now, all these just encapsulate `std::chrono::steady_clock` with no extra custom logic. We might revisit this in a future, once we decide to add support for [`Performance.timeOrigin`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/timeOrigin).
This diff also adds a `README.md` documentation file with a brief summary of the `react/timing` module.
Reviewed By: rubennorte
Differential Revision: D72796412
fbshipit-source-id: 7a92b61202f5e527e020edea2b756b0063971242
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51397
Changelog: [Internal]
Fix order of ancestor titles.
Due to reverse being applied to the title order it flipped order on even contexts.
Reviewed By: rubennorte
Differential Revision: D74886550
fbshipit-source-id: c556af977f1abee633527151a5896c7d69bd0b48
Summary:
Expo is using the backingmap to be able to update properties in a fast and performant way in two overridden view manager subclasses (ViewGroupManager subclass is one of them).
This diff exposes the backing field via JvmName using the `internal_` prefix.
So Expo can keep on accessing the field as they were doing before. In the long run we should prevent them from accessing this property altogether but this would require a different API.
## Changelog:
[INTERNAL] -
Pull Request resolved: https://github.com/facebook/react-native/pull/51386
Test Plan: Build with Expo modules
Reviewed By: cipolleschi
Differential Revision: D74884533
Pulled By: cortinico
fbshipit-source-id: e76673c794a6a125059633d29445d991d867b770
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51383
This diff is a set of alignments/improvements in generated TS types. It includes:
- extending `AppStateStatus` with `extension` and `unknown`,
- exporting `AnimatedProps` under `Animated` namespace,
- resolving issue with discriminated unions in `ProgressBarAndroidTypes`,
- fixing `StyleSheet.create` type to accept only specified style properties,
- extending `TextProps` with `AccessibilityProps`,
extending Fn Args generic with `$ReadOnlyArray` in `ErrorUtils`,
- small `__typetests__` adjustments,
- removing type test `styleDimensionValueValidAnimated` as `DimensionValue` no longer accepts `AnimatedNode`,
- removing `styleDimensionValueInvalid` as `DimensionValue` accepts any string now - template literal types in Flow are not supported,
- changing `overlayColor` type to `ColorValue` to align with manual types,
- fixing `AnimatedPropsAllowList` type which wasn't correct in TS because index signature type was different from style type,
- using `DeviceEventEmitter` instead of `DeviceEventEmitterStatic` in type tests which is equivalent in both new and old types - `DeviceEventEmitterStatic` was only a type of `DeviceEventEmitter`,
- removing type test for checking forwarded key type - doesn't work with new types and that shouldn't be supported,
- removing `Animated.legacyRef` type test - not included in new types,
- adding `DOMRect` from "dom" lib to `globals.d.ts` to not include "dom" lib in the tsconfig - tries to compare globals with `lib.dom.d.ts` and produces many errors,
- exporting `SectionListData`,
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D74807552
fbshipit-source-id: c5254ea0f701f3602b9d716faeb50ca1ab21b013
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51366
We inherited this from the legacy native module infra, where we didn't have access to the module instance. Instead we can use the simpler `methodSignatureForSelector` which works correctly with OCMock (needed in D74815079).
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D74817191
fbshipit-source-id: 6f3f741e9a78dea967a7654e6410ddacfad6d8a3
Summary:
This folder should have been added to the .gitignore.
Gradle is placing some build file over there in the latest version. This prevents it.
Changelog:
[Internal] [Changed] -
bypass-github-export-checks
Reviewed By: cipolleschi
Differential Revision: D74884379
fbshipit-source-id: 7da9682589c2bc161c1b0e3d741d1049b94505e4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51382
This diff replaces `dtslint` which is obsolete and [It is not intended to be used on its own, but as part of the definitelytyped set of packages](https://github.com/microsoft/dtslint) in favor of `tsc` type tests.
It's probably not necessary to have `test-typescript-offline` as tsc does that out of the box but doesn't test with multiple TS versions.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D74804967
fbshipit-source-id: 4c581ba5debf6fd0bb8dcddbb95f3c85b05082d4
Summary:
Expo inherits from the DevServerHelper class, and needs it to be declared as open, the same goes for its public interface.
Expo is using this in `DevLauncherDevServerHelper` and overrides the methods:
- getDevServerBundleURL
- getDevServerSplitBundleURL
- getSourceUrl
- getSourceMapUrl
- isPackagerRunning
This PR fixes this by adding the open to the class and to the methods that should be open
## Changelog:
[ANDROID] [FIXED] - Made DevServerHelper and its method open so that they can be overridden.
Pull Request resolved: https://github.com/facebook/react-native/pull/51323
Test Plan: Verify that we can build against Expo.
Reviewed By: cipolleschi
Differential Revision: D74876479
Pulled By: cortinico
fbshipit-source-id: 0037d6f7cee190a690ec3ec59896df04f46797b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51381
Changelog: [General][Fixed] Fixed codegen breaking when a subset of `modulesConformingToProtocol` fields was specified or when the value was string
D70822061 introduced a new way of defininf modules and components in codegen, but accidentally introduced two breaking changes to the legacy syntax:
- before that diff, in case of 1:1 mapping, the value of the fileds could be a string, while after, it required it to be an array
- before that diff, not all of the fields on `modulesConformingToProtocol` had to be defined in `package.json`, while after, it required all fields to be defined even if unused
Reviewed By: cipolleschi
Differential Revision: D74875251
fbshipit-source-id: 610103b508f1462b4de01725f9b0a87341571197
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51362
Make use of the React 19 feature so that we can remove the remaining `forwardRef` in react native.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74814465
fbshipit-source-id: 7264e137040381621dddc2641fb31114273cfb28
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51369
Make use of the React 19 feature so that we can remove the remaining `forwardRef` in react native.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74815336
fbshipit-source-id: b45f563ee73bd53794319b0d9886d3214caf0544
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51374
Make use of the React 19 feature so that we can remove the remaining `forwardRef` in react native.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74808387
fbshipit-source-id: e724130f88018b2cbe581dfd7a700cfbb0700bb9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51365
Make use of the React 19 feature so that we can remove the remaining `forwardRef` in react native.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74814123
fbshipit-source-id: 5f9410df1710f6a9c59fea7ce1f225b04b67d664
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51364
Make use of the React 19 feature so that we can remove the remaining `forwardRef` in react native.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74814121
fbshipit-source-id: b9b9f09577da1ba59a4b858b538140ab34bdc60d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51367
Make use of the React 19 feature so that we can remove the remaining `forwardRef` in react native.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74810113
fbshipit-source-id: cb841ab71ef582f10f478f2094837cf52d9cdf68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51372
I got notified that a recent change I made was causing a crash. This would happen when the endOffset of the link is larger than the end offset of the line. This can be repro'd with
```
/**
* (c) Meta Platforms, Inc. and affiliates. Confidential and proprietary.
*
* flow strict-local
* format
*/
import {useState} from 'react';
import {Platform, StyleSheet, Text, View} from 'react-native';
export default function Playground() {
const [state, setState] = useState(false);
function toggle() {
setState(old => !old);
}
return (
<View style={styles.container}>
<Text
style={[styles.paragraph, state && {backgroundColor: 'red'}]}
numberOfLines={3}>
<Text>Bacon Ipsum{'\n'}</Text>
<Text>Dolor sit amet{'\n'}</Text>
<Text>{'\n'}</Text>
<Text accessibilityRole="link" onPress={toggle}>
http://www.google.com
</Text>
</Text>
</View>
);
}
const styles = StyleSheet.create({
container: {
flex: 1,
justifyContent: 'center',
paddingTop: 24,
backgroundColor: '#ecf0f1',
padding: 8,
},
paragraph: {
margin: 24,
fontSize: 18,
fontWeight: 'bold',
textAlign: 'center',
},
});
```
This was encountered already by NickGerleman in D46206673 (https://github.com/facebook/react-native/pull/37050) and the fix is fairly straightforward. I modified that fix to check for the endOffset as well.
Changelog: [Internal]
Reviewed By: zeyap
Differential Revision: D74823458
fbshipit-source-id: 08fe81893f1c41d1934215515f88a6e0e546e705
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51363
Make use of the React 19 feature so that we can remove the remaining `forwardRef` in react native.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74814122
fbshipit-source-id: 88a184f84b811ad527e004edf0eb2344db8fe266
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51368
Make use of the React 19 feature so that we can remove the remaining `forwardRef` in react native.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74813682
fbshipit-source-id: c6bb9e286049c8ed16375c3bbb674b26a34459ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51371
Make use of the React 19 feature so that we can remove the remaining `forwardRef` in react native.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74815987
fbshipit-source-id: 1f19757d0219f1d62deb263edfa2a0cc562dd9d2
Summary:
## changelog
[iOS][Deprecated] - RCTFollyConvert.h is deprecated please use /ReactCommon/react/utils/platform/ios/react/utils/FollyConvert.h instead
Pull Request resolved: https://github.com/facebook/react-native/pull/51348
move RCTFollyConverter to utils module so it is more accessible and delete RCTCxxUtils (which only held that one file). Also align on naming and drop RCT prefix.
Reviewed By: cipolleschi
Differential Revision: D74804476
fbshipit-source-id: 9a702b4823a986ed9849707cbb62d024e589bc1d
Summary:
After conversion to Kotlin we could no longer override the removeView function since it is no longer open. The rest of this class can be overridden as before, but since functions are final by default this doesn't work for the new `removeView` function.
Expo is overriding the `removeView` functions in `GroupViewManagerWrapper.kt` (a lot of other ViewManager methods are also overridden here, but the `removeView` is introduced in `ViewGroupManager` and needs to be open as well. `GroupViewManagerWrapper.kt` is a replacement view manager that adds support for a delegate that will receive callbacks whenever one of the methods in the view manager are called.
This commit fixes this by making the removeView function explicitly open.
## Changelog:
[ANDROID] [FIXED] - Made function `removeView` open in Kotlin class
Pull Request resolved: https://github.com/facebook/react-native/pull/51322
Test Plan: Verify that Expo can build against this class.
Reviewed By: javache
Differential Revision: D74807744
Pulled By: cortinico
fbshipit-source-id: 55f4b9deccb7d82ceb78be1d56c2b99a6f7e3ce9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51361
Make use of the React 19 feature so that we can remove the remaining `forwardRef` in react native.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74810512
fbshipit-source-id: 0f902da8b487db353609b8de14f46a4cec23a46b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51358
Make use of the React 19 feature so that we can remove the remaining `forwardRef` in react native.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74812747
fbshipit-source-id: 7ded547ff62ca59d28abfc46a2f57466e2486acd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51338
There was some problems removing this feature flag earlier in that, on older android versions, we would try to focus the top most text input whenever any other text input would try to blur. This was ultimately and issue with how Android implements `clearFocus`. To fix this, lets block the focusability of all views while we clear the focus, then re-enable.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D74760594
fbshipit-source-id: 2811c08ad6ed0855da0a4d7fca89fb08f84905c2
Summary:
Original commit changeset: 4682cf709aa2
Original Phabricator Diff: D73954790
I want to pick this into 0.80 so users can enable the feature flag so this doesn't break older versions
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D74754010
fbshipit-source-id: 75dc96516b00035984741b43814d6fc7df6be0ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51336
Original commit changeset: 12dcaf0c9c35
Original Phabricator Diff: D74678847
I plan on reverting this so that we can in turn revert the diff that this diff fixed so we can pick it into RN 0.80 so that users have some fix on all versions. Right now 0.80 will be broken for older android devices
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D74754164
fbshipit-source-id: fda17da3e9b61ca13f68f6681726ffb3f4f4f6c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51357
This adds a `prepareNative3pDependencies` Gradle task that downloads and prepares all the 3p dependecies.
This will be needed before we download native deps for Fantom.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D74812436
fbshipit-source-id: 85796d0bcffaeef05d3a21d50f39954ef39ae92c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51360
Make use of the React 19 feature so that we can remove the remaining `forwardRef` in react native.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74812991
fbshipit-source-id: 9df7247bcdaed7a880ed0a75a5dcc33fce6f1d86
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51345
Changelog: [internal]
I just realized there were some tests where we didn't migrate to the new recommended pattern.
Reviewed By: rshest
Differential Revision: D74803018
fbshipit-source-id: b74468f1be35fba8d20d3b96ea2b55452a8175ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51343
Changelog: [internal]
This implements `setNativeProps` as a method in the `NativeDOM` C++ TurboModule, so we can replace usages of the method from `FabricUIManager`.
Reviewed By: javache
Differential Revision: D74800815
fbshipit-source-id: cf3c2d4b75c8d30e2528f96d4d63318e1366096a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51342
Changelog: [internal]
Adding a test for `setNativeProps`, as it was missing because we couldn't test this when this test suite was implemented.
Reviewed By: fabriziocucci
Differential Revision: D74800816
fbshipit-source-id: 5f4721e61d1fb41a1898f56be35e6e3b12c9537e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51341
Changelog: [internal]
`measure`, `measureInWindow` and `measureLayout` have been defined in the `NativeDOM` C++ TurboModule for a while, but we didn't migrate the callsites in the DOM APIs to use them. This does that migration so we can remove a few `$FlowFixMe`s and use a cleaner API.
Reviewed By: javache
Differential Revision: D74800814
fbshipit-source-id: 117e4a8798036f2266e25cfc0931e91c148eaf52
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51356
Make use of the React 19 feature so that we can remove the remaining `forwardRef` in react native.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74808564
fbshipit-source-id: 68f55d31c07ceaf7282833bd4b04039e35987935
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51355
Make use of the React 19 feature so that we can remove the remaining `forwardRef` in react native.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74810588
fbshipit-source-id: e979e8fb59d46be6dabc4327b47b20d635864aa9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51353
Make use of the React 19 feature so that we can remove the remaining `forwardRef` in react native.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74809899
fbshipit-source-id: aaa4ef65ea4d4a20c9d9315ae95957e67484c2d8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51354
Make use of the React 19 feature so that we can remove the remaining `forwardRef` in react native.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74808349
fbshipit-source-id: a359278b5d516eb04fc88ea14c21b628f1053fec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51347
The new warnings on RNTester for the imports are covering the New Architecture list item, as you can see from the video.
This prevents maestro from clicking on the list item, and therefore the test fails.
{F1977997600}
## Changelog:
[Internal] - Fix E2E Tests
Reviewed By: cortinico
Differential Revision: D74803709
fbshipit-source-id: 747af57d04c96ba9b0ee642eb70ebf84bca3a3fa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51352
Make use of the React 19 feature so that we can remove the remaining `forwardRef` in react native.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74808254
fbshipit-source-id: 2f5f8d8dbe1bd5fcaba179bea5deed1592dc900c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51346
Changelog: [internal]
I saw that this test was logging errors to the console, which is considered a bad practice in Jest tests.
This prevents the logs from being printed in the test output and also adds assertions to verify what should be logged.
Reviewed By: rshest
Differential Revision: D74803463
fbshipit-source-id: 9c840a51e0e616a6bb15b7a40b3a6937fcb88b64
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51082
Introduces the `IHermesRootAPI` interface and a class implementation.
This root API will contain the previously static methods on
`HermesRuntime`.
The root API will serve as an entry point for users to create the Hermes
runtime and invoke methods that do not necessarily require a runtime.
Diff also moves all usages of the static methods on `HermesRuntime` to
getting the methods from the root API.
Multiple places are depending on Hermes, Hermes snapshot, and Shermes,
so this diff will also update all of these verions of Hermes at once.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D71132855
fbshipit-source-id: fddda83517682779b4aef062efe84e29fd027fae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51182
Wires up the logic to use Facsimile View Manager when flags for prepared layout enabled.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D73161911
fbshipit-source-id: dc8824ecf8a712d5ff52cb8e2d63e85646297d40
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51301
The type of the state we pass has changed, since the original prototype. Need to update the Java side to reflect this.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D74417253
fbshipit-source-id: 9159689e07d6f00504b5116a647c7afdf79005f4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51184
This change adds prepared layouts to `ParagraphState` on Android, for us to send to the client when gating is enabled
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D74356128
fbshipit-source-id: bd1dd5a457869075c561173de398ae1954a20ab5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51185
Was running into issues with split Android ParagraphState, because a lot of code is tied to `#ifdef ANDROID`, which also builds for react-native-cxx.
This does that spliitting, and also introduces `RN_SERIALIZABLE_STATE` to replace previous ANDROID checks related to state serialization, so we can cofine that to just the Android platform. These changes are dependent on each other.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D74374376
fbshipit-source-id: ffb246ea2e16773f85de12209f2d88a95f8bb792
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51305
tsia, there is a lot of TextView specific API calls and instance checks in the delegate that need to be modified. Additionally, facsimile has some custom focusing logic we do not need if we have a delegate
I opted to just do a lot of instance specific logic using `is` . That seems easier for the time being with this text view that should replace our other text view over time.
I also expose a new way of focusing a span on facsimile, which may not be the best way to do that, lmk
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D74104419
fbshipit-source-id: 87c2259bb1698d93afad88ed91cb6322b90714f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51324
This diff just renames the mutexes, so that the method is more understandable.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D74692506
fbshipit-source-id: 3e928ee0465ebed90f9c95ba3eaf28ea148b0e60
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51081
After introducing the interfaces, runtime should be managed through a
shared pointer instead of a unique pointer.
This diff will change the usage in JSI testlib. Later diffs will
actually change the HermesRuntime usages.
Changelog: [Internal]
Reviewed By: lavenzg
Differential Revision: D70113190
fbshipit-source-id: ea831dd8f79750851fd626afe0f1f5550142ac05
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49604
Add JSI castInterface API. This provides a structured way to provide
optional APIs that may or may not be supported in all engines.
Every interface will have its own set of APIs. For instance, Hermes
will provide an interface (`IHermes`) containing Hermes-specific
APIs. In the future, an interface may be created to expose optional
APIs.
A runtime will inherit the interfaces of which the APIs are supported by
the runtime. Users who want to access a specific API may call
castInterface with the UUID of interface containing the API.
For backwards compatibility, the current `jsi::Runtime` will remain as
an object, and its functionalities will not be described by an
interface. However, this may be revisited later.
Changelog: [Internal]
Reviewed By: tmikov
Differential Revision: D68964360
fbshipit-source-id: 3efe61c5bc1a0fa113a192f4abad6d0f135b4301
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51328
RCTSurface is a legacy class. We might be able to kill it off.
Let's decouple RCTSurfaceView from RCTSurface.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D72582309
fbshipit-source-id: 0ffb6c2d08c5ee1eda6ae90955ccbc14f57036b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51327
RCTModuleData is a legacy class. We might be able to kill it off.
Let's deocuple bridgeless from RCTModuleData.
Changelog: [ios][Breaking] - Migrate RCTDisplayLink's API from RCTModuleData
Reviewed By: cipolleschi
Differential Revision: D72582306
fbshipit-source-id: 3e06f8b2036e1f65425c8312644cc92c076e958e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51304
A potential source of truncation we previously experienced with D65171352 is difference in how TextView calculates line spacing with StaticLayout.
As of Android 13, this also appies to how TextView creates the metrics of BoringLayout. Oddly, this is not also applied to `BoringLayout.make()` (I think it ends up only impacting metrics), so we don't pass the flag there. See https://cs.android.com/android/_/android/platform/frameworks/base/+/78c774defb238c05c42b34a12b6b3b0c64844ed7
This could cause some theoretical truncation of simple single line text, so let's match TextView expectations.
Changelog:
[Android][Fixed] - Include fallback line spacing in BoringLayout
Reviewed By: javache, joevilches
Differential Revision: D74694483
fbshipit-source-id: 76dd980b827824f19ac755b3a9a1ec8912cd6ff1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51098
# Changelog: [Internal]
Depending on the sampling rate, there could be lots of samples recorded. Right now, React Native requests the rate to be 10kHz. In reality, Hermes will be slower. How exactly slower will depend on the platform, because sampling profiler implementation is platform-specific. Windows peaks at ~500Hz, whereas iOS and Android that are using signals can reach up to 5kHz, based on my observations. This means that we could record sample approximately every 0.5ms.
For 30 seconds of sampling, we can get around 150k samples, every one of which may have up to 500 call frames (it is a custom limitation on Hermes side). Previously, every call frame could have a unique copy of function name string and url string.
This diff changes the approach to deduplicate strings, keeping a single copy for every unique string. A new abstraction `StringEntry` is added that will keep a const pointer to the string storage and an offset to the entry in this storage.
On React Native side, we are going to re-use these `std::string_view` and keep Hermes' `Profile` alive as long as they are used. We are going to achieve this by keeping unique pointer to the Hermes' `Profile` in React Native's Profile abstraction - `RuntimeSamplingProfile`, which is agnostic to the runtime.
Reviewed By: fbmal7
Differential Revision: D73106068
fbshipit-source-id: bdc7026e19c2677e39e20f14c8532080c5842026
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51264
## Changelog:
[General] [Changed] - Remove native animation fabric sync in JS and infinite animation loop workaround, when cxxNativeAnimated is enabled
when cxxNativeAnimated is enabled, we'll sync native animation props back to Fabric in native, when that happens we can remove the code in JS for same purpose
Reviewed By: lenaic
Differential Revision: D74198568
fbshipit-source-id: 5b313a5e8c07058f939134e9a6d60dcfa3b45842
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51269
This adds an E2E Tests for the fabric interop layer in RNTester, so we can make sure that we don't break the mechanism to add children after the view is rendered
## Changelog:
[Internal] - Add E2E test for FabricInteropLayer
Reviewed By: sammy-SC
Differential Revision: D74590458
fbshipit-source-id: 9483d1ac648d923a8494d6402b9b2f971b9b2547
Summary:
See https://github.com/facebook/react-native/issues/51212 - children aren't updated correctly in an old arch native view using the interop layer under Fabric.
This is caused by the mountChildComponentView method not updating the view, only adding the new view to a list that will be used on the next update to mount the child.
This commit fixes this by adding the same pattern as in unmountChildComponentView where children are inserted directly if the underlying paperview is available in the adapter - otherwise it uses the mounting list as before.
#Closes 51212
bypass-github-export-checks
## Changelog:
[IOS] [FIXED] - fixed adding child views to a native view using the interop layer
Pull Request resolved: https://github.com/facebook/react-native/pull/51213
Test Plan:
**Previous output**:
<image src="https://github.com/user-attachments/assets/472b95e7-0921-46c9-be6a-f31759c0cd26" width="200px" />
**After fix**:
<image src="https://github.com/user-attachments/assets/554387cd-c264-483e-9c52-d9cd40b42601" width="200px" />
Reviewed By: sammy-SC
Differential Revision: D74471278
Pulled By: cipolleschi
fbshipit-source-id: 798f9e7be389359bd6e3aa1b6a6e9fb799fcb369
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51260
This is a preparatory change that adds an example to RNTester for the Fabric interop layer on iOS.
This example is needed to create a Jest E2E tests that will make sure that the Fabric Interop Layer can properly add views as subviews.
We discovered the bug thanks to react-native-maps.
## Changelog:
[Internal] - Add Example for the Fabric Interop Layer to RNTester iOS
Reviewed By: cortinico
Differential Revision: D74579737
fbshipit-source-id: 0c1bbb06790b01313cd98aa4b7152d8aba0cded3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51225
We process a number of props by default in View, so we can provide some amount of compatibility with web API's. The way we then pass these to React means we end up setting a number of props with 'undefined' values. These props need to be diffed, sent to native (so string keys copied via JSI) and serialized to folly::dynamic (on Android) which is just wasteful.
Instead we can mutate the destructured props object and update/insert keys only as necessary to reduce the props payload size.
Changelog: [General][Breaking] View no longer sets any default accessibility props, which should not result in visible changes in behaviour but may affect snapshot tests.
Reviewed By: yungsters
Differential Revision: D74472767
fbshipit-source-id: 462a4495c0672d4bf1752a532acff49b14598e8e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51307
D72228547 added the `exports` field to the main `react-native` package, in which all imports from `./src/*` are explicitly disallowed. This was expected to be a breaking change and to limit the surface area of it, this diff will allow using all imports in jest tests.
Changelog: [General][Added] Added a custom Jest resolver to opt out from handling "exports" in tests
Reviewed By: huntie
Differential Revision: D74708701
fbshipit-source-id: 9a2714f4e6f78ffbad9e56b5bb92657c9ea908ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51285
The `composeStyles` function should correctly determine the type of the input styles (`ViewStyle`, `ImageStyle`, `TextStyle`) base on the output type:
```ts
const combinedStyle8: StyleProp<ImageStyle> = StyleSheet.compose(
// ts-expect-error
composeTextStyle,
composeTextStyle,
);
```
This diff adds generic type checking for `compose` function and fixes `ImageStyle` overflow prop type which accepted `scroll` property (which wasn't previously accepted in manual types) and which enables type system to distinguish `ImageStyle` from `ViewStyle` and `TextStyle`:
previous:
```ts
overflow?: 'visible' | 'hidden' | 'scroll'
```
current:
```t
overflow?: 'visible' | 'hidden'
```
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D74574293
fbshipit-source-id: 751a44f2d3cd43055d93031343995f16ef87b185
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51312
The nativeID and testID prop mapping on the native Java side use full caps `ID` in the setter mapping. Fixing the props diffing result to use the right key in the result for both.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D74724759
fbshipit-source-id: 4291a72cd3081981f4a25f16f8f2bef17230da54
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51311
changelog: [internal]
add a test case for view culling to cover a crash observed in production.
Reviewed By: lenaic, rubennorte
Differential Revision: D74720814
fbshipit-source-id: ed1246ccbaa0d0ab51a6073f20642c1c78872f30
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51310
Changelog: [internal]
Just a bit of separation between these and Fantom own tests.
Reviewed By: lenaic
Differential Revision: D74717487
fbshipit-source-id: f9d8667c823fcda7b1f3222803367c6b15d9309d
Summary:
Resolved a build error [issue https://github.com/facebook/react-native/issues/51297](https://github.com/facebook/react-native/issues/51297) caused by assigning a Boolean to a Property<Boolean>.
Switched from direct assignment to using .set(...) to correctly configure allWarningsAsErrors from project properties.
## Changelog:
- Gradle fix: assign allWarningsAsErrors using .set() for Property<Boolean>
<!-- 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] - [ANDROID] [FIXED]
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/51300
Test Plan:
Fixes build failure with React Native v0.79.2 and Gradle v8.0.
```
npm run start
npm run android
```
no more build errors
Reviewed By: cortinico
Differential Revision: D74706741
Pulled By: rshest
fbshipit-source-id: 31ec923f49a6da63fb5abb464bc38b99b1e8650a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51299
## Resubmit
This change was backed out, due to the WinUI Fabric TextLayoutManager not respecting minimum size constraints, causing early debug assert. D74494087 was confirmed to fix this.
For more safety, we limit fatal debug assertsions to `ParagraphShadowNode`, and only log a native error for other ShadowNodes.
## Original
Android's TextLayoutManager may return widths greather than the max measure constraint.
Yoga will clamp these, but this sort of issue points to a logic bug, and creates issues when we are looking at caching text measurements based on constraint reuse.
Let's debug assert that we don't do that, and fix a case of rounding up at a pixel boundary, to ensure that it doesn't go above max width. This should theoretically be safe, since Yoga is already doing this clamping, which is what dictates final size of the TextView.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D74674460
fbshipit-source-id: 807d6629bb799a3b1a55e378a3243065055ce219
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51303
We do a lot of incorrect `cei()` in text measurement, compensated later by other incorrect bits.
There are a couple of interesting bits here:
A "desired width" is how large a hypothetical text layout would like to be. It is a floating point value, and to avoid truncation, a container must be larger than the desired width. So ceiling this is correct.
We are also passed available width, which may be an exact specification, not at a subpixel boundary. Ceiling this is totally incorrect, since Yoga will disregard our ceiled version, and we just created a layout, larger than our actual measure will be.
We must instead floor `availableWidth`, and we create our layout based off of that, to not give an extra physical pixel, that may not be given to us, if later layout rounding doesn't go our way. We then ceil `desiredWidth` earlier.
Finally, when we have an exact measuremode, we create the layout so that it uses guaranteedWidth`, but act as if it takes the full available space, per-contract, which may be a subpixel size larger. This means we cannot create layouts which cause truncation.
I used this change as an opportunity to clean up `createLayout()`, since we are gating anyways, to remove the duplicated paths, and to avoid the unnecessary `TextDirectionHeuristic` work for BoringLayout case, and since `StaticLayoutBuilder` already defaults to the heuristic we are manually setting.
Changelog:
[Android][Fixed] - Fix more text rounding bugs
Reviewed By: joevilches
Differential Revision: D74685353
fbshipit-source-id: 3700df657958c6efb46bfbbe674051d16a2b7c26
Summary:
X-link: https://github.com/facebook/yoga/pull/1811
Pull Request resolved: https://github.com/facebook/react-native/pull/51298
## Resubmit
This was backed out due to being up the stack from another change that was backed out, but should be safe by itself.
## Original
We want to know if an artifact created during measurement can fully be reused after final layout, but the final layout is allowed to be slightly larger due to pixel grid rounding (while still allowing reuse). It's hard to tell after the fact, whether it is larger because of this rounding (though the measure is used), or if it may be a pixel larger for valid reasons.
We can expose the unsnapped dimensions of a node to give us this information, and to correlate measurement artifacts.
This is most of the time the same as the layout's measured dimension, though I don't think it's safe to use this, since anything else measuring the node after could clobber this (I think `YGNodeLayoutGetOverflow` may also be prone to this as a bug).
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D74673119
fbshipit-source-id: 06d2eb21e28b76458ec88f4dfcaec809707d0390
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51302
We got https://github.com/facebook/react-native/issues/51072#issue-3035616801 which demonstrates that if we have 2 text inputs on a screen we cannot blur them. If you try to blur any, focus jumps to the first one.
This seems to be a bug with Android's `clearFocus` per https://developer.android.com/reference/android/view/View#clearFocus(), this behavior is intended when we are not in touch mode, yet it happens regardless of what mode we are in on this version.
I modified this a bit to swallow `requestFocus` calls if we are in touch mode. This should be fine as no JS focus calls will go through this path. On hardware keyboard focus and focus from `clearFocus`
Changelog: [Android] [Fixed] - Fix bug where focus would jump to top text input upon clearing a separate text input.
Reviewed By: mlord93
Differential Revision: D74678847
fbshipit-source-id: 12dcaf0c9c350d3ed697ff81e8dfb205b7942119
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51257
Changelog: [internal]
Fixes the semantics for `structruredClone` when dealing with platform objects (cloning the supported ones and throwing exceptions for the rest).
Reviewed By: hoxyq
Differential Revision: D74574857
fbshipit-source-id: 71b99e9659cf3fb4bed8f431e9b54d2f9f514706
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51256
Changelog: [internal]
This is just in preparation for `structuredClone` handling the cloning (or not) of platform objects correctly.
It marks all existing Web platform objects in RN as such, and defines the clone method for `DOMRectReadOnly`, `DOMRect` and `DOMException`.
Reviewed By: hoxyq
Differential Revision: D74574856
fbshipit-source-id: 9e9647fcaafcc1d32fb36e5ee40167871572c544
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51255
Changelog: [internal]
Just a small refactor of how we handle non-serializable built-ins in structuredClone
Reviewed By: hoxyq
Differential Revision: D74398113
fbshipit-source-id: 26211920fcd4cf11c5da278e213eaa2b6b9aa1b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51248
Changelog: [internal]
This implements an initial version of `structuredClone`, but only to be used internally (not exposed as a global yet).
The goal is to use this implementation to fix the semantics of the `detail` field in performance entries, which is meant to be cloned.
Reviewed By: hoxyq
Differential Revision: D71407320
fbshipit-source-id: c7ec1229f9c3414d8b95110da6f65828d74b8c8e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51247
Changelog: [internal]
This implements an initial version of `DOMException`, but only to be used internally (not exposed as a global yet).
The goal is to make this available to `structuredClone`, which will be added after this.
Reviewed By: hoxyq
Differential Revision: D71407318
fbshipit-source-id: b28f11542749ceef6485ff934a712eed941a4545
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51267
Changelog: [Internal]
This diff exposes the corresponding target ShadowNodeFamily to a RawEvent through a weak pointer. This is necessary for the upcoming move of pointer event interception from the JS to main thread.
Reviewed By: javache
Differential Revision: D74500630
fbshipit-source-id: 3bcf32855a004e091be64b6171dc65127375534c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51286
This bog action is not really useful. It's currently buggy and spams the user twice + we agreed it provide little value for the user.
Therefore we're removing this message for the time being.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D74645716
fbshipit-source-id: a6b8aa6aa3f3f101ad649d2590bbcb2dc80ee30a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51293
# Changelog:
[Internal] -
Indirect consequence of https://github.com/facebook/react-native/pull/50484, TSAN started to detect a data race in some configurations.
It's possible to have the data race between the `ShadowTreeRevisionConsistencyManager` being set in `RuntimeScheduler` and it being already used in the executor thread (as these things are generally done from different threads).
Differential Revision: D74651070
fbshipit-source-id: bda49371d541815119f119e6986de39c21f9b374
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51074
While working on this class I noticed there are a number of warnings. Let's clean them up.
Changelog:
[Internal] [Changed] -
Reviewed By: mdvacca
Differential Revision: D74001269
fbshipit-source-id: 7e86ffdaf9c82ff5a165618813fa700f8e850a74
Summary:
Follow up from https://github.com/facebook/react-native/pull/51170, static code analysis shows androidx.core.content.res.use as unused, it looked pretty harmless to remove it as there was no context about its usage, but it caused some crashes.
I'm suppressing the warning here, plus adding an explanation on why it is needed to prevent a future developer from touching this file and causing the same regression.
## Changelog:
[INTERNAL] - Suppress unused androidx.core.content.res.use warning
Pull Request resolved: https://github.com/facebook/react-native/pull/51272
Test Plan: Static code analysis should not show the import as unused.
Reviewed By: cortinico
Differential Revision: D74642726
Pulled By: rshest
fbshipit-source-id: 14cec4fe92f06827636410df4b88a3b7088abe52
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51289
Because NaN is always different from NaN, these Float props were always included in the diff when set to NaN. This checks for the specific case where both the current and the prev prop value is NaN.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D74647582
fbshipit-source-id: 7941dcc6a96bed13c2e43232606bd1f9a9179606
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51277
The number of lines prop diffing was not being updated when enabling Props 2.0 and when set through the paragraph attributes. This diff fixes the typo that was causing the bug.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D74619497
fbshipit-source-id: 2ad7d1629106ff16d511760694dcef0cafd9a96e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51276
This diff adds the Android specific props to the `getDiffProps` implementation and enables `TextInput` components for Props 2.0 use in the Fabric mounting manager
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D74610303
fbshipit-source-id: c45abf2b272f5dfb50f4f1bad256e9130a808900
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51227
Standardize error messages thrown from inspector proxy when connection is closed to debugger and link to where they are used in `react-native-devtools-frontend`
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D74484316
fbshipit-source-id: 7885bc5ea41397539814f97d764c9a376ef50eaa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51271
Deletes the feature flag that was gating the new logic to invoke Hermes GC when iOS emits a memory pressure warning.
Changelog:
[iOS][Changed] - Hermes GC is now triggered in response to iOS memory pressure warning.
Reviewed By: fkgozali
Differential Revision: D74605206
fbshipit-source-id: b0753b15f5a30f37ed17bfebff0b491c7e7a6b59
Summary:
This PR refactors the entire ReactAndroid package to replace manual `Arguments.createMap()…` and `Arguments.createArray()…` calls with the new Kotlin DSL helpers `buildReadableMap { … }` and `buildReadableArray { … }`. All eligible call sites have been migrated to the DSL, except in functions whose signatures explicitly declare or return WritableMap or WritableArray.
No runtime behavior changes are introduced; existing functionality and tests continue to pass unchanged.
## 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] [CHANGED] Apply Collections DSL on ReactAndroid package
Pull Request resolved: https://github.com/facebook/react-native/pull/51145
Test Plan:
```
yarn android
yarn test-android
```
Reviewed By: rshest
Differential Revision: D74401357
Pulled By: cortinico
fbshipit-source-id: 0f7b7dfbb7b495675bc4730bdf018666e9041884
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51270
I was informed that we could not reference ourselves with accessibility order when using `useID`. The reason for that ended up being because of this if statement which uses `==`. Note this worked with a normal string like `"foo"` but `useID` has ids like `"<<r0>>"` so I imagine the < and > made this break.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D74601689
fbshipit-source-id: 25adc84248fbfcaff36607d18c170e6c8000cffb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51224
Changelog: [Internal]
We have a bunch of places where we rely on implicit conversion operators of `jsi::Value` and return some primitive type.
This doesn't work well with Bridging, because currently it doesn't take into account these implicit operator conversions: primitives won't be treated as primitivies, but rather as generic `jsi::Value`, which could be many things.
We should be explicit about return type in `toJs`, because it affects the type checking logic.
Reviewed By: javache
Differential Revision: D74478571
fbshipit-source-id: 0633159c5af3a02aafe14e2b137c133d4554a5f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51223
Changelog:
[General][Added] - Added support for bridging Class methods return types
Previously, this wouldn't work, unless you define your C++ implementation of the TM to have primitive return type that can be converted to JavaScript's type.
Reviewed By: javache
Differential Revision: D74478572
fbshipit-source-id: 75c7f589559394704446be1ebac245d38a5c4b2b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51234
Since `createAnimatedPropsHook-test.js` no longer needs to override feature flags, clean up some of the extra logic.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D74535116
fbshipit-source-id: 09dd4c5085f6ee1cbf7d87ab2b7c320119e69651
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51259
Changelog: [internal]
We recently added `Playground-itest` as a quick way to test things with Fantom without committing them.
This does the same for benchmarks, so we can quickly answer questions like:
> is `key in obj` faster than `obj[key]`?
Without having to create a new benchmark manually.
Reviewed By: yungsters
Differential Revision: D74578297
fbshipit-source-id: d86604d459f15652d0c2e1ad16a99d011a1324ca
Summary:
- Convert View implementation to React 19:
- Remove legacy `forwardRef` in favor of built-in `ref` prop.
- Use `use` API instead of `useContext`.
- Drop the extraneous `.Provider` for `TextAncestor` context.
- Remove `displayName` in favor of component name. I'm not 100% sure this is a full fallback but it is valid according to `react/display-name` eslint rule—https://github.com/jsx-eslint/eslint-plugin-react/blob/master/docs/rules/display-name.md
- Based on discussion with Nicola Carti and Riccardo Cipolleschi.
- I tried using flow `component` keyword but it's not enabled in this project. Given the `react-native` package is shipped untranspiled, it's probably safer to avoid newer flow types.
- Overall matched the component style of LogBox.
- It's unclear the exact right way to type a ref since it should be optional for external users of the component but required inside the component. Erring on the side of caution and using optional types so users don't get type errors when `ref` isn't defined.
## Changelog:
[GENERAL] [BREAKING] Upgrade `View` component to React 19.
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/51023
Test Plan: - Type checks should pass.
Reviewed By: rshest
Differential Revision: D74546184
Pulled By: yungsters
fbshipit-source-id: b8257e3a75477c1117b19cd3f8e0843947b092ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51246
Changelog: [General][Fixed] Fix generated types in react-native/virtualized-lists being used without opt-in
D71969602 introduces `exports` field to `package.json` files in `react-native` and `virtualized-lists`. In that diff, the `types` in `virtualized-lists` by default pointed to the new generated types without requiring the opt-in.
This fixes that by requiring the opt-in before using the generated types.
Reviewed By: huntie
Differential Revision: D74573321
fbshipit-source-id: fe05b0204a7200c1c91aac2614aa786bbbced2a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51222
The size parameters are flattened in the source object in the Android image component. This diff converts the `size` object to `width` and `height` props directly set on the source object, fixing image source setting more than one image source.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D74477884
fbshipit-source-id: f6064b4222d5eeafd5d74f9a2044babedd1e291b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51217
Add helper method to build the prop diffing based on the BaseTextProps which are used by the Text and Paragraph props.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D74473004
fbshipit-source-id: 0ae8c0c033ee136da3b8376bd485f8926310dcd4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51230
react-native-exit-app last commit is from 2 years ago.
Removing it as it is broken with our nightly integration
## Changelog:
[Internal] - Remove react-native-exit-app from nightly testing
Reviewed By: cortinico
Differential Revision: D74527792
fbshipit-source-id: 0974b2d857aa6f76c59b0411204798a5fe48cffe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51233
Migrates internal operational and experimental feature flags to React Native's feature flag system, in order to simplify integration of other infrastructure features (e.g. Fantom).
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D74534921
fbshipit-source-id: 1559cba4f208a554bb043a203f331062036c60de
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51220
Changelog: [internal]
Just a playground file to do quick tests in the Fantom environment.
For example, I just used it to know if Hermes supports `AggregateError`, which does:
```
it('...', () => {
console.log('AggregateError', global.AggregateError);
});
```
{F1977824992}
Reviewed By: lenaic
Differential Revision: D74474870
fbshipit-source-id: cbe8a287738b09afe336ae479cc3105d1474e58b
Summary:
Flag was removed in {D74196673}, this cleans up the dynamic flag.
bypass-github-export-checks
Changelog: [internal]
Reviewed By: jackpope
Differential Revision: D74493584
fbshipit-source-id: 6ade542b7e1bd9c4367b7dbef4d2f1ec2d79d0df
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50197
Adds `setRuntimeData` and `getRuntimeData` JSI APIs. This provides a
convenient way for users to store some custom data associated with an
UUID.
For the default implementation of this feature, store the runtime data
in the global map that is shared between all VMs. This is done to keep
JSI lightweight and stateless, instead of adding data members.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D71579532
fbshipit-source-id: 553e28fbf80c93e268d475860197a00d2c5bacf7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50270
Add UUID struct to JSI. This will be used in the incoming changes, such
as identifying JSI interfaces and storing custom runtime data.
Changelog: [Internal]
Reviewed By: tmikov
Differential Revision: D71826382
fbshipit-source-id: e0d9bc20fb0f0e75407b9c88e731623e6a9975dd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51206
When we create a layout from measure constraints, we do some processing of the width, to return a different one, potentially smaller than the layout width, sometimes using line width, and sometimes using the container width.
This logic has gotten spooooky over time, and after a series of changes, and bugfixes, now effectively does nothing!
1. Way back in 2020, yungsters made D21056031 introducing this logic to "shrink wrap" text which is wrapped.
2. "Shrink wrapping" is not how web works when text is wrapped, (though it is how it works when there is explicit newline), and https://github.com/facebook/react-native/pull/47435 later undid this change
3. https://github.com/facebook/react-native/pull/37790 made changes specific to the case of trailing newline, because the logic to "shrink wrap" did not handle correctly.
After D74366936, which changes width used for layout creation to correctly respect `Layout.desiredWidth`, we should be back to multiline layouts, with no paragraph whose lines take up more than container width, being "shrink wrapped", while not doing so when there is wrapping or ellipsization, like current behavior. The desired width also excludes the non-visible trailing whitespace.
It means we can remove all of this logic, while preserving the same behavior. Mismatched measure widths from those used in the intermediate layout may also result in issues for Facsimile (see example in last diff of stack).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D74368513
fbshipit-source-id: df5d7b773ad1888ebca1966ee4020a5c2ce7fd64
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51221
In the case of an empty root node, we don't need `buildStubViewTreeWithoutUsingDifferentiator` to create the initial `StubViewTree`
When testing with Fantom, this caused an additional unnecessary clone of RootShadowNode.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D74472766
fbshipit-source-id: 076e859a6c5795e9026c7a5f8246a5658db4a94b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51214
D74381864 caused a series of crashes to spike due to .IncompatibleClassChangeError: Class 'android.content.res.TypedArray' does not implement interface 'java.lang.AutoCloseable'
This fixes it.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D74468593
fbshipit-source-id: 70c14bdba4f229d4f59a01da3b56cd4fec29752f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51070
Changelog: [General][Internal][Breaking] When a bundle is failing to load throw an error of special type.
### Breaking
`didCompleteNetworkResponse` now throws an Error instead of throwing a string.
In dev, we use [lazy bundling](https://github.com/react-native-community/discussions-and-proposals/blob/main/proposals/0605-lazy-bundling.md#__loadbundleasync-in-metro) which allows us to re-build only the parts of the app that are changed.
However the function that loads these lazy bundles in `loadBundleFromServer.js` for requests that reach `didCompleteNetworkResponse` with an error **throws a string representing the error message** which makes debugging very inconvenient because it lacks stack trace and error type. Throwing strings is not a standard practice. We better throw an error in these cases so it can be handled better.
Why a special type of error?
* As you can see in the "after", in the test plan below, even with a stack trace, it might be hard to know where this error originates from
* Also so extra information can be added on it. Currently adding "url"
* Also to support error handling based on the type of error
Reviewed By: hoxyq
Differential Revision: D73925027
fbshipit-source-id: a0f98d283ec8842696f1b87864fb63cb30c0c028
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51210
Changelog: [internal]
This adds a safety mechanism to Fantom tests to prevent LogBox from swallowing errors.
Now we validate that LogBox isn't installed when running tasks, so we can properly fix error reporting in tests.
Reviewed By: rshest
Differential Revision: D74464749
fbshipit-source-id: ef5e814b14aedbc681a4c7f9f8f60f454b239b6d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51211
Changelog: [internal]
This modifies the setup for Fantom so:
1. We don't inject "InitializeCore" by default.
2. We define a default environment setup module for Fantom with good defaults (LogBox, etc. disabled).
We also migrate all existing tests to use the new module.
The goal of this is to prevent LogBox from being used in tests so we can properly fix error propagation in the work loop (so they're not intercepted by it).
Reviewed By: rshest
Differential Revision: D69003812
fbshipit-source-id: 00353b5055e3700943a08ea67f698d49e068555b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51209
Changelog: [internal]
This refactors `InitializeCore` to extract the initialization logic to a separate configurable module.
By default, this does the same thing it does now, but the new module could be used without `InitializeCore` to set up the environment forcing disabling developer tools (e.g.: for testing in Fantom in development environments).
Reviewed By: rshest
Differential Revision: D69003811
fbshipit-source-id: ab85b10e4f21adccd8844a848d3272c407832031
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51208
Changelog: [internal]
Adding a few more test cases to make sure error handling is fixed considering these use cases.
Reviewed By: rshest
Differential Revision: D74459974
fbshipit-source-id: 9a5865a9a09dd64535b4d38307db6c30f213b45f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51197
This change adds the Package.swift file that can finally build React Native core using SPM
## Changelog:
[Internal] - Add Swift PM file to uild React Native Core using SwiftPM
Test Plan:
prepare the repo with
```
node packages/react-native/scripts/ios-prebuilds.js
```
and by downloading the ReactNativedependencies from the CI
Then open the Package.swift file in Xcode. I successfully built:
- iOS
- iOS Simulator
- Mac Catalyst
Reviewed By: lenaic
Differential Revision: D74393435
Pulled By: cipolleschi
fbshipit-source-id: 7d61ad1d09444a0c16e865062ae448ec1e7ef5ad
Summary:
After unobserve is called, the shadow node actually isn't deleted from the `targetToShadowNode` WeakMap. So, if the element is kept around, the shadow node will leak.
We suspect this doesn't happen in practice. But, still it's good to just do this cleanup, just in case.
Changelog: [General][Fixed] Fix potential leak inside IntersectionObserver
Reviewed By: lunaleaps, yungsters
Differential Revision: D74361644
fbshipit-source-id: 1a5ccce1486aa200fc7318c689bfa887f713c284
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51148
Intersection observer should not be holding on to shadow nodes.
This diff migrates the javascript infra to instead use families.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74262804
fbshipit-source-id: cc090be54f7312ce32b853ddf86567bb43e676b8
Summary:
IntersectionObserverManager now uses families to manage IntersectionObservers.
This diff just migrates its apis to family too.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74263375
fbshipit-source-id: d2e5fda327dfc75f0f711932626643d49cb3322f
Summary:
X-link: https://github.com/facebook/yoga/pull/1809
Pull Request resolved: https://github.com/facebook/react-native/pull/51181
We want to know if an artifact created during measurement can fully be reused after final layout, but the final layout is allowed to be slightly larger due to pixel grid rounding (while still allowing reuse). It's hard to tell after the fact, whether it is larger because of this rounding (though the measure is used), or if it may be a pixel larger for valid reasons.
We can expose the unsnapped dimensions of a node to give us this information, and to correlate measurement artifacts.
This is most of the time the same as the layout's measured dimension, though I don't think it's safe to use this, since anything else measuring the node after could clobber this (I think `YGNodeLayoutGetOverflow` may also be prone to this as a bug).
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D74292949
fbshipit-source-id: 05011c66a9a9480544313eb1dfe2c46bf7742bac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51183
D58818560 tried to deduplicate some code, but introduced an error, where we no longer correctly incorporate the width MeasureMode into the text layout that we create, instead, passing `YogaMeasureMode.EXACTLY`.
In effect, this means the Android layout created always takes up the maximum allowable space, even if content is smaller. This is later masked, because our returned measure when `AT_MOST` is based on maximum line length, and the layout is then recreated when drawing a TextView, but means:
1. Attachments may not be positioned correctly, when using a non-left-aligned paragraph alignment
2. Directly drawing the layout shows the wrong thing
Changelog:
[Android][Fixed] - Fix TextLayoutManager MeasureMode Regression
Reviewed By: rshest
Differential Revision: D74366936
fbshipit-source-id: 3eda8c716ba9790a61c2da19023e140afbb6971d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51180
Android's TextLayoutManager may return widths greather than the max measure constraint.
Yoga will clamp these, but this sort of issue points to a logic bug, and creates issues when we are looking at caching text measurements based on constraint reuse.
Let's debug assert that we don't do that, and fix a case of rounding up at a pixel boundary, to ensure that it doesn't go above max width. This should theoretically be safe, since Yoga is already doing this clamping, which is what dictates final size of the TextView.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D74291373
fbshipit-source-id: 44166f2e47323384cb00f3cf4c32f398e298a63e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51195
This change adds a script that prepares the repository by creating hard links to the header files in the `.build` folder that is also gitignored
## Changelog:
[Internal] - Add sdcript to setup the repository so that we can build it properly.
Test Plan:
run:
```
node packages/react-native/scripts/ios-prebuilds.js
```
observe the folder `.build` being created with all the files.
Reviewed By: cortinico
Differential Revision: D74393116
Pulled By: cipolleschi
fbshipit-source-id: 4951e61b49db83fbebbcc265ae025f53185fec81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51194
This change adds an utils script to set up folders when needed.
## Changelog:
[INTERNAL] - Add utils script
Test Plan: This is tested in the next diff of the stack.
Reviewed By: cortinico
Differential Revision: D74393298
Pulled By: cipolleschi
fbshipit-source-id: db3db61ec938d2ebe5c0bf5ae0a42aa20c673bb0
Summary:
- Added multiple targets to Package.swift
- WIP: Builds up untill we need to touch files in React/Base
## Changelog:
[INTERNAL] - WIP: prebuilding using Swift packages
Pull Request resolved: https://github.com/facebook/react-native/pull/50766
Test Plan: This will be tested in a diff in the stack.
Reviewed By: cortinico
Differential Revision: D74386522
Pulled By: cipolleschi
fbshipit-source-id: 7bac3c21a362c4ef79d0104727cdd3494419012f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51174
Allows the start and end of the scrollview to be faded to different values independently by passing an object containing a "start" and "end" value to the fadingEdgeLength prop.
To support non-uniform edge lengths we use the [FadingEdgeStrength](https://developer.android.com/reference/android/view/View#getTopFadingEdgeStrength()) api to set different values for the start/end of the scrollview. The FadingEdgeStrength value is multiplied by the FadingEdgeLength value [internally by Android when drawing the view.](https://cs.android.com/android/platform/superproject/+/android15-qpr1-release:frameworks/base/core/java/android/view/View.java;l=25007)
Because the value of FadingEdgeStrength is required to be between 0 and 1, we set setFadingEdgeLength to the max value and set the smaller side as a percentage of that value.
Changelog: [Android][Added] Allow fadingEdgeLength to be set independently on the start and end of the scrollview
Reviewed By: martinbooth
Differential Revision: D74222606
fbshipit-source-id: 7010ca803cc48450ab98c2a457fdc72ff47c29d7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51167
Adding the ScrollView properties that are android specific to the common ScrollView props so that they can be diffed in a getDiffProps implementation.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D74327335
fbshipit-source-id: 8e5683d4bf7fe0f6d54d4b97f535731721c60292
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51192
The `build-types` script cannot currently resolve `react-native/assets-registry` and `react-native/js-polyfills`. This diff moves imported types from these packages to `react-native` to include them in generated types.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D74392568
fbshipit-source-id: cbce977b710f54dc53ce1b0fc080704b420490d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51096
**Problem:** `Activity.onBackPressed()` has been deprecated and with targetSdk 36, predictive back will be enforced and the API no longer called. We need to migrate to backward compatible AndroidX `OnBackPressedCallback`.
- https://developer.android.com/about/versions/16/behavior-changes-16#predictive-back.
**Solution:**
`OnBackPressedCallback` is registered conditionally only if it is `targetSdk` 36 or greater.
If the callback in enabled, `onBackPressed()` is not called and callback is used regardless of `android:enableOnBackInvokedCallback` property in <application> or <activity> set in AndroidManifest.xml.
As a workaround callback is manually calling existing `onBackPressed()`.
This is done rather than removing onBackPressed() completely and using only `OnBackPressedCallback` as we are not sure of the impact of removing the implementation entirely. Once we determine it is safe to do so then, we should remove the workaround and fully transition to `OnBackPressedCallback`
* I also surveyed child classes extending ReactActivity for overridden `onPressedBack()` usage and found only one usage which will be handled later.
NOTE: `ReactDelegate.onHostResume()` sets up the `DefaultHardwareBackBtnHandler` using `ReactActivity` (https://fburl.com/ul47tbeo) and will be called from JS `BackHanderl.exitApp` (https://fburl.com/code/a4l2pjsw). Calling `BackHanderl.exitApp` enables predictive back to work.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D74161428
fbshipit-source-id: 2e081ba6922b315e9d1746e83a41bab5277fa62e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51136
This diff attaches doc block to ProgressBarAndroid copied from the manual TS types.
Generated types result:
```ts
import * as React from "react";
import type $$IMPORT_TYPEOF_1$$ from "./ProgressBarAndroidNativeComponent";
type ProgressBarAndroidNativeComponentType = typeof $$IMPORT_TYPEOF_1$$;
import type { ProgressBarAndroidProps } from "./ProgressBarAndroidTypes";
export type { ProgressBarAndroidProps };
declare let ProgressBarAndroid: (props: Omit<ProgressBarAndroidProps, keyof {
ref?: React.Ref<React.ComponentRef<ProgressBarAndroidNativeComponentType>>;
}> & {
ref?: React.Ref<React.ComponentRef<ProgressBarAndroidNativeComponentType>>;
}) => React.ReactNode;
/**
* ProgressBarAndroid has been extracted from react-native core and will be removed in a future release.
* It can now be installed and imported from `react-native-community/progress-bar-android` instead of 'react-native'.
* see https://github.com/react-native-community/progress-bar-android
* deprecated
*/
declare const $$ProgressBarAndroid: typeof ProgressBarAndroid;
declare type $$ProgressBarAndroid = typeof $$ProgressBarAndroid;
export default $$ProgressBarAndroid;
```
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D73855212
fbshipit-source-id: c6c09ea68c9f61f305f96c0954370bb938fc59d9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51135
In generated types default exported variables are re-declared which shadows attached tags and doc blocks. This transform moves necessary comments on top of re-declarations to keep them accessible.
Example output for SafeAreaView:
```ts
import type { ViewProps } from "../View/ViewPropTypes";
import View from "../View/View";
import * as React from "react";
declare const exported: (props: Omit<ViewProps, keyof {
ref?: React.Ref<React.ComponentRef<typeof View>>;
}> & {
ref?: React.Ref<React.ComponentRef<typeof View>>;
}) => React.ReactNode;
/**
* Renders nested content and automatically applies paddings reflect the portion
* of the view that is not covered by navigation bars, tab bars, toolbars, and
* other ancestor views.
*
* Moreover, and most importantly, Safe Area's paddings reflect physical
* limitation of the screen, such as rounded corners or camera notches (aka
* sensor housing area on iPhone X).
*/
declare const SafeAreaView_DEFAULT: typeof exported;
declare type SafeAreaView_DEFAULT = typeof SafeAreaView_DEFAULT;
export default SafeAreaView_DEFAULT;
```
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D74249424
fbshipit-source-id: 5cdd1c746e7fed99e3d3427d6ebf4c0e7ba3f3fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51189
Changelog: [Internal]
Adds a Github action that validates that the typegen script can successfully translate every necessary Flow file to TypeScript.
Reviewed By: huntie
Differential Revision: D74390916
fbshipit-source-id: 8c6d554c8681a2b92a8b182244a329ee538d9e53
Summary:
Selectively disabling autolinking of a native dependency with components registered in the codegen configuration in react-native.config.js causes builds to crash upon launch on iOS. This is because the generated `RCTThirdPartyComponentsProvider.mm` file contains references to the excluded library using `NSClassFromString` causing the returned NSDictionary from `+[RCTThirdPartyComponentsProvider thirdPartyFabricComponents]` to be populated with nil values and therefore crashing the app. This has been confirmed in 0.78.2 and 0.79.2 but probably exists in 0.77.x as well.
The issue has been further described in https://github.com/facebook/react-native/issues/51077.
## Changelog:
[IOS][FIXED] - Skip codegen for selectively disabled libraries in react-native.config.js
Pull Request resolved: https://github.com/facebook/react-native/pull/51078
Test Plan:
1. Install a library that has the componentProvider field set in the codegen config (see reproducer) and install the iOS pods.
2. Build the app.
3. App should run successfully without any crashes.
Reviewed By: cortinico
Differential Revision: D74248371
Pulled By: cipolleschi
fbshipit-source-id: 1ff7b477ed3d94ca45616ae243d3d2d30bd897db
Summary:
Follow up from https://github.com/facebook/react-native/issues/51061 – Static code analysis detected several redundant constructs across the codebase. Most of the ones fixed here are marked as warnings/weak warnings, likely code smells post-migration from Java.
Doing another small round to clean up some of them.
## Changelog:
[INTERNAL] - Kotlin: Clean up redundant constructs
Pull Request resolved: https://github.com/facebook/react-native/pull/51170
Test Plan:
```sh
yarn android
yarn test-android
```
Reviewed By: rshest
Differential Revision: D74381864
Pulled By: cortinico
fbshipit-source-id: 25244cdf384875f7cc4e2d091c8b247710de5ecf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51162
We specify the java target version to 17 for ReactAndroid but not for hermes-engine.
This is causing it to be the default (8) which will cause our build to fail on JDK 21.
This fixes it.
Changelog:
[Internal] [Changed] -
Reviewed By: alanleedev
Differential Revision: D74325107
fbshipit-source-id: 39ba745be4fa754fb0b0408160202940a61fcd94
Summary:
Enables `DEFINES_MODULE` in `React-jsc.podspec`
After upgrading app to RN `0.79`, when installing pods with JSC enabled there is an error being thrown that
`The following Swift pods cannot yet be integrated as static libraries`
`The Swift pod 'RNFlashList' depends upon 'React-jsc', which does not define modules. ...`
when installing packages that use Swift
## Changelog:
[IOS] [CHANGED] - enable `DEFINES_MODULE` in `React-jsc.podspec`
Pull Request resolved: https://github.com/facebook/react-native/pull/51160
Test Plan: RNTester runs and builds correctly
Reviewed By: huntie
Differential Revision: D74325357
Pulled By: cipolleschi
fbshipit-source-id: b994b7e678633440d5e362ae6965b2d5188d34f1
Summary:
Switches to use the version imported through diff train for `eslint-plugin-react-hooks`. This should allow us to finally use component syntax in RN.
bypass-github-export-checks
Changelog: [internal]
Reviewed By: yungsters
Differential Revision: D74203162
fbshipit-source-id: d9ea17e5c6533e8df0889404a7f7798f6f5061c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51138
The co-opting logic failed to account fo the case where the entire text view as a link and therefore turns off ax. In this case I think it makes sense to re-focus that element again so the user can interact with the link.
Changelog: [Internal]
Reviewed By: jorge-cab
Differential Revision: D74262675
fbshipit-source-id: c8d11cdff76cd92170581d167d5a8df64d0dd101
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51155
changelog: [internal]
we have experienced breakages where we stopped propagating accessibility prop to the mounting layer. These tests should catch it.
Reviewed By: fabriziocucci
Differential Revision: D74317767
fbshipit-source-id: 72c6d8c788afe3a9d4d41f7cfc0aa37605b20b6a
Summary:
Static code analysis detected several missing `ReplaceWith` on deprecated methods. This diff addresses some of them by adding the most accurate suggestions based on the implementations.
## Changelog:
[INTERNAL] - Add missing ReplaceWith on deprecations
Pull Request resolved: https://github.com/facebook/react-native/pull/51144
Test Plan:
```sh
yarn android
yarn test-android
```
Reviewed By: fabriziocucci
Differential Revision: D74327121
Pulled By: javache
fbshipit-source-id: 5b338531210bef104208d14cbd0e3320dc566b8e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51157
test-js jobs are failing because the codegen snapshot tests generates a Podspecs withan hardcoded version that does not matches the version we are about to release.
This fix updates the script that set the RN version to make sure it also updates the Codegen snapshots.
This is a porting to `main` of [this PR](https://github.com/facebook/react-native/pull/51156).
## Changelog:
[Internal] - Fix set-rn-version to account for codegen snapshot test files
Reviewed By: fabriziocucci, cortinico
Differential Revision: D74321590
fbshipit-source-id: 6837e60a0a2834030680f7ec0c7584bf2622f33e
Summary:
When testing the release by running the `test-e2e-local` for RNTester on iOS, the script sometimes fails because it expect to have codegen properly built before running the app.
This fix makes sure we build the codegen package.
## Changelog:
[Internal] - Fix building the codegen
Pull Request resolved: https://github.com/facebook/react-native/pull/51130
Test Plan: Tested locally
Reviewed By: fabriziocucci
Differential Revision: D74248031
Pulled By: cipolleschi
fbshipit-source-id: 319f3332c616f7118b673fb7acb63c2e15946b2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51151
changelog: [General][Deprecated] - deprecate type aliases ShadowNode::Unshared and ShadowNode::Weak in favour of std::shared_ptr<ShadowNode> and std::weak_ptr<ShadowNode>
migrate away from using these type aliases to avoid confusion.
It is unclear from ShadowNode::Unshared what it means. This can be avoided by using std::shared_ptr<ShadowNode> directly. The same applies to ShadowNode::Weak.
Reviewed By: rubennorte
Differential Revision: D74245228
fbshipit-source-id: f22a18e87f170e46f5079e0ee7678700a3f5f623
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51149
Changelog: [internal]
This replaces the use of `ShadowNode` with `ShadowNodeFamily` in the `MutationObserver` logic to prevent retaining stale subtrees of the nodes being observed.
It refactors some existing logic so we don't need to keep track of the shadow nodes in JS. It was only used to be able to find the node for a target after unmounted, so we could "unobserve" it, but `MutationObserver` doesn't support unobserving individual targets anyway, so we removed that use case and implemented a more general `unobserveAll` method that doesn't require the shadow nodes in the first place.
Reviewed By: javache
Differential Revision: D74240834
fbshipit-source-id: 6d4c43a561780962874c76615fb53369c0c68cf7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51128
Changelog: [internal]
Just a minor refactor of a method in `MutationObserver` which was doing some redundant work that could be avoided.
Reviewed By: javache
Differential Revision: D74247437
fbshipit-source-id: 510d26f2a315582df9cddc215bf516d3d4ebd341
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51133
Changelog: [internal]
Having a single native module with all the test-specific functionality that we need in native in Fantom is just more convenient.
Reviewed By: rshest, huntie
Differential Revision: D73997209
fbshipit-source-id: 5d3aa69a2c799166a1351fbff3e80e4396cec9c6
Summary:
Static code analysis shows that there are a lot of unresolved KDoc references. This is just another round addressing several of them.
## Changelog:
[INTERNAL] - Fix unresolved KDoc references
Pull Request resolved: https://github.com/facebook/react-native/pull/51142
Test Plan: Verify that the comments link the classes correctly using Android Studio.
Reviewed By: rshest
Differential Revision: D74305933
Pulled By: javache
fbshipit-source-id: f512a33fa5da46fb828bb76bd95d9502261ea08a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51141
This diff introduces ReactSoftExceptionLogger.CategoryMode to limit categories used on soft errors, the limiation will only create a lint warning but won't create a compilation error.
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D74263367
fbshipit-source-id: 56fb2ef0ad3d24810172af300e43ecc1f479464f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51089
Currently, `IntersectionObserver#observe` retains a reference to the `ShadowNode` of the view that is supplied as an argument, which is used to compute intersection whenever a shadow tree is committed.
However, the `shadowNode` includes all of child nodes and state at the time that `IntersectionObserver#observe` is called. This means that an active `IntersectionObserverEntry` will retain references to memory that would otherwise be deallocated (e.g. if children of the observed view are unmounted after `IntersectionObserver#observe` is called).
This diff refactors `IntersectionObserver` to instead retain a reference to the `ShadowNodeFamily`, which does not retain references to child nodes and still eanbles `IntersectionObserver` to compute intersections.
Changelog:
[General][Changed] - Fixed `IntersectionObserver#observe` to avoid retaining memory for unmounted child nodes of observed views.
Reviewed By: RSNara
Differential Revision: D74130479
fbshipit-source-id: 6b581f73f06b93e6463d5004c181c39aae13896a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51118
changelog: [internal]
1. `ConcreteState` and `State` were taking shared_ptr to family even though they only use weak_ptr.
2. `ConcreteState` was taking a const& to `data`. It unconditionally takes ownership of data, make it obvious in the interface.
Reviewed By: lenaic
Differential Revision: D74024980
fbshipit-source-id: 22401d4153588861f3edd04af0bdc7213a8056ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51121
Previously could match via the `"./*"` subpath when `"react-native-strict-api"` is not set. Only the entry point `./types_generated/index.d.ts` should be exposed.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D74242716
fbshipit-source-id: 232c90f34fafe8fdf1a5a7ef1fec4acc191525b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51101
TS LSP suggests importing/using components from `types_generated` directory which are exported under slightly different name than root exports. Prefixing default exports with `$$` fixes the issue.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D74177107
fbshipit-source-id: 86a6869c2aa7a113915184e4857a7882710b1db4
description:Which JavaScript engine to use. Must be one of "Hermes", "JSC".
default:Hermes
use-frameworks:
description:The dependency building and linking strategy to use. Must be one of "StaticLibraries", "DynamicFrameworks"
default:StaticLibraries
architecture:
description:The React Native architecture to Test. RNTester has always Fabric enabled, but we want to run integration test with the old arch setup. Must be one of "OldArch" or "NewArch"
`> **Newer version available**: You are on a supported minor version, but it looks like there's a newer patch available - ${labelWithContext.newestPatch}. Please [upgrade](https://reactnative.dev/docs/upgrading) to the highest patch for your minor or latest and verify if the issue persists (alternatively, create a new project and repro the issue in it). If it does not repro, please let us know so we can close out this issue. This helps us ensure we are looking at issues that still exist in the most recent releases.`,
stale-issue-message:'This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.'
stale-pr-message:'This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.'
stale-issue-message:'This issue is stale because it has been open for 180 days with no activity. It will be closed in 7 days unless you comment on it or remove the "Stale" label.'
stale-pr-message:'This PR is stale because it has been open for 180 days with no activity. It will be closed in 7 days unless you comment on it or remove the "Stale" label.'
close-issue-message:'This issue was closed because it has been stalled for 7 days with no activity.'
close-pr-message:'This PR was closed because it has been stalled for 7 days with no activity.'
exempt-issue-labels:'Help Wanted :octocat:, Good first issue, Never gets stale, Issue:Author Provided Repro'
- name:Build the Helloworld application for ${{ matrix.flavor }} with Architecture set to ${{ matrix.architecture }}, and using the ${{ matrix.jsengine }} JS engine.
- name:Build the Helloworld application for ${{ matrix.flavor }} with Architecture set to New Architecture.
shell:bash
run:|
cd packages/helloworld/android
cd private/helloworld/android
args=()
if [[ ${{ matrix.architecture }} == "OldArch" ]]; then
needs:[prepare_hermes_workspace, build_hermes_macos, prebuild_apple_dependencies]# prepare_hermes_workspace must be there because we need its reference to retrieve a couple of outputs
needs:[prepare_hermes_workspace, build_hermes_macos, prebuild_apple_dependencies, prebuild_react_native_core]# prepare_hermes_workspace must be there because we need its reference to retrieve a couple of outputs
needs:[prepare_hermes_workspace, build_hermes_macos, prebuild_apple_dependencies]# prepare_hermes_workspace must be there because we need its reference to retrieve a couple of outputs
needs:[prepare_hermes_workspace, build_hermes_macos, prebuild_apple_dependencies, prebuild_react_native_core]# prepare_hermes_workspace must be there because we need its reference to retrieve a couple of outputs
@@ -28,7 +28,7 @@ Examples of contributing to the release include being a [community releaser](htt
### Current partners:
* **[Coinbase](https://www.coinbase.com/):** Publishes [posts](https://blog.coinbase.com/tagged/react-native) advocating React Native usage. Supports `@react-native-community/datetimepicker` and other community modules to migrate to the new architecture. Supports releases in testing and feedback.
* **[Callstack](https://callstack.com/):** Maintains the [React Native CLI](https://github.com/react-native-community/react-native-cli) and [other community libraries](https://github.com/callstack), organizes [React Native EU](https://react-native.eu/) and hosts [The React Native Show podcast](https://www.callstack.com/podcast-react-native-show)
* **[Callstack](https://callstack.com/):** Maintains [React Native Community CLI](https://github.com/react-native-community/cli), develops [RNEF](https://rnef.dev), [Re.Pack](https://re-pack.dev) and [other community libraries](https://github.com/callstack). Hosts [React Universe Conf](https://www.reactuniverseconf.com/) and [React Universe On Air](https://www.callstack.com/podcast).
* **[Expo](https://expo.dev/):** Builds [Expo Go and SDK](https://github.com/expo/expo), [Snack](https://snack.expo.dev/), and [Expo Application Services](https://expo.dev/eas). Maintains [React Native Directory](https://reactnative.directory/), stewards [React Navigation](https://reactnavigation.org/) along with other partners.
* **[Infinite Red](https://infinite.red/):** Maintains the [ignite cli/boilerplate](https://github.com/infinitered/ignite), organizes [Chain React Conf](https://cr.infinite.red/), hosts the [React Native Radio podcast](https://reactnativeradio.com), publishes the [React Native Newsletter](https://reactnativenewsletter.com)
* **[Meta](https://opensource.fb.com/):** Oversees the React Native product and maintains the [React Native core repo](https://reactnative.dev/)
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.