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
Summary:
When building the RNDependencies XCFrameworks we saw some errors in the CI servers about rsync failing:
`rsync(3031): error: poll: hangup on nonblocking write`
We decided to fix this by changing from using rsync to cp.
This commit fixes this by replacing rsync with cp, and adding a cleanup step after copying the XCFramework files.
## Changelog:
[INTERNAL] [FIXED] - Replacing rsync with cp, and adding a cleanup step after copying the XCFramework files.
Pull Request resolved: https://github.com/facebook/react-native/pull/51095
Test Plan: Run RNDependencies scripts on CI and verify that they're working as expected.
Reviewed By: fabriziocucci
Differential Revision: D74236114
Pulled By: cipolleschi
fbshipit-source-id: accd84abf7601919cfdbc1b6a8681a61d4293ca5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51112
Throw if getCatalystInstance() is executed when running on bridgless mode + legacy arch minification
This should be safe given that all the methods of BridgelessCatalystInstance throw exceptions
changelog: [internal] internal
Reviewed By: alanleedev
Differential Revision: D74200099
fbshipit-source-id: a888061250f19348a22895c3684aa2333280c916
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51111
BridgelessCatalystInstance is unused in bridgeless, any usage will lead to an exception / crash.
This diffs marks BridgelessCatalystInstance as LegacyArchitecture and removes DoNotStrip annotation to enable further optimizations
changelog: [internal] internal
Reviewed By: alanleedev
Differential Revision: D74200097
fbshipit-source-id: f99b6fa74c30bdf0e1cd6758e223601b3ce5826c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51088
Creates `ShadowNodeReferenceCounter`, a module with utilities for writing Fantom tests that make assertions about the reference count for a `ShadowNode` object.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D74131710
fbshipit-source-id: a949a402ee52f40445ce99c712540e80c8a05065
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51065
This adds infrastructure to let us start storing cached Android text layouts as part of a `ParagraphShadowNode`. After this, we will clear them out, and propagate them to state. Right now, the flag doesn't do much, apart from extra work.
This is done by adding `TextLayoutManagerExtended::supportsPreparedLayout()`, and `TextLayoutManager::PreparedLayout` types, to shim between platforms, then on Android, we add a `PreparedLayout`, which is for now just an Android layout, with extra field (`maxNumberOfLines`, for some reason not exposed on recent versions).
Android `TextLayoutManager` java side is split a little bit, so that we reuse all the existing logic for prepared layouts. I tried to set up the boundary, so that we don't reserialize a MapBuffer after preparation, and for simplicity, this means source of truth for attachment count, and attachment sizes, now lives on the layout. This means we need to change boundary a bit, where we are no longer able to pass in a buffer to fill from C++ side of attachment positions.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D73970149
fbshipit-source-id: ff71c227e062c16fe52a4eb3ba2acbebf3d96e56
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51107
Changelog: [iOS][Deprecated] Deprecate loadImageForURL in favor of new signature which uses completionHandlerWithMetadata
Updating the signature of completionHandlerWithMetadata to allow passing metadata through the completionHandlerWithMetadata in order to enable better instrumentation of image loading.
Reviewed By: philIip
Differential Revision: D73162738
fbshipit-source-id: 8e7e4ac35c9685a362a2efe08ebebbf0dd249ff9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51108
We calculate the width of text to be the full width of the container, if the text overflows the bounds of the container, instead of the wrapped width, to match the behavior on web.
Incorporating line count into layout defeats this logic, since the final layout never overflows. We need to also check to see if we are ellipsized (had overflow) instead.
Changelog:
[Android][Fixed] - Assume full container width when ellipsizing line
Reviewed By: joevilches
Differential Revision: D74204041
fbshipit-source-id: 1c2a7fc50f101bd4c9ed2f979534731992b5310b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51106
There was a strange bug reported to us with `accessibilityOrder` where an OCR model would announce text on the screen sometimes. This would happen if a focused `View` without a label would wrap `Text` that was was not included in the `accessibilityOrder` array. What happens under the hood is we have a focused `View` trying to coopt a label. It finds no accessibility nodes under it (because the `Text` has `importantForAccessibility` set to `NO`) so it falls back to this weird TalkBack behavior. It both reads the text from the TextView and announces an OCR announcement - leading to repeating the text.
To fix this we just check if we are going to coopt text and if we do then we do not set `importantForAccessibility`. Behavior here changes a bit. Links are not accessible without having to reference the Text, setting `accessible={true}` on non-referenced `Text` will lead to be focusable.
These are both less bad than what we had before though, so I think this tradeoff is fine.
Changelog: [Internal]
Reviewed By: jorge-cab
Differential Revision: D74101530
fbshipit-source-id: 0678915efdc46a6273f79927b87f22bc9017814a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50997
In some apps, we spend a non-trivial amount of time calling ShadowNode destructors on the UI thread.
A simple way to avoid stalling the UI thread is to move the `baseRevision_` instance to a data structure that is cleared on a background thread, so it's tree of ShadowNode shared_ptrs are released (and in most cases destroyed) on the background thread.
Rather than using std::thread, this change introduces the LowPriorityExecutor abstraction that should be supplied by host platforms. The implementation of this LowPriorityExecutor for each platform is as follows:
- iOS: uses dispatch_async to a low priority dispatch queue
- Android: uses a pthread with SCHED_OTHER and priority = 19
Moving the ShadowTreeRevision into a lambda capture and punting the lambda to the LowPriorityExecutor moves the destructor calls of the ShadowNodes to the host platform implementation of the LowPriorityExecutor.
This change is also guarded by a feature flag so we can keep an eye out for potential memory leaks.
## Changelog
[Internal]
Reviewed By: NickGerleman
Differential Revision: D73688009
fbshipit-source-id: 6a66da248e6fe5c38375bf026499346e8381e75a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51018
`ReactNativeTypes` deep imports `MeasureOnSuccessCallback`, `PublicInstance`, `PublicRootInstance` and `PublicTextInstance`. The `MeasureOnSuccessCallback` type is already root exported, `PublicInstance` is exported as `HostInstance` and there are two types left to export to root import all of them from react-native. This is needed for `simpleResolve` to properly resolve and build types located in `ReactNativePrivateInterface`.
This cannot be fixed on the resolver level because that would also involve change in the `exports` field in `package.json` to enable types resolution for deep paths which should be strict by design.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D73926160
fbshipit-source-id: 3a711a0f002ea42d9ad538c07ec00f22cc4afb6b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51091
Fix for top padding with Android edge-to-edge (default for current version of the RN template). We add a `statusBarHeightOffset` explicitly, since this is not covered by the builtin `SafeAreaView`.
{F1977676990}
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D74142357
fbshipit-source-id: 6d70db43d8b80b7e3d2d4b598e29560efa046b5c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51066
Splits up some of the `measureText` code in Android TextLayoutManager, ahead of D73970149, which adds `measurePreparedLayout` to reuse most of this logic. Most significant change, is we pull out logic to iterate and retrieve metrics for attachments, since `measurePreparedLayout`, needs to also return dimensions, and fill into ArrayList, instead of received buffer.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D74035246
fbshipit-source-id: 2a0f5b171c4343e26ffa5b2538a0018939b06773
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51055
When clipping to the padding box without a background or border set, we should default to clipping to the drawing rectangle.
This ensures accurate clipping behavior when there is no background or border set. This is because it seems bounds accommodates the contents of the drawables but when no content is present (either a background or a border) the bounds are 0. In which case we want to rely on the drawing rect instead of the bounds for this edge case.
Changelog: [Android][Fixed] - Fix incorrect clip to padding box on new Background and Border drawables
Reviewed By: NickGerleman
Differential Revision: D74014372
fbshipit-source-id: bd5a496db6de44c4185760ed72b3013d9f2faa00
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51039
We added a feature flag in case this broke things. Its been about 4 months now with now issues, I think we can clean this up.
Changelog: [Android][Fixed] - Can now focus TextInput with keyboard
Reviewed By: NickGerleman
Differential Revision: D73954790
fbshipit-source-id: 4682cf709aa2f34ba69e76a35d07a908edb28f23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51053
unstable_hasComponent(component) first registers the component with react native, if possible. Then, it returns you whether registration succeeded.
## Problem
For unregistered components, the initial call returns false. But, all subsequent calls return true.
The reason why: After the initial call fails, react native registers unimplemented view under that component name. So, all subsequent calls return true.
## Solution
Just record the initial loopup result. And always return that initial lookup result from this method.
Changelog: [iOS][Fixed] Fix bug: unstable_hasComponent(*) = true for unregistered components for n > 1th call.
Reviewed By: yungsters, cipolleschi
Differential Revision: D73949864
fbshipit-source-id: ac5b6fc373cb1b2436045ae1f78391f0712bca17
Summary:
This is an automatically generated fixup patch to bring fbsource back into sync with
facebook/react on GitHub. Please land this patch as soon as possible, as the difference
reflected on here is already on GitHub and future changes may depend on these
changes!
Changelog: [Internal]
<< DO NOT EDIT BELOW THIS LINE >>
diff-train-skip-merge
Generated by: https://www.internalfb.com/intern/sandcastle/job/22517999956752681/
GitHub Repo: facebook/react
Reviewed By: kassens
Differential Revision: D73844457
fbshipit-source-id: 840a8448839992538427cd52501cdfaf0a2e82da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51062
Document logic implemented in ComponentDescriptorRegistry when a component is not found
changelog: [internal] internal
Reviewed By: arushikesarwani94, cortinico
Differential Revision: D74036572
fbshipit-source-id: 20a5d182e0308538cdfa3f5e97957d488f010f0d
Summary:
This PR introduces a concise Kotlin DSL for constructing `ReadableMap` and `ReadableArray` in Android native modules:
- Adds `buildReadableMap { … }` and `buildReadableArray { … }` functions, modeled after Kotlin’s `buildMap`/`buildList` APIs.
- Wraps `Arguments.createMap()` / `Arguments.createArray()` in a type-safe, nested DSL to reduce boilerplate and prevent errors.
- Improves readability and maintainability when assembling nested map/array structures for React Native bridges.
Current code like:
```kotlin
val map = Arguments.createMap().apply {
putString("name", user.name)
putInt("age", user.age)
// …
}
```
can now be written as:
```kotlin
val userMap = buildReadableMap {
put("name", user.name)
put("age", user.age)
put("scores") {
user.scores.forEach { add(it) }
}
}
```
This feature proposal also written in [[Android] Support Collection DSL](https://github.com/react-native-community/discussions-and-proposals/issues/899)
## Changelog:
[Android] [Added] - Collections DSL functions for Kotlin(`buildReadableMap`, `buildReadableArray`)
Pull Request resolved: https://github.com/facebook/react-native/pull/51042
Test Plan:
### Run Unit Test
```shell
cd packages/react-native/ReactAndroid
./gradlew :ReactAndroid:unitTest
```
Ensure all tests in `src/test/java/.../ReadableMapBuilderTest.kt` and `ReadableArrayBuilderTest.kt` pass.
Reviewed By: javache
Differential Revision: D73986390
Pulled By: cortinico
fbshipit-source-id: b9f94327646bcb6e0190cdd06dfb9bb5eaa6375c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51079
This test was not using AssertJ. I've updated it then.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D74065455
fbshipit-source-id: 2393340fd75aaf9599ba789237c29bb91e0192ae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51025
(Sparsely) wires up reporting of Network events to the Web Performance subsystem.
Our plan is to report to the Web Performance APIs (lightweight timing metadata, here) for all build flavours, and report to CDP (more costly full metadata/previews) in dev/profiling builds.
**Notes**
- Introduces `PerformanceEntryReporter::unstable_reportResourceTiming` — this will become "stable" when further network events/fields are fully hydrated on Android and iOS.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D73922341
fbshipit-source-id: bcfc03c3d8a9a286ae72ba00a3313602fb2adea8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51046
This small change improves the cleanup script for ios, which is now not deleting the workspace and that it might be keeping an outdated version of the codegen for OSS.
## Changelog:
[Internal] - Improve yarn clean-ios script
Reviewed By: cortinico
Differential Revision: D73988442
fbshipit-source-id: 6de5d6ab08812ba7fdb19b0cc955a38840d82f89
Summary:
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 a 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/51061
Test Plan:
```sh
yarn android
yarn test-android
```
Reviewed By: rshest
Differential Revision: D74056259
Pulled By: javache
fbshipit-source-id: 04f7ce7ce7b4f6063c8e1712840a44fd91d3b9e1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51073
Currently the SampleLegacyModule screen is not loading in OldArch for RNTester.
That's because we gate adding a `SampleLegacyModule` to the BaseReactPackage
only if NewArch is enabled.
This shouldn't be the case as we can still build RNTester in oldarch and we
should be able to visualize the SampleLegacyModule example.
Changelog:
[Internal] [Changed] -
Reviewed By: mdvacca
Differential Revision: D74009245
fbshipit-source-id: 55eae3dc6063343f57261af2742e643a8e5c2b50
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51050
Gate network event reporting on iOS (inputting into the network reporting subsystem), now that this is load-bearing with the Performance API.
Changelog: [Internal]
Reviewed By: vzaidman
Differential Revision: D73995864
fbshipit-source-id: 65a15485cdae445eadff6c57148f3682af6de215
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50995
Refactors our previous single-struct representation for `PerformanceEntry` ([see MDN](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceEntry)) as a `std::variant`.
This maps closely to the `PerformanceEntry` type inheritance in the web spec, and makes this type substantially cleaner to extend and work with in D73861431.
Changelog: [Internal]
Reviewed By: rubennorte, rshest
Differential Revision: D73860532
fbshipit-source-id: f3b7a7444d2456370620c1a1ba9a43f118cb9730
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51044
This change prevents RN from accessing the MainBundle every time a NativeModule is registered by caching the `legacyLogEnabled` property in a static variable.
## Changelog:
[Internal] - Prevent multiple access to mainBundle
Reviewed By: javache
Differential Revision: D73992070
fbshipit-source-id: a14aada43f367314b7f868a0b5e30b9f92d0971a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51064
This is pretty much just checked in printf debugging. Let's clean it up, before we duplicate some code which has the logs.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D73975310
fbshipit-source-id: d2b936ad62a17aef20903fd2ca0defc23c647aa0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51040
## Resubmit
We were previously only checking for `maxNumberOfLines` of `ReactConstants.UNSET` (-1), but it may also be `0` to signify unset from other checks (wut), and different versions of Android would handle this case of `maxLines={0}` differently.
The resubmission adds an explicit check for zero here as well.
```
if (ReactNativeFeatureFlags.incorporateMaxLinesDuringAndroidLayout()) {
if (maxNumberOfLines != ReactConstants.UNSET && maxNumberOfLines != 0) {
builder.setEllipsize(ellipsizeMode).setMaxLines(maxNumberOfLines);
}
}
```
## Previous
Right now, we fully layout text, then use max lines to determine a metric to use when calculating size.
Android API 23+ which we fully target allows incorporating ellipsization and maxlines directly into the layout. This will let us directly draw the layout when using maxLines later. This may also let Android optimize line-breaking a bit, when we hit truncation.
Special care is taken not to set this when we are in `adjustsFontSizeToFit` path, so that line count will flow over, signifing overflow.
I think the main user-facing change is that `onTextLayout` events will have measures post-ellipsization.
Changelog:
[Android][Changed] - Incorporate maxLines and ellipsization into text layout
Reviewed By: lenaic, joevilches
Differential Revision: D73953691
fbshipit-source-id: 2e08faab5bb9eda90a126545571bb441ea1ece39
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51037
## Changelog:
[Android] [Changed] - Make mHybridData in CxxReactPackage protected
In some cases subclass needs to override it in constructor
Reviewed By: javache
Differential Revision: D73894471
fbshipit-source-id: 7958f9b88841a0201d39e49fba09af76927e5737
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51019
Follows D72228547 and D73770609.
This diff internalises (moves files from fbsource+GitHub to fbsource only) a number of RNTester examples which referenced `'react-native/src/private/'` subpaths.
In future, new components/APIs should be exported from index as `unstable_`, or added to `RNTesterListFbInternal` if they are exported from `src/fb_internal/`.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D73777092
fbshipit-source-id: d9fb0833c56f2ae580b6db62ddbbbeae774a0004
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51043
The call to the mainBundle to read the `RCTLegacyWarningsEnabled` key can sometime deadlock in prod.
However, these are development logs that we don't want to run in Prod.
This change should disable the logs in prod, skipping the access to the `mainBundle`, and avoid the deadlock completely.
## Changelog:
[Internal] - Fix deadlock at startup to read `RCTLegacyWarningsEnabled`
Reviewed By: philIip, javache
Differential Revision: D73987454
fbshipit-source-id: 014410266733fdfa1e7b29d41fab5f7112b1ddb4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50914
The URL spans generated by Linkify are not actually accessible because we do not update the delegate's virtual views.
I also had to change how AccessibilityLinks get generated, since it does not work well if it includes spans that are not `ReactClickableSpans`
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D73612119
fbshipit-source-id: 0c6028a7473e0484216300863f2d7a043fb2ea85
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50887
There is currently a bug with the recent changes to keyboard accessibility with Text and nested links. If something with nested links has a `dataDetectorType` prop then we have 2 different selections when we navigate with arrow keys since the drawing behind the 2 are separate.
Removing LinkMovementMethod is not possible since it allows for clicking the links it detects
As a result, lets just allow it to take precedence over the delegate when handling link navigation in the cases its present.
Changelog: [Android][Fixed] - Double selection with dataDetectorType and links
Reviewed By: NickGerleman
Differential Revision: D73549839
fbshipit-source-id: bbe37470e78841bb119fa68e197b327023031c7e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51029
# Changelog: [Internal]
Instead of exposing vector of samples / call frames directly, we will share pair of iterators that would allow iterating over them in a specified order.
Reviewed By: dannysu
Differential Revision: D73448002
fbshipit-source-id: 16c476453e943a71403b375b168b30da7d261cfa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51028
# Changelog: [Internal]
There is a way to implement the trie without allocating `ProfileTreeNode` on the heap. The serialization logic (`RuntimeSamplingProfilerTraceEventSerializer.cpp`) remained mostly the same, the only new limitation is that we can only use pointer to `ProfileTreeNode` until the next push into a `children` container, when all pointers are invalidated. Not sure if we can avoid this invalidation, since we don't know the potential size of `children` vector, it has to be dynamically allocated.
Main changes are in `ProfileTreeNode`:
- Instead of receving already created instane that will be check if it should be added as a child, it will expose predicate to check if such node already exists - `getIfAlreadyExists`. If not, then caller can use `addChild` to register it and receive a pointer.
Reviewed By: huntie
Differential Revision: D73213284
fbshipit-source-id: 385be884bcc5feb61b3a8cbd0ff36402e3b20c6c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50847
# Changelog: [Internal]
We have different types of call frames, right now we defined 4 of them. Previously, they would descend from `ProfileSampleCallStackFrame`, which has `kind_` field that can be used for determining the type of the call frame.
We were using polymorphism later on React Native side to cast from base type to derived.
Instead of this, and instead of doing heap allocations for potentially tens of thousands of objects, we will use std::variant for storing frames in a single container and them distinguishing them.
This fixes memory leaks caused by new-ing objects and not clearing out when Profile is destroyed.
Reviewed By: dannysu
Differential Revision: D72803934
fbshipit-source-id: a279c6d68c7c2628f0eab585f33137222ad9e3f1
Summary:
The `Object.assign` support is [inherently unsound](https://github.com/facebook/flow/issues/3392), carries a lot of tech debt, and we want to error on them.
This diff pre-suppresses errors that will be added in the next version of Flow, to make the next release easier.
Changelog: [Internal]
Reviewed By: panagosg7
Differential Revision: D73963639
fbshipit-source-id: ebefc82c123588eb0b72ab48a24e45c42be33267
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51035
This is causing some problems with older versions of Android. Let's back out for now.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D73950625
fbshipit-source-id: 424dfc1216ae811e1e287774c6ac5d0c9ba5aa17
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51004
It would be very convenient if `accessibilityOrder` could reference itself. Meaning the View with the `accessibilityOrder` prop can include its own `nativeID` in the array. This makes sense API wise - we allow for referencing parents and their descendants, so long as they are treated as an element and not a container. This is pretty nice since you no longer have to wrap everything in a View who's sole purpose is `accessibilityOrder`.
Under the hood things get a bit garbled, however, since iOS only lets you have UIViews that are either accessibility elements or accessibility containers - and we need to support both at the same time for this to work. To do this, we make use of the `UIAccessibilityElement` class and just forward all of the logic to the View with the `accessibilityOrder` prop. This View will also not be an accessibility element from the point of view of iOS.
Changelog: [Internal]
Reviewed By: jorge-cab
Differential Revision: D73792934
fbshipit-source-id: b0810277c8e410319639b863b59e4e60782bffca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50925
This crashes without this change, now it does not!
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D73626930
fbshipit-source-id: 37fd99372d1781a9e895e854e8b2f75c568ef9c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51027
Simple change to make the host of `experimental_accessibilityOrder` include the view that hosts the property in its order.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D73808337
fbshipit-source-id: 441329a6ca0cd4b0aba08bddb15143215d337e01
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51014
Starting from the [24th of April](https://developer.apple.com/news/upcoming-requirements/?id=02212025a), Apple only accepts app built with Xcode 16.0 or greater
This change bumps our CI to ensure that everything works with Xcode 16.
## Changelog:
[Internal] - Bump CI to Xcode 16.2
Reviewed By: javache
Differential Revision: D73924819
fbshipit-source-id: 82cdca5e12cee505de6e97513c07678776642d88
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51022
As per title, it bumps maestro to 1.40 in CI
## Changelog:
[Internal] - Bump Maestro to 1.40
Reviewed By: cortinico
Differential Revision: D73929936
fbshipit-source-id: 7dfd974a0d1227520c5a6892ff4f157633fdbd54
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51013
There's no need to use a singleton pattern here, we can just use a Kotlin object.
Changelog: [Android][Removed] Deprecated `ResourceDrawableIdHelper.instance`
Reviewed By: Abbondanzo
Differential Revision: D73923281
fbshipit-source-id: f46e125ce595fe4506b9fb5aa471109f5ba150f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50998
I'm reverting this as this change is too disruptive for the OSS ecosystem.
It will break ALL the apps written in Kotlin and it's coming too close to the branch cut which is in less than one week.
We need to re-do this migration in a non breaking manner after the branch cut as this is highly disruptive for little benefit at this point
Changelog
[Android][Changed] - Back out "[RN][Kotlin] Migrate ReactActivity"
Original commit changeset: 936263100ca9
Original Phabricator Diff: D73507044
Reviewed By: mdvacca
Differential Revision: D73864144
fbshipit-source-id: 264921b1f1cd38301e66364de4b619807272bd27
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51006
Moves a bit of code, reading spans that we may not control, to query for `Spanned`, instead of `Spannable`, since some code (see last diff around ellipsization) may wrap intermediate Spannables.
Changelog: [internal]
Reviewed By: joevilches
Differential Revision: D73820368
fbshipit-source-id: e107bcf1f2f7d5555fca68fb2209c12c3f99c099
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51007
Right now, we fully layout text, then use max lines to determine a metric to use when calculating size.
Android API 23+ which we fully target allows incorporating ellipsization and maxlines directly into the layout. This will let us directly draw the layout when using maxLines later. This may also let Android optimize line-breaking a bit, when we hit truncation.
Special care is taken not to set this when we are in `adjustsFontSizeToFit` path, so that line count will flow over, signifing overflow.
I think the main user-facing change is that `onTextLayout` events will have measures post-ellipsization.
Changelog:
[Android][Changed] - Incorporate maxLines and ellipsization into text layout
Reviewed By: joevilches
Differential Revision: D73811573
fbshipit-source-id: df83295d0902ae8b043ce57b06cbb9c8f0c194fc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51005
We need to get a context corresponding to the root being passed, to be able to resolve things like theme to use. RIght now that's a TODO, that's been around since new arch. Let's pass the real data along.
Changelog:
[Android][Fixed] - Correctly Pass SurfaceID to TextLayoutManager
Reviewed By: javache
Differential Revision: D73819640
fbshipit-source-id: 1ae2505b59b8577d35a4dc5bb2a524663f3bd47f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50889
This effectively reverts D67064488
We are trying to smash together functions, variables, virtual or non-virtual, all required by different platforms, into a single header, often using #ifdefs that are not what we want (apart from a bad editor experience, `#ifdef ANDROID` may or may not be compiled into the react-native-cxx platform, and we cannot use it for the Android platform reliably).
For Facsimile, we are going to be introducing more potential divergence, with the idea of `PreparedText`, where we can generate intermediate products as part of the layout process to be reused later. I'm planning to design that in a way which can be eventually reused across platforms, but not everywhere.
I think the best path for this is going to be to allow each platform to have their own headers, instead of the current messiness, then allow shared code (e.g. in `ParagraphShadowNode`) to pick how to interact at compile time. I added an example of this as part of `TextLayoutManagerExtended`, to customize how we act if a `TextLayoutManager` chooses not to implement `measureLines`.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D73557126
fbshipit-source-id: 9851ebba691b0d123f6a355126f2d5b003aceba0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50970
__onAnimatedValueUpdateReceived is called from 2 places.
It is called from the onAnimatedValueUpdate subscription where the source of the values comes from here: https://fburl.com/8v2cwd2x with getValue() returning the offset + value components combined.
It's also called from in the animation end callback here: https://fburl.com/h36xy2nw where the source of this value comes from https://fburl.com/sud7m7st. In this case it's accessing `nodeValue` directly rather than calling getValue() and so it only includes the value component.
In this diff we pass both the value and offset in both onAnimatedValueUpdate callbacks as well as endCallback.
This allows us to separate the value from the offset on the JS side and ensures we have the latest offset value from native
Changelog: [Android][Fixed] - Sync offset and value from native -> js in separate fields
Reviewed By: zeyap
Differential Revision: D73795619
fbshipit-source-id: e8ed234497e3fcaf9d2a137aa1e17ca8d0f76d97
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51000
changelog: [internal]
# Why so many tests?
Differentiator has two modes: regular and reparenting. The reparenting one is almost a completely separate Differentiator, effectively doubling the complexity. It handles quite a few different special cases and is not covered by any reasonable tests, so here I am adding the tests to make sure every branch of the reparenting Differentiator is traversed.
Reviewed By: lenaic
Differential Revision: D73845746
fbshipit-source-id: 27a9fd72a5f8111b84e231cf8f495e278037a323
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50971
This feature flag enables a fix of double measurement on a subset of android components
changelog: [internal] internal
Reviewed By: yungsters
Differential Revision: D73804996
fbshipit-source-id: 3271deb8a8bf4c132cbfb6819f72cab556c6253c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50985
# Changelog: [Internal]
There may be tens of thousands of samples stored, so we should avoid copying it. I don't think we should restrict it from being copied, though, but we don't need it to copy in this case.
Reviewed By: huntie, dannysu
Differential Revision: D73106950
fbshipit-source-id: 45c027ea8bfc3424fe3428f5578d5bed3d1cdda9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50984
# Changelog: [Internal]
We are only using these struct to define how they will be serialize before sending over CDP, no need for custom constructors.
Also updated the naming of the serialization method to align with other parts of the project: `asDynamic()` -> `toDynamic()`.
Reviewed By: huntie
Differential Revision: D73774114
fbshipit-source-id: d0371cf3dee7584daa77054f73aced440550e674
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50988
Changelog: [internal]
This fixes a potential bug where we coalesce unique events with non-unique ones of the same type and target.
Not marked as a bug fix in the changelog because this wouldn't happen in practice, as we always dispatch events of a given type the same way (all unique or all non-unique).
Reviewed By: sammy-SC, javache
Differential Revision: D73849222
fbshipit-source-id: 6f387d63b3a68dccc81c110287d42e15e31c181e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50987
Changelog: [internal]
This adds a new `isUnique` option in `RawEvent` to determine if it's unique (whether it should be coalesced with other unique events of the same type and target).
This effectively makes `dispatchUniqueEvent` redundant, as we can use `dispatchEvent` with a `RawEvent` marked as unique.
This will allow us to fix the bug we found in the new tests for event dispatching, where non-unique events of a given type where being coalesced with non-unique events of the same type.
Reviewed By: javache
Differential Revision: D73849220
fbshipit-source-id: ce89623aee509071ab6a86654ee25d9614863a8a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50989
Changelog: [internal]
Just adding a test suite to verify the behavior of event dispatching in Fabric (especially around event priorities, automatic determination based on ContinuousStart/ContinuousEnd and unique events).
This also surfaced a bug where we incorrectly batch unique and non-unique events together (see the disabled test).
Reviewed By: javache
Differential Revision: D73849218
fbshipit-source-id: 404172822d6985283a161c8a56575e0b5658a5cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50986
Changelog: [internal]
This just exposes some enum values and methods that we forgot to expose in a few interfaces.
Reviewed By: javache
Differential Revision: D73849221
fbshipit-source-id: 19014d53216e67c77b0c31e5ade8f86de071b001
Summary:
This PR aims to migrate ViewGroupManager to kotlin as part of https://github.com/facebook/react-native/issues/50513
## Changelog:
[ANDROID][CHANGED]Migrate ViewGroupManager to kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/50895
Test Plan: Tested with RN tester with old and new arch
Reviewed By: javache
Differential Revision: D73770843
Pulled By: cortinico
fbshipit-source-id: 45959a8bf512b3590ca8bc64dac281e13fa41ca3
Summary:
With the redesign of the new app screen, the E2E tests against the template started failing because we don't have a `Step One` string anymore.
This change should fix them.
## Changelog:
[Internal] - Fix Template E2E tests
Pull Request resolved: https://github.com/facebook/react-native/pull/50990
Test Plan: tested by running the E2E tests on this PR
Reviewed By: huntie
Differential Revision: D73855988
Pulled By: cipolleschi
fbshipit-source-id: d0d72e5a07cd88923e310767eae27f5df376d637
Summary:
As part of the work to integrate libraries with our nightlies, we want to receive a message when the libraries are failing to build on discord. This will help us catch breaking changes early on and onboarding library maintainer as soon as possible.
## Changelog:
[Internal] - Integrate with Discord when nightly fails
Pull Request resolved: https://github.com/facebook/react-native/pull/50979
Test Plan: GHA
Reviewed By: cortinico
Differential Revision: D73845810
Pulled By: cipolleschi
fbshipit-source-id: c6cfdf16b29642b1c3ad3872096c0e815fa88a0a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50992
shouldnt happen but when it does it shouldnt crash some more
fix for P1798860939
Changelog: [Internal] - fix crash when onHostPause is called and mCurrentActivity is null
Reviewed By: cortinico
Differential Revision: D73852655
fbshipit-source-id: 19ee4ada1c71a34a6115882e9a558b4ea9f9d8c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50965
While D72228547 has recently disallowed all `./src/*` subpath imports from React Native (functionally, `./src/private/*`), we have a number of APIs that are imported from Meta product code legitimately — e.g. as part of validating under-development React Native features internally in real Meta apps.
This diff defines a new, exported `./src/fb_internal/*` subpath via `package.json#exports`, which will allow us to expose select entry points for this purpose.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D73770609
fbshipit-source-id: 397019669e565b95a86302ef30f80b65a17dcc0d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50976
This is the second part of the migration of `rn-tester` package to use root imports. In this diff the `CodegenTypes` namespace is used to define Codegen primitives.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D73780584
fbshipit-source-id: c13c2dfcfa4d023978a9463af1d2a3bf7b72476c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50975
Re-defining types in `AnimatedExports.js.flow` shadows their documentation located in `AnimatedImplementation`. Moving them to the `AnimatedExports` fixes the issue for generated TS types.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D73840908
fbshipit-source-id: 2648498a53660b483c70be647716accc11e96d82
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50967
In some cases we may want to check this only if the prop exists
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D73793783
fbshipit-source-id: b498f82414edf63d8644b90bb3932298eb37b43c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50941
Without doing this, using Animated.event to update a value with an offset causes the value to revert to not having an offset because the native side doesn't even know about the offset if it hasn't been synced.
Don't think there's a better place to sync this for the cases where an animation is kicked off entirely from the native side
Changelog: [Android][Fixed] - Ensure latest offset value is synced to native
Reviewed By: javache
Differential Revision: D73622302
fbshipit-source-id: 7e67a7f41d900cc225af410af94ccdfd33c170c8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50850
This prop will be used to enable screen reader focusability without allowing keyboard focus. Mostly a quality of life prop for product engineers and maps 1:1 to Android
Changelog: [Android][Added] - Expose Android's screenReaderFocusable prop
Reviewed By: javache
Differential Revision: D73382051
fbshipit-source-id: 8171b9d24a735dd42d54abe4537fb487bdd011b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50962
OSS is affected by https://github.com/facebook/react-native/issues/49694 and it is endangering the migration of multiple apps to the New Architecture.
We fixed the issue but it is hidden behind feature flag while we are experimenting with it internally, to make sure it does not causes regressions.
However, the fix has been verified for the reproducer code and the OSS will be beneficial for the community.
We are overriding the featureFlag, enabling it for OSS.
## Changelog:
[Internal] - Enable `updateRuntimeShadowNodeReferencesOnCommit` for OSS
Reviewed By: lenaic, cortinico
Differential Revision: D73771648
fbshipit-source-id: 4394a2370d9edd9699c8e03293868defd465853c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50909
Enables and maps the `types_generated/` directory for `react-native` and `react-native/virtualized-lists` — exposing the new Strict TypeScript API entry points to React Native.
**New `"exports"` conditions**
- `"react-native-strict-api"` — The Strict TypeScript API opt in, exposing the `index.d.ts` entry point only.
- `"react-native-strict-api-UNSAFE-ALLOW-SUBPATHS"` — Opts into the new from-source generated types, but allows accessing subpaths (unsafe).
- We intend for this unsafe condition to be an escape hatch for Frameworks only (i.e. Expo).
Note: In the case of `virtualized-lists`, we simply use the `"types"` condition — since this package did not expose any TypeScript API previously.
NOTE: Should we need to roll back JS Stable API phase 1, **this is the single diff to revert**.
Changelog:
[General][Added] - Configure the "react-native-strict-api" opt in for our next-gen TypeScript API
Reviewed By: cipolleschi
Differential Revision: D71969602
fbshipit-source-id: 291182cc826db8b33f21fc79698e6096876d17ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50964
Address/supress ESLint warnings across the codebase, currently flagged on every PR via GitHub's "Unchanged files with check annotations" check.
{F1977480883}
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D73778510
fbshipit-source-id: 91bed86877eae74fa3b9ebea71e26cdcaeee1761
Summary:
Rewrite of the Inspector class from Java to Kotlin in scope of https://github.com/facebook/react-native/issues/50513
## Changelog:
[ANDROID] [CHANGED] - Migrated Inspector to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/50947
Test Plan: Tested using RNTester app, on both old and new arch, and tested by navigating to multiple pages
Reviewed By: cortinico
Differential Revision: D73767386
Pulled By: javache
fbshipit-source-id: e0098568aa0ed9863503e206a88d3b171c8f9966
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50958
In rn-tester package there are many react-native deep imports which will be deprecated in the future. It is a starter for migrating rn-tester to using root imports instead. Only deep imports that are already root exported are changed. This diff avoids using `CodegenTypes` as it causes build errors and will be resolved in next stages.
Besides import changes, `PointerEvent` type is now also exported from the root.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D73656526
fbshipit-source-id: 5814a3d9c6a04b1236581dbbe291cd109e2c71c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50957
Changelog: [internal]
Now we can use the higher level API for event dispatching in this test.
Reviewed By: javache
Differential Revision: D73663626
fbshipit-source-id: 961af26f62128f093c71ad14f457ac8544348415
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50903
For now we do not change the way this module is exported to prevent breaking changes (due to high usage in external packages). It is a tentative mitigation - this case requires more discussion and what could be sufficient. The `no-deep-imports` rule and plugin shouldn't emit a warning when encountered.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D73590627
fbshipit-source-id: 6f85c52373ee6c7c538c632b55cd9e0b9357f2a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50932
Add a warning for LegacyArch users that are providing a ViewManager with a corresponding shadow node that implements the `YogaMeasureFunction`.
For those users, we know that the ViewManager is most likely not working on the NewArch (unless they have a backward compat ViewManager with a C++ shadow node implementation).
Changelog:
[Android] [Added] - Warn Legacy Arch users if they use a Component with a ShadowNode with `YogaMeasureFunction.measure()` function. That Component will stop working on NewArch.
Reviewed By: javache
Differential Revision: D73654273
fbshipit-source-id: 70d232434f94bc2a6970379d566b276f73850fce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50939
Redesigns React Native's `NewAppScreen` component, and moves it into a new `react-native/new-app-screen` package with a single component export. Deletes the old New App Screen under `'react-native/Libraries/NewAppScreen/'`.
{F1977434404}
**Motivation**
- **Reduces our public API** (see https://github.com/react-native-community/discussions-and-proposals/pull/894)
- Separates this screen from the main `react-native` package, where it was a number of subpath exports.
- Reduces the size of the main `react-native` package, including image assets — which are redundant for consumers like Expo.
- **Updated visual treatment**
- Replace outdated logo, update to a responsive tablet/windowed layout.
- Removes outdated guidance (e.g. "use cmd+R to reload"), and generally simplifies the layout (with the aim of reducing future maintenance).
- **Simplifies template boilerplate**
- `NewAppScreen` is now a fully encapsulated screen layout, avoiding the cruft of the previous modular design.
**Integration plan**
When we cut the `0.80-stable` branch, we'll update [the template](https://github.com/react-native-community/template/blob/main/template/App.tsx) to import and use `<NewAppScreen />`.
- This will cause an extra runtime dependency in the template `package.json`, which will require user cleanup. We are happy with this tradeoff, given the self-evident package name, reduction of template boilerplate, and size reduction on the main `react-native` package.
Changelog:
[General][Breaking] - The `NewAppScreen` component is redesigned and moved to the `react-native/new-app-screen` package
Reviewed By: cipolleschi
Differential Revision: D73657878
fbshipit-source-id: 9ca07afa9fbdd6f32015eafa2f27d52ed182918e
Summary:
This PR makes sure that monitor-new-issues runs only in the main repo. It was failing on my fork and spamming notifications.
## Changelog:
[INTERNAL] [FIXED] - run monitor-new-issues only in the main repo
Pull Request resolved: https://github.com/facebook/react-native/pull/50951
Test Plan: CI Green
Reviewed By: cipolleschi
Differential Revision: D73763006
Pulled By: cortinico
fbshipit-source-id: cbb22f8804448b41de970d3d11930110b353994f
Summary:
For real this time, the change was lost due to some merge conflict
Changelog: [Internal]
Reviewed By: Abbondanzo
Differential Revision: D73726167
fbshipit-source-id: 1e0cef75f59a166d795922266365b2b7b060472e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50872
NOTE: Resubmission of D71968187.
Define `"exports"` field on the main `react-native` package.
**Notes**
Module resolution should be equivalent to the previous implicit `"main"` field (backwards compatible).
- Exports all module subpaths to JavaScript (Flow) source files, with and without `.js` suffix (unchanged ✅)
- These are restricted to the `flow/` and `Libraries/` subdirectories (ℹ️ this should be unchanged, matching any JS imports apps may have today)
- Still includes 3P integration scripts such as `./jest-preset.js` and `./rn-get-polyfills.js` (unchanged ✅)
- Exports `./package.json` (unchanged ✅)
- TypeScript should:
- fall back to the `"types"` field (unchanged ✅)
- OR to `"."`,`"./*"` when Package Exports support is enabled via `compilerOptions`, and use the *adjacent `.d.ts` file* (unchanged ✅)
Changelog:
[General][Breaking] - The `react-native` package now defines package.json `"exports"`.
- While these expose existing JavaScript and TypeScript modules, this change may affect deep imports of non-JS files via Node in third party tools.
- Jest mocks to a `react-native` subpath will need to be updated to match the import path used in your code.
- Imports from `src/` and `src/private/` directories are disallowed.
Reviewed By: robhogan
Differential Revision: D72228547
fbshipit-source-id: d50d6e556d32a9cf2f90855a562e61549853acb9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50855
This diff addresses a crash caused by view duplication in React Native Android. The issue occurred when a view was not already clipped and was laid out again, resulting in duplicated views.
This problem was particularly noticeable when using nested FlatLists, which triggered a custom focus search with an incomplete and buggy duplicated FlatList container view.
The fix involves preventing the duplication of views by checking if a view is clipped already before laying it out again. Additionally, this diff includes two other improvements:
- Preventing clipping issues: When a view is nested within a non-ReactClippingViewGroup ancestor, focus searching would fail due to the needUpdateClippingRecursive logic only running on instances of ReactClippingViewGroup. By excluding these ancestors, we ensure that the next focusable view can be properly excluded from being clipped.
- Minor fix: A minor fix was made to prevent potential issues in deeply nested cases.
- Add a Kill switch with a feature flag and mobile config combo.
Reviewed By: joevilches
Differential Revision: D73471780
fbshipit-source-id: efbb968600f21b24ab1fa32222d555f346fb336e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50936
D63141469 introduced an option to use HSR Core's trace macros for profiling react. I believe this was to enable Tracy support. However, the consequence of this is that hsr core is statically linked twice into Worlds, once in libclient_server_android.so and once into libxplat_js_react-native-github_packages_react-native_ReactCxxPlatform_react_profiling_profiling.so.
It isn't obvious that this causes any problems, but it does result in some weirdness with regard to symbol interposition between the two shared libraries. Some tracing categories are registered twice in hz_tracing, for example.
Since the HSR Core macros call directly through to hz_tracing, this change simply replaces the HSR Core dependency with an equivalent hz_tracing dependency.
Reviewed By: javache
Differential Revision: D73532803
fbshipit-source-id: 56d4b62873aabcbf0a92cebd7a0f720fed616158
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50908
This diff removes the usages of ShadowNodes in the new architecture by fully releasing disableShadowNodeOnNewArchitectureAndroid() feature flag.
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D73519567
fbshipit-source-id: e222e3b4fab371c8bc5480950da005d2a12a8619
Summary:
We landed a PR that was importing a file available only in the New Architecture also when the app was running in the old architecture.
This was creating a corrupted bundle for rntester.
This PR fixes the issue
bypass-github-export-checks
## Changelog:
[Internal] - Fix RNTester on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/50940
Test Plan: Tested locally by setting `newArchEnabled` to false in the gradle.properties file
Reviewed By: javache, cortinico
Differential Revision: D73663049
Pulled By: cipolleschi
fbshipit-source-id: c8d6e4190adee7388e51901360a811b0007ee3a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50938
Changelog: [internal]
No more `maybeNode`s. Using ref objects makes the tests cleaner and the JSX easier to read than injecting lambdas.
This speaks for itself:
* 617 lines added
* 1393 lines removed
{F1977434870}
Reviewed By: lenaic
Differential Revision: D73659018
fbshipit-source-id: d1c23e6457bb1d351ce02b9f6fa8778b06ee0e55
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50935
Those classes are internal and deprecated since a while.
It should now be safe to fully remove them.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D73655877
fbshipit-source-id: cdca8f032fe865f9a08c40e4a0145945c7e25a85
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50931
This removes all the `OSS_LEGACY_WARNINGS_ENABLED` infrastructure from LegacyArchitectureLogger. We'll instead pivot to use ad-hoc functions for scenarios that don't work in LegacyArch + Interop Layers (see D73654273).
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D73654272
fbshipit-source-id: d10eac2ded92f2c0191503e64f0c1d9db688d6e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50930
Due to D73591315, we don't need to specify the `legacyWarningsEnabled` for RNTester anymore as it's effectively ignored.
Changelog:
[Internal] [Changed] -
Reviewed By: rshest, cipolleschi
Differential Revision: D73654270
fbshipit-source-id: 9428634fb8374024940e4041de60d679b6f352a2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50929
We decided to change the warning model for LegacyArch/NewArch.
I'm currently removing the infra to read the `legacyWarningsEnabled` Gradle property if provided.
Warnings will be enabled by default for all Legacy Arch users in the new model.
This change was never shipped in a numbered version, so that's not breaking.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D73591315
fbshipit-source-id: a46fade91b46fcc9b81984577161c046dc0939b6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50928
This broke in D72979663, since we relied on the object identify of `native` changing to correctly reset the native state back to the controlled JS state.
Changelog: [General][Fixed] Fixed switches correctly reverting to controlled state
Reviewed By: vzaidman
Differential Revision: D73653323
fbshipit-source-id: d6ca8a31d9f08a339c7acf6bba264137690dd794
Summary:
Rewrite of JSBundleLoader from Java to Kotlin in scope of https://github.com/facebook/react-native/issues/50513
## Changelog:
[ANDROID] [CHANGED] - Migrated JSBundleLoader to Kotlin
<!-- 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/50911
Test Plan: Tested using RNTester app, on both old and new arch, and tested by navigating to multiple pages
Reviewed By: cortinico
Differential Revision: D73649145
Pulled By: javache
fbshipit-source-id: 7ef1fc1ea1c53a8b914ae1aada1966e64b4c3d80
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50899
changelog: [internal]
making things clearer in the docs for Fantom.
Reviewed By: rubennorte
Differential Revision: D73580305
fbshipit-source-id: 0e5edaa3baf57fc54f7a0c454fe4d2fa81627f66
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50906
Annotation to mark classes or functions that are part of the interop APIs that provide support for legacy architecture APIs in the new architecture of React Native .
changelog: [internal] internal
Reviewed By: shwanton
Differential Revision: D73407613
fbshipit-source-id: 887a14ca4dea891b50e7df01e0ffff5064cd43ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50888
This is shared between platforms using a very strange pattern. Let's just extract this into its own function. Not considering breaking, since TextLayoutManager is internal interface.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D73555465
fbshipit-source-id: ea99fbebd9db44efd1dc56c2cad68b5b56e77ad1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50890
With Facsimile, we are introducing some new concept of `PreparedText`, where platform TextLayoutManager which implement, can lead to additional optimizations.
`#ifdef ANDROID` is not a workable pattern for this. Apart from react-native-cxx getting hooked into it, and all of the existing bugs there, it is bad for editor environment, and hard to reason about.
This splits up `ParagraphState`, so that we can control platform specific bits more easily. We do not split `ParagraphShadowNode`, which will use concepts (e.g. `TextLayoutManagerWithPreparedText`) to control which paths it takes, based on platform capaibilities.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D73555441
fbshipit-source-id: fd585eb99d26b0b6966efb1867d03fbd5cc7e7e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50923
This implements the view manager for `PreparedLayoutTextView`, originating by taking the view managers composing `ReactTextView`, converting to Kotlin, and removing everything no longer needed.
In Facsimile, anything influencing text appearance is applied earlier, when creating the Fabric layout, so there are many less setters here. Most visual attributes are instead present in the state we are presenting.
We have tasks for some of these, that need to be reimplemented, as they do not currently influence the Spannable being measured. That includes e.g. `ReactTextViewManagerCallback`, used for injection, and `dataDetectorType` for linkifying Spannable.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D73287706
fbshipit-source-id: 938b57d4e443f6b8bb127e17b47cc371f31a416d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50922
This forms the basis for a replacement of `TextView`.
This started off with Litho's [`RCTextView`](https://github.com/facebook/litho/blob/master/litho-rendercore-text/src/main/java/com/facebook/rendercore/text/RCTextView.java), which is a simple view, for rendering a text layout, and providing some built-in keyboard navigation and a11y support. Many changes were made to it, including:
1. Removing many parts not relevant to RN, or which will be replaced by other RN infra. E.g. we will reuse existing a11y delegates, have existing ways of creating Spannables and text layouts, inline views, etc
2. Converting to Kotlin
3. Adding back in some changes required for RN's drawing, and expected view manager APIs (e.g. overflow/clipping customization)
4. Making it target a ViewGroup instead of a View, for correct inline view support down the line
Because we rely on drawing text layout, with the same Spannable as before, most things "just work", because they are part of the layout we are drawing, generated by TextLayoutManager on the Fabric side. We don't offer much customization to what can be drawn, forcing it to have happened in the layout we are showing already.
There are quite a few bits not implemented yet. Some of these are cases, like `textAlignVertical`, were previously incorrectly implemented just at the ReactTextView layer, so Fabric layout was unaware of them. Another similar class to this is any non-default fonts which we must load. `adjustsFontSizeToFit` (stubbed out in later diff) will also need some tweaking with the new assumption we don’t want to mutate Spans/layouts set in State.
Fine grained selection support is the largest tbd.
Changelog: [Internal]
Reviewed By: Abbondanzo
Differential Revision: D73282649
fbshipit-source-id: abe3a30461095d2d0ddbc6c939704f3982f44771
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50921
This adds the ability to represent Fabric State sent to Java View managers as a raw JNI reference. This is used by Facsimile to tell a component to mount a layout, previously generated during measurement.
This API is consciously well hidden (in comparison to MapBuffer which is fairly public). To use it:
1. The concrete state data representation must implement a method named `getJNIReference()` that returns an fbjni ref
2. The Java view manager must cast the `StateWrapper` to an internal `ReferenceStateWrapper` type, not exposed outside of React Native internals
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D73159146
fbshipit-source-id: b7602bf7717bff28d2f3b259073bc47606fd76e4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50920
We construct this from JNI, which doesn't care about visibility, and then only want to expose `StateWrapper` as the public interface.
Changelog:
[Android][Removed] - Make StateWrapperImpl Internal
Reviewed By: Abbondanzo
Differential Revision: D73161592
fbshipit-source-id: b787e31e190dc52a02d73cadfa77b1c1defb9703
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50912
Changelog: [Internal] - Update IntersectionObserver Fantom tests to use the new `scrollTo` api which didn't exist when I first wrote these tests. As well, do clean up between tests
Reviewed By: rubennorte
Differential Revision: D73551695
fbshipit-source-id: 9625328879230d178f23a089436f2a3c7b8323bd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50905
Subtle compiler differences cause this to fail, but we can just `Class<*>` here instead.
Changelog: [Internal]
Reviewed By: cortinico, rshest
Differential Revision: D73593304
fbshipit-source-id: ea3996fc0641ae5d12a6923bd78645e21232afe7
Summary:
Resolves https://github.com/facebook/react-native/issues/50778
### Problem Description
Implement the crossOrigin property for Image in RNW Fabric when only source.uri is passed and not src/ srcSet.
For reference, check the public API documentation: https://reactnative.dev/docs/image#crossorigin
Implement the referrerPolicy property for Image in RNW Fabric when only source.uri is passed and not src/ srcSet.
For reference, check the public API documentation: https://reactnative.dev/docs/image#referrerpolicy
Also refer docs for source, src, srcSet
https://reactnative.dev/docs/image#sourcehttps://reactnative.dev/docs/image#srchttps://reactnative.dev/docs/image#srcset
It's not mentioned in the doc that when src / srcSet is missing then crossOrigin / referralPolicy would be ignored when source uri is a remote URL that is passed.
Currently these were ignored if src / srcSet was not passed and not added to sources headers.
This change adds headers support even without passing src / srcSet and only sources uri that consists of remote URL.
crossOrigin and referrerPolicy are passed as source.headers here:

### Steps to reproduce
```
<Image
defaultSource={{uri: this.state.defaultImageUri}}
source={{uri: this.state.imageUri}}
crossOrigin="use-credentials"
referrerPolicy="no-referrer"
/>
```
Pass this in React Native and check source headers
## Changelog:
[GENERAL] [ADDED] - Support headers [crossOrigin and referralPolicy] in Image without src and srcSet and only remote source.uri
Pull Request resolved: https://github.com/facebook/react-native/pull/50799
Test Plan:
Refer this PR for testing; https://github.com/microsoft/react-native-windows/pull/14521
## Screenshots
_Add any relevant screen captures here from before or after your changes._
Before

After
<img width="790" alt="image" src="https://github.com/user-attachments/assets/8e0a2522-7009-430d-b848-da80896670f4" />
## Testing
_If you added tests that prove your changes are effective or that your feature works, add a few sentences here detailing the added test scenarios._
Tested in playground and RNW Tester and Visual Studio Debugger
_Optional_: Describe the tests that you ran locally to verify your changes.
1. Tested with only source remote uri passed
2. Tested with both source, src
3. Tested with source, src, srcSet
Reviewed By: javache
Differential Revision: D73427747
Pulled By: cipolleschi
fbshipit-source-id: f09174d1e4eaa2173b27970a6079eeb8ba6f3069
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50900
This bumps the minor of Android Gradle Plugin ahead of the branch cut for 0.80
Changelog:
[Android] [Changed] - AGP to 8.9.2
Reviewed By: rshest
Differential Revision: D73579447
fbshipit-source-id: f0d40ba3d160e332ee9ab2853a949ed6ec51a3fc
Summary:
Right now having a javascript error like an invalid import statement during first bundle load results in a disappearing redbox screen.
https://github.com/user-attachments/assets/ab9c64f5-6e32-481c-a58f-6d37bb920acb
The `invalidate` call removed in this PR cleans up all turbomodules, including the RedBox module, which in turns calls `dismiss` in `RCTRedBox`.
After removing this line the result is as following:
https://github.com/user-attachments/assets/6eeb4d43-f883-440f-ade3-5628f85f833a
I made sure that the `invalidate` function is still called when executing only two possible ways to reload the bundle:
- the Reload button
- Cmd+R
The HMR/hot reload is not connected if the bundle has an error on initial load, so we don't need to worry about it.
Longer term, it would be better to establish HMR and use a different redbox in this case:

Doing this requires larger changes to the bundle loading flow – happy to to try and land that change if there's any guidance you could give.
## 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] – Fix disappearing redbox on initial load of an invalid bundle.
Pull Request resolved: https://github.com/facebook/react-native/pull/50867
Test Plan: I have tested this change using RN from main and RNTester app (see videos).
Reviewed By: cortinico
Differential Revision: D73511154
Pulled By: cipolleschi
fbshipit-source-id: dfe149ebc15d845f07fd3926db2e063b468870af
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50802
The plugin analyses the source of all `import`, `require`, and `export` statements and injects the `console.warn` statement for each path targeting deep react-native source code. It runs only on a dev mode so there is no need to keep that in the `if (__DEV__) ` block. It is possible to disable this plugin by setting `disableDeepImportWarnings: true` and **resetting** the Metro cache:
```js
module.exports = {
presets: [['module:react-native/babel-preset', {
"disableDeepImportWarnings": true
}]],
};
```
Changelog:
[General][Internal] - Added plugin to react-native/babel-preset injecting `console.warn` for each react native deep import in dev mode.
For a given code:
```js
import { Image } from 'react-native';
import View from 'react-native/Libraries/Components/View/View';
const Text = require('react-native/Libraries/Text/Text');
export { PressabilityDebugView } from 'react-native/Libraries/Pressability/PressabilityDebug';
```
The transformed output should look like:
```js
import { Image } from 'react-native';
import View from 'react-native/Libraries/Components/View/View';
const Text = require('react-native/Libraries/Text/Text');
export { PressabilityDebugView } from 'react-native/Libraries/Pressability/PressabilityDebug';
console.warn("Deep imports from the 'react-native' package are deprecated ('react-native/Libraries/Components/View/View').");
console.warn("Deep imports from the 'react-native' package are deprecated ('react-native/Libraries/Text/Text').");
console.warn("Deep imports from the 'react-native' package are deprecated ('react-native/Libraries/Pressability/PressabilityDebug').");
```
For more information about why this plugin was needed, please check [RFC](https://github.com/react-native-community/discussions-and-proposals/pull/894).
Reviewed By: huntie
Differential Revision: D70783145
fbshipit-source-id: ae145db6471d861099566a8faf2fbd93bd136450
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50894
changelog: [internal]
adding more tests to cover all branches of `calculateShadowViewMutationsFlattener`.
calculateShadowViewMutationsFlattener is over 400 lines of code and covers quite a few edge cases. I plan to cover every branch with a test to make it easier to refactor Differentiator in the future.
Reviewed By: rubennorte
Differential Revision: D73543444
fbshipit-source-id: b0b22aba4b9cc4718edd2a6c4535993be437ed9f
Summary:
As the repository is moving towards Kotlin and the tests have also been moving towards mockito-kotlin, I'm doing another round here.
## Changelog:
[INTERNAL] - Flip mockito usages to mockito-kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/50878
Test Plan:
```sh
yarn test-android
```
Reviewed By: javache
Differential Revision: D73569293
Pulled By: rshest
fbshipit-source-id: 9bfe7d3f69480367384eafdde429db15eb81d11c
Summary:
Rewrite of JavaModuleWrapper from Java to Kotlin in scope of https://github.com/facebook/react-native/issues/50513
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [CHANGED] - Migrated JavaModuleWrapper to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/50882
Test Plan:
Test RNTester using old arch. SampleLegacyModule is the one I've used, it needs to be enabled for old arch though (RNTesterApplication.kt -> getPackages & getReactModuleInfoProvider).
I may enable SampleLegacyModule for old arch to make testing easier. mateoguzmana
It breaks on `getDynamic` on old arch, but I could filter these from examples or add some fallback in SampleLegacyModule.kt for old arch.
Reviewed By: cortinico
Differential Revision: D73576099
Pulled By: javache
fbshipit-source-id: c940be27133258fa589571a600435fa478e6b51e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50863
No need for `shouldReturnInteropModule` if we can just use the nullability of what's returned by `getInteropModule` instead.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D73501845
fbshipit-source-id: 9b7628707edc3eb288733baffaca59a9d3c40b40
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50870
As explained in the doc block, now that ReactInstance is in Kotlin we can move this logic to StackTraceHelper and migrate it to Kotlin
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D73503879
fbshipit-source-id: 38a9ff346e00d68bbc3c383834e2a1763dbba9b8
Summary:
While upgrading a project to React 19, I noticed React.ElementRef is deprecated (see [types/react/index.d.ts#L199](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react/index.d.ts#L199)). I think we can replace it for the RN types as well.
Not sure if this is considered as a breaking change.
## Changelog:
[GENERAL] [CHANGED] - TypeScript: Replace deprecated React.ElementRef usages to React.ComponentRef
Pull Request resolved: https://github.com/facebook/react-native/pull/50883
Test Plan:
Create a RNTesterPlayground.tsx next to the normal .js just to validate the type checking is not throwing an unexpected error.
<details>
<summary>Code snippet:</summary>
```tsx
import React, { useRef, useEffect } from 'react';
import { FlatList, Text, View } from 'react-native';
type Item = { id: string; title: string };
const data: Item[] = Array.from({ length: 10 }, (_, i) => ({
id: i.toString(),
title: `Item ${i + 1}`,
}));
const FlatListScrollRefExample: React.FC = () => {
const flatListRef = useRef<FlatList<Item>>(null);
useEffect(() => {
if (flatListRef.current) {
const nativeRef = flatListRef.current.getNativeScrollRef();
console.log('nativeRef', nativeRef?.componentWillUnmount);
}
}, []);
return (
<FlatList
ref={flatListRef}
data={data}
keyExtractor={(item) => item.id}
renderItem={({ item }) => (
<View style={{ padding: 16 }}>
<Text>{item.title}</Text>
</View>
)}
/>
);
};
export default FlatListScrollRefExample;
```
</details>
Reviewed By: cipolleschi
Differential Revision: D73569274
Pulled By: rshest
fbshipit-source-id: f72477b9b3c0eda1007187c7dac3da0433410e86
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50886
changelog: [internal]
Group tests related to reparenting in "describe" block. Differentiator is two algorithms hidden behind a single interface: regular and reparenting. The tests are structured this way as well where regular tests focus on common scenarios and reparenting section focuses on reparenting and special cases around that. The reparenting implementation is considerably more complex as it handles edge cases that don't happen often.
Reviewed By: mdvacca
Differential Revision: D73541053
fbshipit-source-id: c3905a0f0117cb1aa6c468e24e6bb982de48545d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50885
changelog: [internal]
a special case inside of Differentiator handling parent-child switching from unflattened-flattened to flattened-unflattened. If a child has view that is culled, this needs to be handled.
This diff also simplifies the implementation inside of calculateShadowViewMutationsFlattener by passing only one cullingContext.
Reviewed By: mdvacca
Differential Revision: D73523523
fbshipit-source-id: d6f314da6b9ff40bcf3362243b03de1b39e7aabb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50881
Rename Codegen Component Descriptors Entrypoint for FAC and hook it up in DefaultComponentsRegistry
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D73535745
fbshipit-source-id: dad68e7e6c8d7ba2ed86bbd1c06131101e00689e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50851
## Changelog:
[General] [Added] - Add pan gesture animation example to rntester
Including examples of
* using native driven Animated.event + touch event (which will not be interrupted by busy js thread, and is potentially a boost to performance) - the code requires some hacks but it's doable
* using js PanResponder to drive pan gesture animation
Reviewed By: sammy-SC
Differential Revision: D68909931
fbshipit-source-id: 484ecb0646fb249b31362013725219a1c1ec6181
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50879
The view for a view manager should not be nullable. Let's fix that.
These are also all bound specifically to `ReactTextView` instead of the generic constraint, so I just changed the constraint. Really this should just be totally merged with `ReactTextViewManager`.
Changelog: [Internal]
Reviewed By: cortinico, rshest
Differential Revision: D73453631
fbshipit-source-id: 74bcadeef0e83a719dfe2b989784501575b58168
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50753
Runtime Shadow Node Reference Updates (RSNRU) is currently implemented through the clone method which on each internal clone updates the runtime reference to point to the new clone. This guarantees that the runtime reference always points at the latest revision of the shadow node.
This came with the constraint that RSNRU could only run from one thread at all times, otherwise the React renderer state (current fiber tree) would end up being corrupted by receiving reference updates from multiple threads cloning shadow nodes.
This change moves the reference update step to the locked scope of the commit phase. Since the runtime is blocking on the commit and the scope is locked, it is safe and correct to update the runtime references with the latest revision of the shadow node after running state progression and layout.
By moving the reference update to the commit, we can support shadow node syncing from any thread since the actual runtime references are now executing at a safe time and the renderer state will stay valid at all times.
This change is gated behind the `updateRuntimeShadowNodeReferencesOnCommit` feature flag, which enabled shadow node syncing from any thread and reference updates only during the commit.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D73038439
fbshipit-source-id: d90308498f3c0625dc87158f15311d1088aad8b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50752
Storing the runtime reference for a shadow node and updating the runtime reference to point at a specific shadow node should be separated so that these actions can be done at different moments in time.
We want to keep a reference to the runtime reference of a shadow node for all revisions cloned internally (not triggered by the React renderer, e.g. on layout or shadow node state updates).
We also want to support updating that runtime reference to point at a specific shadow node revision, ideally the one that will end up being used to mount the host component.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D73038438
fbshipit-source-id: 68c3912cbb077d790dd8d2abe8291548b12c8231
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50877
At some point I made some changes to how alpha works on BackgroundDrawable. This inadvertently broke BackgroundImage because we need a non transparent color to apply shaders.
Setting the alpha to 255 temporarily when drawing background-image layers fixes it
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D73520952
fbshipit-source-id: b8017bb06adc0d3d328d9831fbc4c74f2ec0b783
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50876
This diff is temporarily reverting the code shipped in D72671083 to wait for more data before fully release this change
changelog: [internal] internal
Reviewed By: rshest, arushikesarwani94
Differential Revision: D73515903
fbshipit-source-id: 6566e9533ebffc93348e24eb6c0512020b220eae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50533
Builds upon https://github.com/facebook/react-native/pull/49446
On iOS, by default, every EditText accepts DragEvent and will automatically focus themselves to accept these data. In some rare cases, it might not be desirable to allow data from arbitrary drag and drop events to be pasted into a text input.
This change adds a new prop `acceptDragAndDropTypes` to do exactly that: reject drag and drop events by telling the system to ignore certain types of drag data and, by proxy, disabling behavior that automatically focuses the text input.
The prop accepts a list of [Uniform Type Identifiers](https://developer.apple.com/documentation/uniformtypeidentifiers) that iOS supports. It's important to note that these are *not* MIME types. A MIME type would be something like `text/plain` but the equivalent for iOS is `public.plain-text`.
It's important to note that this is an experimental prop, as is evident by the `experimental_` prefix on the JS side. Its signature could change before the prop has fully matured, use at your own risk
Changelog: [iOS][Added] - Add new prop for filtering drag and drop targeting to text inputs
Reviewed By: javache
Differential Revision: D70992749
fbshipit-source-id: 22b5aa1b4ced14147bf16a844361acf6f99c5a40
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49446
On Android, by default, every EditText accepts `DragEvent` and will automatically focus themselves to accept these data. In some rare cases, it might not be desirable to allow data from arbitrary drag and drop events to be pasted into a text input.
This change adds a new prop `acceptDragAndDropTypes` to do exactly that: reject drag and drop events by telling the system to ignore certain types of drag data and, by proxy, disabling behavior that automatically focuses the text input.
The prop accepts a subset of MIME types supported by Android as documented [here](https://developer.android.com/reference/android/content/ClipDescription#MIMETYPE_TEXT_HTML).
It's important to note that this is an experimental prop, as is evident by the `experimental_` prefix on the JS side. Its signature could change before the prop has fully matured, use at your own risk
Changelog: [Android][Added] - Add new prop for filtering drag and drop targeting to text inputs
Reviewed By: javache
Differential Revision: D69674225
fbshipit-source-id: 4dbbdd81bb0f394b6206da5a377c75ea71671626
Summary:
Some libraries still use the `folly_flags` method provided by our infra. When updating how folly should be installed in an app, we removed that function.
We are putting it back as deprecated, to avoid unnecessary breaking changes in libraries
## Changelog:
[iOS][Fixed] - Put back the `folly_compiler_flag` function to make libraries install pods
Pull Request resolved: https://github.com/facebook/react-native/pull/50875
Test Plan: Tested locally in a nightly app, using the react-native-exit-app library which still uses these flags
Reviewed By: cortinico
Differential Revision: D73512830
Pulled By: cipolleschi
fbshipit-source-id: 28f099064e93ecd5a5a6a7b82e3f7e9db4d35cb9
Summary:
`SocketRocket` and `fmt` are part of React Native dependencies.
If a library is written in swift and depends on them, it will fail to install the pods because these pods are not compatible with Swift.
This change makes sure that the pods are installed in a way that is swift compatible.
## Changelog:
[iOS][Fixed] - Make fmt and SocketRocket Swift friendly
Pull Request resolved: https://github.com/facebook/react-native/pull/50874
Test Plan:
Tested locally in a nightly app.
### Before the change:
```
yarn add react-native-video
cd ios
bundle exec pod install
```
This script resulted in this error:
```
[!] The following Swift pods cannot yet be integrated as static libraries:
The Swift pod `react-native-video` depends upon `fmt` and `SocketRocket`, which do 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.
```
### After the change
```
yarn add react-native-video
cd ios
bundle exec pod install
```
This script installed pods successfully.
Reviewed By: cortinico
Differential Revision: D73512109
Pulled By: cipolleschi
fbshipit-source-id: 222d85dba1cbdf4044e3c8459008a4083a720016
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50846
## Motivation
After a more rigorous search through GitHub uses of the restricted APIs, and consultation with framework authors, it became apparent that this restriction should be lifted.
Changelog: [Internal]
Reviewed By: zeyap
Differential Revision: D73267844
fbshipit-source-id: e6c0c146690c07debf74c51f82171a9239be5c15
Summary:
the `react-native-maps` library has a complex setup for iOS. It doesn't work with autolinking, therefore we need to disable the test with the nightlies
## Changelog:
[Internal] - Disable nitghtly test for react-native-maps
Pull Request resolved: https://github.com/facebook/react-native/pull/50873
Test Plan: GHA
Reviewed By: cortinico
Differential Revision: D73510995
Pulled By: cipolleschi
fbshipit-source-id: a8abadfc8f0656de1288aa28e65abeab07bb9074
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50852
changelog: [internal]
Adding a test to verify view culling in scenario where a subtree is revealed and part of it is culled.
Reviewed By: lenaic
Differential Revision: D73454202
fbshipit-source-id: 6c4fb2ec4757b9ed1460bec8d3f02a661470266f
Summary:
Fixes https://github.com/facebook/react-native/issues/50010
On the initial render of a Text with the `selectable` prop set as `true`, the Text view is not making itself selectable. I debugged this quite a lot, and by changing the state from false to true using `setState` on the JS side, I made it work.
It turns out that we are setting this property in `onAttachedToWindow`, but somehow if `super.setTextIsSelectable` was already set as `true`, it won't re-apply it and we have to reset it to false before setting it again to true. This PR adds this reset.
I couldn't understand yet why this is not breaking in Fabric.
## Changelog:
[ANDROID] [FIXED] - Fix `selectable` prop not working correctly on initial render (old-arch)
Pull Request resolved: https://github.com/facebook/react-native/pull/50822
Test Plan:
- Test in both Fabric and Paper architectures to ensure there won't be a regression with this change in Fabric, as the issue occurs only in Paper.
- To test this, I created a small example in the RN-Tester playground to toggle the selectable property on/off. Notice in the first video that initially the prop is set as true, but it won't allow selecting. If you toggle to false and then back to true again, it works. With the provider fix it should also allow selecting the text on initial render.
Use this code snippet:
```tsx
function Playground() {
const [selectable, setSelectable] = React.useState(true);
return (
<View style={styles.container}>
<Text selectable={selectable} selectionColor="blue">
TESTING: is selectable? {selectable ? 'true' : 'false'}
</Text>
<Button title="Press me" onPress={() => setSelectable(!selectable)} />
</View>
);
}
```
Videos:
<details>
<summary>Before</summary>
https://github.com/user-attachments/assets/6a24dd0d-7f45-4a38-b18d-5142801ea1c3
</details>
<details>
<summary>After</summary>
https://github.com/user-attachments/assets/ce5f9e6e-9a4c-44d7-9d97-f607f2fdc1b4
</details>
Reviewed By: cortinico
Differential Revision: D73421487
Pulled By: rshest
fbshipit-source-id: c0b9d76076ef2e05930996953015fb58ad2a3d5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50858
changelog: [internal]
This test verifies that React commits can override values previously set by `setNativeProps`. The test demonstrates the proper reconciliation behaviour between imperative updates via `setNativeProps` and declarative updates via React renders.
Reviewed By: lenaic
Differential Revision: D73463364
fbshipit-source-id: 3504d9a23bfc36a46fdfc4e9bf585f64088ab518
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50849
changelog: [internal]
Previously we didn't have a way to properly test bug reported in https://github.com/facebook/react-native/issues/47476. But with Fantom we do! Let's write a test for it to make sure this is not broken in the future.
Reviewed By: rubennorte
Differential Revision: D73432279
fbshipit-source-id: dbc1ce9d7b34bbe4275f6b8b1ce3a1c48bca3504
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50854
changelog: [internal]
In D73437449 I accidentally introduced a deadlock for single threaded testing environments. Here, I resolve the flakiness and the deadlock.
Reviewed By: mdvacca
Differential Revision: D73457182
fbshipit-source-id: 242edd4443b354cda4b082c2d45d8df04033cfd0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50827
This diff addresses a crash caused by view duplication in React Native Android. The issue occurred when a view was not already clipped and was laid out again, resulting in duplicated views.
This problem was particularly noticeable when using nested FlatLists, which triggered a custom focus search with an incomplete and buggy duplicated FlatList container view.
The fix involves preventing the duplication of views by checking if a view is clipped already before laying it out again. Additionally, this diff includes two other improvements:
- Preventing clipping issues: When a view is nested within a non-ReactClippingViewGroup ancestor, focus searching would fail due to the needUpdateClippingRecursive logic only running on instances of ReactClippingViewGroup. By excluding these ancestors, we ensure that the next focusable view can be properly excluded from being clipped.
- Minor fix: A minor fix was made to prevent potential issues in deeply nested cases.
- Add a Kill switch with a feature flag and mobile config combo. For Facebook we can kill through MC and for all other apps we can kill with the feature flag default value
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D73213775
fbshipit-source-id: 51a667a0c22eb35f0ec46ac4cbe430e2e62b407b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50826
Pull Request resolved: https://github.com/facebook/react-native/pull/50105
Pull Request resolved: https://github.com/facebook/react-native/pull/49543
When using `ReactScrollView` or `ReactHorizontalScrollView` Views with `removeClippedSubviews` keyboard navigation didn't work.
This is because keyboard navigation relies on Android's View hierarchy to find the next focusable element. With `removeClippedSubviews` the next View might've been removed from the hierarchy.
With this change we delegate the job of figuring out the next focusable element to the Shadow Tree, which will always contain layout information of the next element of the ScrollView.
We then prevent the clipping of the topmost parent of the next focusable view to lay out the entire containing element in case we have some necessary context in the parent
Changelog: [Android][Fixed] - Fix keyboard navigation on lists with `removeClippedSubviews` enabled
Reviewed By: NickGerleman
Differential Revision: D73114782
fbshipit-source-id: 081a2216037e033a4638151e5226f430ac093ea5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50825
Pull Request resolved: https://github.com/facebook/react-native/pull/50404
Add another function to fabric to get the topmost stacking context parent given a root and a child.
This is to be used on focus searching algorithm in the case where the next focusable child is deeper in the hierarchy meaning we need to find the top most parent in the Android hierarchy and lay that out as well before transferring focus.
If we don't lay out the parent as well as the next focusable view:
- The next focusable view might lack context given by the parent
- If the parent is a scrollview and has removeClippedSubviews enabled then laying out the next focusable view will not work
- If the view is deeper in the android hierarchy in some cases it won't be layed out unless the parent is
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D73114933
fbshipit-source-id: 081720199943eff78966982a5fd1c921d4e105fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50824
Pull Request resolved: https://github.com/facebook/react-native/pull/50196
Currently when `removeClippedSubviews` is enabled on Android keyboard navigation breaks and we can never focus the elements that are clipped. iOS has a similar issue but not as drastic, it only happens when elements on the FlatList have a lot of margin between them.
This algorithm aims to find the next focusable view and return it to native so that we can prevent the clipping of the view on the view clipping algorithm and hence fix keyboard navigation. For more information see D71324219
Fabric algorithm to find the next focusable view given:
`parentTag`: Top most relevant parent of the focused view
`focusedTag`: Tag of the currently focused view
`direction`: Direction in which focus is moving
EDIT AFTER AMA SEV 3 S510469:
This whole algorithm was based on the idea of fixing focusing within a ScrollView. What we didn't consider is that focus search could be triggered when focusing a pop-up view. This includes transfering focus to an element on a new page or a modal which means that in some cases the parent view could be removed from the hierarchy.
Just add null checks to the parent node and the currently focused node to prevent unexpected crashes.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D73115104
fbshipit-source-id: b9c9314fbd4b97da23c0b941d34f4dc2a1a3b883
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50823
Introduce a trait to be able to tell if a ShadowNode is focusable by keyboard. This will be used for focus ordering that delegates the work to the shadow tree when Native platforms don't have enough information to define the next focusable node
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D73114986
fbshipit-source-id: eed8642db0c65b6f54808d681640bb605cb6e0aa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50845
changelog: [internal]
`signalTaskToSync` should be released after `executeNowOnTheSameThread` is called to prevent race condition between `executeNowOnTheSameThread` and reading stubQueue's size on line 723.
Reviewed By: rubennorte, rshest
Differential Revision: D73437449
fbshipit-source-id: 3b2af3ddee5a422f7f846cc34ebbb7695463c267
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50840
Cleanup of index.js API removal warnings. This should motivate more urgency on the remaining members.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D73429537
fbshipit-source-id: 03faabdf30c2836dd5c61b4a2ce8d2355ad8e1e9
Summary:
Fixes https://github.com/facebook/react-native/issues/50817
Using a fragment is very common when rendering elements. We are cloning and adding `onLayout` always to the ListEmptyComponent element, but this would seem to work only when `View` is used for this as a wrapper in this prop. To prevent this unnecessary warning, I think we can easily check whether it is a fragment or not before cloning and adding the extra props – this adds backwards compatibility for those that don't need to use `onLayout`.
## Changelog:
[GENERAL] [FIXED] - Skip cloning Fragments in ListEmptyComponent to avoid onLayout warning
Pull Request resolved: https://github.com/facebook/react-native/pull/50833
Test Plan: Use the code snippet from the linked issue to verify that the warning is not thrown anymore when using a Fragment.
Reviewed By: javache
Differential Revision: D73421503
Pulled By: rshest
fbshipit-source-id: 0da4a38130601943e4704589ac275eba39767191
Summary:
This PR aims to migrate BlobProvider from Java to kotlin as part of [50513](https://github.com/facebook/react-native/issues/50513)
## Changelog:
[ANDROID][CHANGED] – Migrate BlobProvider to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/50756
Test Plan: Tested on RN tester with both new and old arch
Reviewed By: rshest
Differential Revision: D73420896
Pulled By: cortinico
fbshipit-source-id: 4c9a26452a7e45a78c9698f699822b4ac855628c
Summary:
instead of explictly specifying fully qualified Java boxed types, use proper Kotlin syntax to refer to it.
---
👉 Notes on Java <> Kotlin type mapping !!!
See: Kotlin's Mapped Types; https://kotlinlang.org/docs/java-interop.html#mapped-types
- kotlin `Boolean` maps to Java's primitive type `boolean` and not boxed Type `Boolean`
- Java boxed type `Boolean` maps to `Boolean?` in Kotlin
So in Kotlin,
- `Boolean::class.java` refers to Java primitive type `Class<boolean>` which is equivalent to `Boolean::class.javaPrimitiveType`
- For boxed type use `Boolean::class.javaObjectType` == `Class<Boolean>`
**TIP:** When dealing with Java primitive types using reflection, use `::class.javaPrimtiveType` or `::class.javaObjectType` to avoid the confusion with using plain `::class.java`.
Changelog:
[Internal]
Reviewed By: cortinico
Differential Revision: D73224138
fbshipit-source-id: 858093a22b38bfdad40b170d0cf80a440e503829
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50812
tsia, adding some accessibility examples that we have refined so far this half.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D73283176
fbshipit-source-id: 5bb451c1e79cd8bc92f333ef2fce82669ad0e971
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50811
tsia, adding some accessibility examples that we have refined so far this half.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D73281713
fbshipit-source-id: 42db49feba5c232e699afe01916425ddf11f4aea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50810
tsia, adding some accessibility examples that we have refined so far this half.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D73280582
fbshipit-source-id: a1cc572522729d06b9a0227f0e5731e698f86cc3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50838
This diff removes the usages of ShadowNodes in the new architecture by fully releasing disableShadowNodeOnNewArchitectureAndroid() feature flag.
changelog: [internal] internal
Reviewed By: alanleedev
Differential Revision: D72671083
fbshipit-source-id: a1505d02fd6bf7e87c7234581a26ef13768796a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50829
It is not appropriate to go through the fast path for border drawing when we have translucent border colors since it will cause overlapping borders to look weird.
Adding an if statement to prevent fastpath when the alpha value of any border is less than 255 (opaque)
Changelog: [Android][Fixed] - Fix translucent borders on Android overlapping bug
Reviewed By: NickGerleman
Differential Revision: D73145119
fbshipit-source-id: f22d0d55adca571d6b75725f6bc4753f98698763
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50828
The new Background and Border drawables come with some correctness improvements and potential small perf gains on edge cases. We are now switching to using them by default.
Changelog: [Android][Changed] - Change to use new Background and new Border drawables by default
Reviewed By: NickGerleman
Differential Revision: D72082947
fbshipit-source-id: 7caeb279110b520bea760a4621184dc0de05cf78
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50807
This structure is unsafe:
```
// In each native module:
+load
dispatch_once
NSBundle mainBundle
```
NSBundle mainBundle itself uses dispatch_once during initialization. If that initialization triggers a native module class load, we could end up with a circular dependency chain. This could deadlock the application.
## Changes
Just remove the dispatch_once. Getting the NSBundle mainBundle is very efficient after the first access. And NSBundle objectForInfoDictionaryKey is also very efficient.
Created from CodeHub with https://fburl.com/edit-in-codehub
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D73265906
fbshipit-source-id: f718e5bba7e95517613204b1f95e1b637e6c2366
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50832
Changelog: [iOS][Breaking]
these experiences did not end up shipping, so cleaning them up.
Reviewed By: fkgozali
Differential Revision: D73343958
fbshipit-source-id: ff0dc1394748c897aed9c66513b250dfc2192e0d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50818
Logging LegacyArchitectureLogger asserts only in Debug mode as that will give us enough information about wrong usages of Legacy Architecture at this point
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D73322301
fbshipit-source-id: 981a26b1bd7c89080f35ef0ab27677b0a38f2665
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50813
This is already in the same package, which makes Gradle build unhappy. Then, this wasn't invoked at all by a Buck build, because we have target per folder. Let's fix those.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D73286269
fbshipit-source-id: 6100c83e6607705160e4602e8637e3b1ebe8f28b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50809
Configures `react-native/metro-babel-transformer` (used by `react-native/babel-preset`) to parse source using `hermes-parser` to target React 19. This changes components written with Component Syntax to stop generating `forwardRef` calls (because `ref` is now a prop).
Most of this was already accomplished in https://github.com/facebook/react-native/pull/50377 ({D72070021}), but this call site was missed.
Changelog:
[General][Changed] - Configured Hermes Parser to target React 19, resulting in Component Syntax no longer producing `forwardRef` calls.
Reviewed By: elicwhite
Differential Revision: D73279825
fbshipit-source-id: c0d64cb8c0adb22b78c5fbed1b2c386c8b3f3ede
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50796
When we render a `Switch` today we are never actually focusing on the native `UISwitch` that gets rendered. We instead focus on the parent `RCTViewComponentView` which houses the `UISwitch` as a `contentView`. That is because of [this logic](https://www.internalfb.com/code/fbsource/[b7e1547dab5a]/xplat/js/react-native-github/packages/react-native/React/Fabric/Mounting/ComponentViews/View/RCTViewComponentView.mm?lines=1211-1213). This blocks the accessibility of any descendants, including the `contentView`.
What we lose here is the announcement of "on" and "off" based on the toggle state that comes built into `UISwitch`. To do this today you need to add `accessibilityState={{checked: ...}}` which is very unintuitive. Android DOES announce "on" and "off".
We can fix this with an override on the switch class.
Changelog: [iOS][Fixed] - Fix "on" and "off" announcements on `Switch`
Reviewed By: realsoelynn
Differential Revision: D73226500
fbshipit-source-id: ff4eed0b0b4b978e4b59c5e4b37d880373f6506c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50806
1. `useWindowDimensions` is already returning in DIPs, my math was just wrong before
2. Playground is marking itself as a deeplink when it shouldn't be
Changelog: [internal]
Reviewed By: cortinico, joevilches
Differential Revision: D73221335
fbshipit-source-id: 32dfa9d60609faccef8e264aa46d64b79250b64d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50782
Changelog: [IOS][FIXED] Fix TextInput `onContentSizeChange` event being dispatched only once on iOS on the new architecture
Currently, the comparison to decide whether to send event happens between the content size before and after layout metrics update. Those values turn out to be the same in all but the first call.
This updates the logic to use the previously send values in the comparison.
Reviewed By: huntie
Differential Revision: D73182563
fbshipit-source-id: 3b764a89c1844e203001d75022a3295a3fd747f2
Summary:
PR migrates DynamicFromObject class to Kotlin as part of https://github.com/facebook/react-native/issues/50513 work.
## Changelog:
[ANDROID] [CHANGED] - Migrated DynamicFromObject to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/50754
Test Plan: Run RN-Tester application and played around with it a bit.
Reviewed By: mlord93
Differential Revision: D73118014
Pulled By: alanleedev
fbshipit-source-id: 84958ff07ccafea9ec3dbdf06467c638eb92d49d
Summary:
unstable_hasComponent(component) first registers the component with react native, if possible. Then, it returns you whether registration succeeded.
## Problem
For unregistered components, the initial call returns false. But, all subsequent calls return true.
The reason why: After the initial call fails, react native registers unimplemented view under that component name. So, all subsequent calls return true.
## Solution
Just record the initial loopup result. And always return that initial lookup result from this method.
Changelog: [iOS][Fixed] Fix bug: unstable_hasComponent(*) = true for unregistered components for n > 1th call.
Reviewed By: yungsters
Differential Revision: D73127468
fbshipit-source-id: ee30bde486a6bb970f40f654c65a8946452f49b3
Summary:
These internals have leaked pretty far. As we are adding support for JNI reference state wrappers, lets hide this, and make functions for getting MapBuffer work automatically if state data exposes the requisite functions, instead of external users needing to worry about multiple possible `ConcreteState` types for a given state data type.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D73158627
fbshipit-source-id: e3ac2a045368d46fab72e2017fc28d680db6a7c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50784
Migrates us from several `.npmignore` files to `package.json#files`, for the main `react-native` package.
This reduces the size of our npm package by 38 files — in particular, catching previously missed `__tests__` and `__docs__` directories.
```diff
- npm notice package size: 4.4 MB
- npm notice unpacked size: 23.7 MB
- npm notice total files: 4533
+ npm notice package size: 4.4 MB
+ npm notice unpacked size: 23.7 MB
+ npm notice total files: 4533
```
NOTE: `"files"` or `.npmignore` — one or the other!
- Having `.npmignore` at the package root does not behave(!). Having `"files"` as one source of truth is better and safer. See https://github.com/npm/cli/issues/6221.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D73185321
fbshipit-source-id: 429c9fec4f447d63440a38bb8e3f3ce3bd155414
Summary:
parse-git-config is a transitive dep for Danger that hasn't been updated in years and has an unresolved CVE (CVE-2025-25975)
Danger has moved away from this dependency yesterday and cut a new version, so we can update to resolve
Changelog: [General][Fixed] Update Danger to 13.0.4
Reviewed By: cortinico
Differential Revision: D73181590
fbshipit-source-id: e5c512e6f381725eea71d64555018327144e23be
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50730
This is a consolidation of our "dev support" features in the `src/private/` dir.
New grouping:
- `src/private/devsupport/`
- `devmenu/` — The Dev Menu and in-app inspection features (in-app UI)
- `elementinspector/` — The Element Inspector overlay (panel with sub-features), accessed from Dev Menu → Toggle Element Inspector
- `perfmonitor/` — The Perf Monitor overlay, accessed from Dev Menu → Show Perf Monitor
- `rndevtools/` — Modules supporting React Native DevTools (external UI)
`NativeReactDevToolsRuntimeSettingsModule.js` and `NativeReactDevToolsSettingsManager.js` are also moved out of `specs_DEPRECATED/`.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D73031559
fbshipit-source-id: 952a469f31f4cd05aeed27dc7023552e723ca078
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50780
This bumps Kotlin to the latest stable: 2.1.20.
I've also fixed several warnings emitted by the new compiler.
Changelog:
[Android] [Changed] - Kotlin to 2.1.20
Reviewed By: rshest
Differential Revision: D73122000
fbshipit-source-id: 019a01d085b2c115a3efcf567056e9990a1ff0ce
Summary:
PR migrates DynamicFromArray class to Kotlin as part of https://github.com/facebook/react-native/issues/50513 work.
## Changelog:
[ANDROID] [CHANGED] - Migrated DynamicFromArray to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/50602
Test Plan: Run RN-Tester application and played around with it a bit.
Reviewed By: rshest
Differential Revision: D73179609
Pulled By: cortinico
fbshipit-source-id: e304884fea9f57e152bca4926677d7338dc2403a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50774
Adding a Fantom test for the `useShadowNodeStateOnClone` feature flag, showing that the shadow node state is maintained after commit hook processing only when the feature flag is enabled.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D73121159
fbshipit-source-id: bbd7f46fbf49394ca5015e825a59d2fb1b519ee5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50776
Changelog: [Internal]
Adds a lint rule that prevents the use of named imports when importing types from React. `flow-api-translator` relies on the `React` namespace being used when generating TypeScript definitions based on Flow.
Reviewed By: huntie
Differential Revision: D73170799
fbshipit-source-id: 96d014b016c7cec8d3b266447dc7a185d2b1da26
Summary:
I've migrated `FrescoBasedTextInlineImageSpan.java` to kotlin. Reference https://github.com/facebook/react-native/issues/50513.
## Changelog:
[ANDROID] [CHANGED] - Refactor class `FrescoBasedTextInlineImageSpan` from Java to Kotlin.
<!-- 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/50532
Test Plan: Tested the RN tester app with `yarn android` on both new and old architecture.
Reviewed By: rshest
Differential Revision: D73031024
Pulled By: cortinico
fbshipit-source-id: e7208bf1103849f38c3dc26d73b31315b2326275
Summary:
I forgot to add toString and protocol in test cases last time when we merged this https://github.com/facebook/react-native/pull/50043
## 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
-->
[INTERNAL][ADDED] More Test cases
Pull Request resolved: https://github.com/facebook/react-native/pull/50768
Test Plan: Tested with yarn jest
Reviewed By: rshest, cipolleschi
Differential Revision: D73169665
Pulled By: cortinico
fbshipit-source-id: 1115c0ccce52a67663fcd60ef376ce7bde502d1f
Summary:
This unblocks the `binary-compatibility-validator` for Kotlin 2.1.0
I've bump the tool to the latest version + re-aligned all the dependencies to the one used by the tool as well
(diff utils, asm, kotlinx-metadata-jvm).
Reviewed By: mdvacca
Differential Revision: D73057557
fbshipit-source-id: 020babea3a4032a8f9919ce7f456c3d4fb9a8e0c
Summary:
Nothing big, fixed typos in CHANGELOG
## Changelog:
[INTERNAL] - Fix Changelog message
<!-- 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/50772
Reviewed By: cortinico
Differential Revision: D73155730
Pulled By: arushikesarwani94
fbshipit-source-id: 0f169b455af5d657f3fa09a99562eb376c955389
Summary:
Since I enabled INTERPROCEDURAL_OPTIMIZATION last week, we're having a warning for gtest that
they're not setting this CMake policy: CMP0069
https://cmake.org/cmake/help/latest/policy/CMP0069.html
As Gtest is not a production dependency, we can safely ignore this warning. So I'm enabling the policy for all the targets.
Changelog:
[Internal] [Changed] -
Reviewed By: alanleedev
Differential Revision: D73122573
fbshipit-source-id: 319a889024f080752f0c9287d011209459dcb013
Summary:
Afacit from searching both fbsource and GitHub, this should be totally dead.
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D73154613
fbshipit-source-id: 1ed993ae53e7bc97232a8200b5fb4e01f0db7bb4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50773
With shadow node syncing enabled by default, whenever a shadow node has to be cloned, we can be guaranteed that the state on the shadow node will be the most recent state in most cases.
This change fixes state updates being ignored when cloning YogaLayoutableShadowNodes from a commit hook. Since the most recent state gets updated post commit, any clone reading the most recent state might miss state changes done within the commit.
Changelog: [Internal]
Reviewed By: rshest, cipolleschi
Differential Revision: D72315898
fbshipit-source-id: 5e14d03681dd1cc5686a649caa2e8c3685042cfa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50770
OSS CI is failing because the we forgot a deprecation message in ReactScrollViewManager.
## Changelog:
[Internal] - Add deprecation annotation to fix ci build
Reviewed By: sbuggay
Differential Revision: D73136939
fbshipit-source-id: 4f39d7c7ae60aaca1011b70135d9535b16ed58e0
Summary:
This structure is unsafe:
```
// In each native module:
+load
dispatch_once
NSBundle mainBundle
```
NSBundle mainBundle itself uses dispatch_once during initialization. If that initialization triggers a native module class load, we could end up with a circular dependency chain. This could deadlock the application.
## Changes
Just remove the dispatch_once. Getting the NSBundle mainBundle is very efficient after the first access. And NSBundle objectForInfoDictionaryKey is also very efficient.
Created from CodeHub with https://fburl.com/edit-in-codehub
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D73058551
fbshipit-source-id: 9d14b5556748288227cfb93940f79d44997d7b47
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50735
This change adds a warning in JS that is printed when the app is running using the old architecture.
The assumption is that, if it is running with Fabric, it is running with the new architecture. So running without Fabric implies old architecture.
## Changelog:
[General][Added] - Add warning when the app runs with the legacy architecture
Reviewed By: cortinico, rubennorte
Differential Revision: D73041156
fbshipit-source-id: 89a14f6370ae54b9d115e0ef672f29084d009a8e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50757
We received [this issue](https://github.com/facebook/react-native/issues/50747) in OSS where the URL parsing logic does not respect node/chromium specs.
This can cause issue in usercode. This change fixes it
## Changelog:
[General][Fixed] - make sure that URLs are parsed following the node specs
Reviewed By: huntie
Differential Revision: D73101813
fbshipit-source-id: 36f1d23b3ad7882c16524843621d9ebbcc09b95d
Summary:
This diff converts the last java file inside `com.facebook.react.views.textinput` to Kotlin.
As `ReactEditText` is quite involved, reviewing this one is going to be quite critical.
I'm marking this as breaking as a number of nullability types has changed for OSS users.
Changelog:
[Android] [Breaking] - com.facebook.react.views.textinput.ReactEditText is now in Kotlin. If you're subclassing this type you'll need to adjust your signatures.
Reviewed By: rshest
Differential Revision: D72972921
fbshipit-source-id: 92ed112444cbc20daed5466ad20f651479bfac6f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50738
The implementation of this in Hermes depends on a deprecated CMake
feature. Since it just needs to run a command to generate the dSYM, it
seems simpler to eliminate the flag and move the work into the RN build
script.
## Changelog:
[Internal] - move dsym generation logic from Hermes to RN
Reviewed By: cortinico, cipolleschi
Differential Revision: D73054511
fbshipit-source-id: 4b8f9d97ef3386154bfe4030e0061f9c0791d7ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50760
Changelog: [internal]
This updates all Excalidraw SVG diagrams in the repository to use the latest format exported by Excalidraw after the fix in https://github.com/excalidraw/excalidraw/pull/9386.
I basically opened every image in Excalidraw and re-exported it.
Reviewed By: lenaic
Differential Revision: D73107703
fbshipit-source-id: 4432e952f9e6ee29f59ef8a9ff05479552744a31
Summary:
## Changelog:
[Android] [Internal] - As in the title
Reviewed By: cortinico
Differential Revision: D72971263
fbshipit-source-id: 8bd0c4e29e48f7e3d47a97f1a4e988e7b0282646
Summary:
We have a different version of OkHttp internally and in OSS so we need to suppress these for now.
Only Error was supressed in previous diff, also suppress warning.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D73085528
fbshipit-source-id: a38a6e15e8ca33d4e93678c54d337ad9e86c2bbe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50748
We have a different version of OkHttp internally and in OSS so we need to suppress these for now.
Changelog: [Internal]
Reviewed By: Abbondanzo
Differential Revision: D73079163
fbshipit-source-id: 1928b00acbba5bc6577a248bc46a091d5b970f10
Summary:
const val NAME had quotes around it breaking native module loading from CoreReactPackage
This error was uncaught in previous diff.
Changelog:
[Internal]
Reviewed By: makovkastar
Differential Revision: D73070533
fbshipit-source-id: a7f14f4b4bd25003529c625d9182554dd2c2ee3e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50744
Crash was discovered after converting source code from Java to Kotlin.
This was due to type checking against Kotlin types instead of Java types.
Also added minor refactoring of code
Changelog:
[Internal]
Reviewed By: Abbondanzo
Differential Revision: D73064216
fbshipit-source-id: 3429f0627740438be3bbc345c9e7b2c4a535da7e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50586
# Changelog: [Internal]
We are going to record microtasks phase of the Event Loop.
RAII reporter that was added in D69399955 will be updated to support phase as a parameter.
There is one downside of the current implementation. Every Event Loop task will have a corresponding "Run Microtasks" block displayed, even if the microtasks queue was empty. There is no API in `jsi` that would allow us to get the size of the queue. If we had that, we could emit this event only when there is something in a microtasks queue.
The good this is that these frames usually have duration of 1-2 microseconds, so they are not visible, until user fully zooms in.
Reviewed By: rubennorte
Differential Revision: D72649816
fbshipit-source-id: d597f5b75aaf0975b14f61d2aa28b9c8bc34f4d5
Summary:
The check nightlies job is failing on some libraries because the library key contains `/` and ` ` characters that fails to be used properly when they are part of a path.
With this change, we are replacing those characters with `_` so this is a valid path were CI can save the outcome that needs to be collected later.
## Changelog:
[Internal] - Fix folder path
Pull Request resolved: https://github.com/facebook/react-native/pull/50726
Test Plan: Running in GHA
Reviewed By: cortinico
Differential Revision: D73036049
Pulled By: cipolleschi
fbshipit-source-id: 147b9fa15b4dfa08e94f01715e5a175479230d80
Summary:
*Hi,*
I made a small update to the dependency array in `useLayoutEffect`, changing it from `[native]` to `[native.value]` for better precision. Since JavaScript compares objects by reference, this change can lead to a minor performance improvement. Additionally, as `useLayoutEffect` is render-blocking, I wanted to ensure we optimize its usage as much as possible.
As a micro-optimization and in line with good coding practices, I also changed a `let + if` variable to `const`. While the performance gain is minimal, it contributes to cleaner and more consistent code.
Please feel free to review, and I sincerely apologize if I made any mistakes in the process.
## 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] [Changed]* – Refined `useLayoutEffect` dependency array from `[native]` to `[native.value]` for improved precision and efficiency in re-renders.
*[General] [Changed]* – Replaced `let` with `const` where applicable for better code standards and micro-optimization.
Pull Request resolved: https://github.com/facebook/react-native/pull/50682
Reviewed By: huntie
Differential Revision: D72979663
Pulled By: yungsters
fbshipit-source-id: 64ac09811b78ca67be903d8cd91da8cd6f0a45fa
Summary:
Implemented ReactLifecycleStateManager.java in Kotlin as part of Kotlin-ifying RN Round 3
## Changelog:
[ANDROID] [CHANGED] - Migrate ReactLifecycleStateManager to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/50685
Test Plan: Run RN-Tester and interacted with Mulitple components(Image, Flatlist, Input ) with both new architecture enabled and disabled
Reviewed By: rshest
Differential Revision: D73003097
Pulled By: cortinico
fbshipit-source-id: 27b90a0b94c17aa42cbb1665ca6fcf06db7cbf96
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50396
Integrates the `yarn build-types` script into our CI workflows.
**Notes**
- Will validate type generation in future PRs as part of the `test-all` workflow (this has been stable (i.e. successfully runs for our codebase) for the last 3 weeks).
- This is not load bearing in production code until D71969602.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D71975705
fbshipit-source-id: a234a05008b5e75976bbd5258948c37fcc1eeb76
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50718
On Windows `path.join` returns path with separators unsupported by resolution mechanism. This change enforces the use of `/` separators in `no-deep-imports` rule tests.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D73021185
fbshipit-source-id: d4799c01a5aef5b27fad961d774b58627115d213
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50714
This diff changes the category used by LegacyArchitectureLogger soft errors to be SOFT_ASSERTIONS
changelog: [internal] internal
Reviewed By: makovkastar
Differential Revision: D72999455
fbshipit-source-id: b5378fb92b22a3d06dda550192c7eba0db97ddcb
Summary:
Migrated ReactClippingViewGroupHelper.java to Kotlin as part of the React Native Kotlin migration initiative.
This change helps modernize the React Native Android codebase and improve maintainability.
No functional changes were introduced—only a language conversion while preserving the original logic and behavior.
## Changelog:
[ANDROID] [CHANGED] - Migrated ReactClippingViewGroupHelper.java to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/50679
Test Plan:
✅ Ran yarn && yarn android in the root directory and verified RNTester builds successfully.
✅ Opened RNTester on an Android emulator/device and navigated through various screens to ensure the app works as expected.
✅ Specifically tested views with removeClippedSubviews enabled to confirm runtime behavior remains unchanged.
✅ Used [KtFmt](https://github.com/facebook/ktfmt) to format the Kotlin file properly.
Reviewed By: arushikesarwani94
Differential Revision: D72973621
Pulled By: cortinico
fbshipit-source-id: e6f426a0cb7eb583935a560660900b29786df4c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50105
Pull Request resolved: https://github.com/facebook/react-native/pull/49543
When using `ReactScrollView` or `ReactHorizontalScrollView` Views with `removeClippedSubviews` keyboard navigation didn't work.
This is because keyboard navigation relies on Android's View hierarchy to find the next focusable element. With `removeClippedSubviews` the next View might've been removed from the hierarchy.
With this change we delegate the job of figuring out the next focusable element to the Shadow Tree, which will always contain layout information of the next element of the ScrollView.
We then prevent the clipping of the topmost parent of the next focusable view to lay out the entire containing element in case we have some necessary context in the parent
Changelog: [Android][Fixed] - Fix keyboard navigation on lists with `removeClippedSubviews` enabled
Reviewed By: joevilches
Differential Revision: D71324219
fbshipit-source-id: b55b7735a30714b2a5e1c9e0ed4ae84ab43f6694
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50404
Add another function to fabric to get the topmost stacking context parent given a root and a child.
This is to be used on focus searching algorithm in the case where the next focusable child is deeper in the hierarchy meaning we need to find the top most parent in the Android hierarchy and lay that out as well before transferring focus.
If we don't lay out the parent as well as the next focusable view:
- The next focusable view might lack context given by the parent
- If the parent is a scrollview and has removeClippedSubviews enabled then laying out the next focusable view will not work
- If the view is deeper in the android hierarchy in some cases it won't be layed out unless the parent is
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D72178408
fbshipit-source-id: 7b91ea695e236f3a92f9703bcc9ca943bf0dec24
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50196
Currently when `removeClippedSubviews` is enabled on Android keyboard navigation breaks and we can never focus the elements that are clipped. iOS has a similar issue but not as drastic, it only happens when elements on the FlatList have a lot of margin between them.
This algorithm aims to find the next focusable view and return it to native so that we can prevent the clipping of the view on the view clipping algorithm and hence fix keyboard navigation. For more information see D71324219
Fabric algorithm to find the next focusable view given:
`parentTag`: Top most relevant parent of the focused view
`focusedTag`: Tag of the currently focused view
`direction`: Direction in which focus is moving
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D71558965
fbshipit-source-id: 1a13c82d067834337e7f7936860780f467c9a15d
Summary:
Introduce a trait to be able to tell if a ShadowNode is focusable by keyboard. This will be used for focus ordering that delegates the work to the shadow tree when Native platforms don't have enough information to define the next focusable node
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D72258544
fbshipit-source-id: dcc2410b408eab5dbefc4512e0680cbe7f18c811
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50638
There were two issues with inset shadows here that I fixed
* If spread was big enough it would "invert" the clear region. [RectF's inset](https://developer.android.com/reference/android/graphics/RectF#inset(float,%20float)) method does not bound to a 0x0 rect, it will instead start making the rect bigger if the inset value is large enough.
* If the clear region was outside the rect the shadow disappeared. This is because [Canvas's drawDoubleRoundRect](https://developer.android.com/reference/android/graphics/Canvas#drawDoubleRoundRect(android.graphics.RectF,%20float[],%20android.graphics.RectF,%20float[],%20android.graphics.Paint)) will fail to draw if the inner rect is not completely inside of the outer.
Changelog: [Android][Fixed] - Fix inset shadow edge cases
Reviewed By: GijsWeterings
Differential Revision: D72833275
fbshipit-source-id: 3f42fb767630319c51a380f8ea28d682df9771a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50666
This diff updates the assert message in ReactNativeNewArchitectureFeatureFlags to reflect the behavior required by the assert
changelog: [internal] internal
Reviewed By: mlord93
Differential Revision: D72868428
fbshipit-source-id: 7a43aa9d3b3a2ee60e88cf77d117d97edc955af3
Summary:
Fixes https://github.com/facebook/react-native/issues/45857
The general idea behind this PR is the same for both platforms: dirty all nodes with `MeasurableYogaNode` trait when the layout is constrained with a new `fontSizeMultiplier`. There were a few caveats:
- `ParagraphShadowNode` marks its layout as clean in the constructor in most cases. To prevent that from using a stale measurement I'm using the font scale multiplier stored in `content_` property of the node. That value is then compared with the scale used to create the attributed string kept in the node's state. If those differ, the layout is not cleared.
- On Android, font scale wasn't passed down to the `SurfaceHandler`
- On Android, text measurement relies on cached `DisplayMetrics` which were not updated when the system font scale changed.
- `AndroidTextInputShadowNode` wasn't using `fontSizeMultiplier` at all. I needed to add it in all places where an `AttributedString` is constructed.
## Changelog:
[GENERAL] [FIXED] - Fixed text not updating correctly after changing font scale in settings
Pull Request resolved: https://github.com/facebook/react-native/pull/45978
Test Plan:
So far tested on the following code:
```jsx
function App() {
const [counter,setCounter] = useState(0);
const [text,setText] = useState('TextInput');
const [flag,setFlag] = useState(true);
return (
<SafeAreaView
style={{
flex: 1,
backgroundColor: '#fff',
alignItems: 'center',
justifyContent: 'center',
}}
>
<Text style={{fontSize: 24}}>RN 24 Label Testing {flag ? 'A' : 'B'}</Text>
<TextInput value={text} onChangeText={setText} style={{fontSize: 24, borderWidth: 1}} placeholder="Placeholder" />
<Pressable onPress={() => setCounter(prevState => prevState + 1)} style={{backgroundColor: counter % 2 === 0 ? 'red' : 'blue', width: 200, height: 50}} />
<Pressable onPress={() => setFlag(!flag)} style={{backgroundColor: 'green', width: 200, height: 50}} />
</SafeAreaView>
);
}
```
Reviewed By: NickGerleman
Differential Revision: D71727907
Pulled By: j-piasecki
fbshipit-source-id: 240fb5fa4967a9182bce7e885798b233d1e25aea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50377
Configures the Hermes Parser to target React 19, which changes components written with Component Syntax to stop generating `forwardRef` calls (because `ref` is now a prop).
Changelog:
[General][Changed] - Configured Hermes Parser to target React 19, resulting in Component Syntax no longer producing `forwardRef` calls.
Reviewed By: javache, SamChou19815
Differential Revision: D72070021
fbshipit-source-id: b891789d4ff1cbcb8eebea3525361ab14e628b51
Summary:
Migrated FrescoBasedReactTextInlineImageShadowNode.java to Kotlin as part of the React Native Kotlin migration initiative.
This change helps modernize the React Native Android codebase and improve maintainability.
No functional changes were introduced—only a language conversion while preserving the original logic and behavior.
## Changelog:
[ANDROID] [CHANGED] - Migrated FrescoBasedReactTextInlineImageShadowNode.java to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/50693
Test Plan:
✅ Ran yarn && yarn android in the root directory and verified RNTester builds successfully.
✅ Opened RNTester on an Android emulator/device and navigated through various screens to ensure the app works as expected.
✅ Specifically tested views with FrescoBasedReactTextInlineImageShadowNode enabled to confirm runtime behavior remains unchanged.
✅ Used [KtFmt](https://github.com/facebook/ktfmt) to format the Kotlin file properly.
Reviewed By: cortinico
Differential Revision: D72948067
Pulled By: rshest
fbshipit-source-id: ed56e6b328804d7b70271b669d101f70d6190d7f
Summary:
On Android, when resource shrinking is enabled, all resources added by Metro may be removed as react-native is accessing resources based on strings rather than references, so AGP can't see its usage.
Example output of `android/app/build/outputs/mapping/release/resources.txt `when `shrinkResources` is enabled.
```
raw/__node_modules_expo_vectoricons_build_vendor_reactnativevectoricons_fonts_materialcommunityicons : reachable=false
drawable/__common_assets_haptics_icon : reachable=false
```
It’s a coincidence that most of the resources are currently working, as many file names begin with strings that already exist in the String Pool. For example, `node_modules...` is flagged as used because 'node' is present in the String Pool, causing it to be whitelisted. However, this does not guarantee that the same will apply to all files - especially in a monorepo setup, where paths are significantly different. For example
* `__node_modules_expo_vectoricons_build_vendor_reactnativevectoricons_fonts_materialcommunityicons`
* `__common_assets_haptics_icon`
To prevent that behavior, metro during assets export should create `keep.xml` listing all resources generated by metro.
https://developer.android.com/build/shrink-code#keep-resources
We have already made a similar change in expo cli: https://github.com/expo/expo/pull/35465
## Changelog:
[ANDROID][ADDED] - Generate keep.xml to prevent resource shrinking
Pull Request resolved: https://github.com/facebook/react-native/pull/50620
Test Plan:
1. Enable resource shrinking in RNTester by adding this to `android.buildTypes.release` to `packages/rn-tester/android/app/build.gradle.kts`
```gradle
isMinifyEnabled = true
isShrinkResources = true
```
2. Use some resources in playground, for example:
```diff
diff --git a/packages/rn-tester/js/examples/Playground/RNTesterPlayground.js b/packages/rn-tester/js/examples/Playground/RNTesterPlayground.js
index 9dbacb99701..9ac9c231f3f 100644
--- a/packages/rn-tester/js/examples/Playground/RNTesterPlayground.js
+++ b/packages/rn-tester/js/examples/Playground/RNTesterPlayground.js
@@ -11,16 +11,14 @@
import type {RNTesterModuleExample} from '../../types/RNTesterTypes';
-import RNTesterText from '../../components/RNTesterText';
import * as React from 'react';
import {StyleSheet, View} from 'react-native';
+import {Header} from "react-native/Libraries/NewAppScreen";
function Playground() {
return (
<View style={styles.container}>
- <RNTesterText>
- Edit "RNTesterPlayground.js" to change this file
- </RNTesterText>
+ <Header />
</View>
);
}
```
3. Build app using `hermesRelease` variant
4. See Playground screen
| Before | After |
|---|---|
| <img width="488" alt="Zrzut ekranu 2025-04-10 o 12 17 53" src="https://github.com/user-attachments/assets/24fcaa7b-6ddb-4ba6-9fe5-65c27bcbc931" /> | <img width="488" alt="Zrzut ekranu 2025-04-10 o 12 15 58" src="https://github.com/user-attachments/assets/09a1ce77-be26-4571-a4b8-c466bf19e026" /> |
5. Inspect `packages/rn-tester/android/app/build/outputs/mapping/hermesRelease/resources.txt`
| Before | After |
|---|---|
| `drawable/_reactnative_libraries_newappscreen_components_logo : reachable=false` | `drawable/_reactnative_libraries_newappscreen_components_logo : reachable=true` |
Reviewed By: cortinico
Differential Revision: D72960028
Pulled By: huntie
fbshipit-source-id: df725fa2ea50150cd67687a97986976ffbbb5b40
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50698
Changelog: [internal]
This cleans up the flag to enable paint time reporting for Event Timing API entries, as this reporting fixes a bug and we've verified is stable/performant enough.
Reviewed By: rshest
Differential Revision: D72960337
fbshipit-source-id: 976810382208b9403c01c80324b540570bbc0e42
Summary:
Avoid incorrectly updating caret position
Pull Request resolved: https://github.com/facebook/react-native/issues/50641
The caret position is updated incorrectly when a user is first typing if an zero-length selection is set.
## Changelog:
[IOS] [CHANGED] - Typing into TextInput now will not cause the caret position to update to the beginning when a zero-length selection is set.
Pull Request resolved: https://github.com/facebook/react-native/pull/50680
Test Plan:
Tested with the following code(a simplified version from the code in https://github.com/facebook/react-native/issues/50641)
```js
const [selection, setSelection] = useState({start: -1, end: -1});
const onSelectionChange = (
evt: NativeSyntheticEvent<TextInputSelectionChangeEventData>,
) => {
const {selection} = evt.nativeEvent;
const {start, end} = selection;
console.log('selection change: ', start, end);
setSelection(selection);
};
return (
<View style={{ position: 'absolute', top: 50, left: 30 }}>
<TextInput
placeholder="test"
selection={selection}
onSelectionChange={onSelectionChange}
/>
</View>
);
```
When using the main branch, the caret position will jump back to the beginning after the first typing.
It works fine after applying this commit.
Reviewed By: fabriziocucci
Differential Revision: D72957245
Pulled By: cipolleschi
fbshipit-source-id: 3586797332b35e86b17f386a35e7d192ff758f7e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50699
Changelog: [internal]
Just changing the template to include emojis in the top level titles to make it easier to scan the doc
Reviewed By: lenaic
Differential Revision: D72961870
fbshipit-source-id: 64c45e7ac769c38af06ea318cdb581a04e230f90
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50656
This is going to convert to Kotlin one of the biggest class we have: ReactTextInputManager
As this class is quite big, I suspect there will be breakages.
https://github.com/search?type=code&q=%22%3A+ReactTextInputManager%22
I will investigate further and adjust the class as necessary.
Changelog:
[Android] [Breaking] - ReactTextInputManager is now in Kotlin
Reviewed By: rshest
Differential Revision: D72859925
fbshipit-source-id: 140d1a48ef891f1e6a401e3be59a11d3f9e24078
Summary:
Static code analysis detected obsolete SDK version checks.
Since [the minimum supported SDK version is API 24](https://github.com/react-native-community/discussions-and-proposals/discussions/802), these checks for API 21 are no longer necessary and can be safely removed.
## Changelog:
[INTERNAL] - Remove obsolete TargetApi annotations for LOLLIPOP (API 21)
Pull Request resolved: https://github.com/facebook/react-native/pull/50686
Test Plan:
```sh
yarn test-android
yarn android
```
CI should be green.
Reviewed By: cortinico
Differential Revision: D72948073
Pulled By: rshest
fbshipit-source-id: 1dd1415364d19f115771de3643cdc023a247d851
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50645
While we were refactoring the generation of the podspec, we made a mistake and we started generating the ReactCodegen.podspec for both libraries and apps.
This must be generated only for apps.
## Changelog:
[iOS][Fixed] - Generate `ReactCodegen.podspec` only for apps.
Reviewed By: fabriziocucci
Differential Revision: D72854074
fbshipit-source-id: 5a1d1120e576d4fe4cf8f733793f5a2619278c2b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50542
After TS types generation is completed, react native deep imports will be deprecated. This rule produces warnings to let users know to use root imports instead. For more information about why this rule was added, please check [RFC](https://github.com/react-native-community/discussions-and-proposals/pull/894).
Changelog:
[General][Added] - Added no-deep-imports rule to eslint-plugin-react-native.
Reviewed By: robhogan
Differential Revision: D71398004
fbshipit-source-id: 69104f69b1b1c59b5b0f115dcdd708a46d8d614d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50657
The ReactTextInputManager file is huge and really hard to migrate to Kotlin.
Here I'm extracting 4 private inner classes to separate files and converting them to Kotlin.
This will make reviewing the Kotlin migration of ReactTextInputManager a bit easier.
Changelog:
[Internal] [Changed] -
Reviewed By: rshest
Differential Revision: D72858396
fbshipit-source-id: 1fcca1b8421c810aa4bf9fdca7656f4e805565d8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50647
This diff makes the following file internal - ReactTextInputShadowNode
as part of our ongoing effort of reducing the API surface.
There is only one usage in OSS: `react-native-aztec`. The library is abandoned
with little weekly download so we should be good marking this as internal.
Changelog:
[Internal] [Changed] - ReactTextInputShadowNode is now internal.
Reviewed By: javache
Differential Revision: D72854896
fbshipit-source-id: 27512704ed84e893ae72d26469527276133a6295
Summary:
We fixed the previous layout issue when it wasn't in a ScrollView (I think text caching problem?) Let's enable for more than just Catalyst, and re-enable this test for iOS!
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D72683455
fbshipit-source-id: 538f8e23226c07510d382e45eb29f1710822849e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50673
Because, this is less a pain then trying to shrink every example to fit in to the tiny window given to us by Jest E2E.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D72683487
fbshipit-source-id: 5c08bd04445fc573086bc780194c893d0cb6ea19
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50672
We have precious little screen real estate, esp in E2E tests where we get 320x192 dips. Let's clean this up.
Changelog: [Internal]
Reviewed By: cortinico, GijsWeterings
Differential Revision: D72683491
fbshipit-source-id: 222a77f937dfb9dcceb627d8f084c58df7c07b56
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50669
Fixes a bug that was introduced while migrating from Java to Kotlin.
Changelog:
[Android][Changed] - Fixed a bug with synchronously fetching resources from Metro.
Reviewed By: cortinico, mdvacca
Differential Revision: D72878362
fbshipit-source-id: feb881fa51f6eaa2cb5c7ba87ac93b7fdc29dc2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50636
A while ago someone on GitHub reported that box shadow on iOS was causing frame drops when animating a large, pretty blurry shadow: https://github.com/facebook/react-native/issues/49128. This week I finally got around to fixing this!
The slowness was happening since we were using CG to draw this shadow, which is very CPU intensive and, to my knowledge, does not take advantage of GPUs to do anything. Couple that with an animating, large, blurry shadow and we have frame issues. These shadows were taking very long to draw, to get the image of the shadow (which then needs to be copied into some texture 3 times as big, composited, put on the screen etc) took 12-14ms :o, thats very slow.
To fix this I figured out how to get CA's shadow APIs working, which take advantage of the GPU. The enable inset shadows and spread you have to get creative with a mix of `shadowPath` and `mask` with a `CAShapeLayer`, but we got it done! Things are much faster, I am not sure how to time this but using a real device shows no frame drops :D
Changelog: [iOS][Fixed] - Box shadows on iOS are faster
Reviewed By: lenaic
Differential Revision: D72823334
fbshipit-source-id: 460339c9d77e7423ce59a1a9178b6b3ad527e4b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50665
Changelog: [internal]
Just a stylistic change of the link back to the documentation home.
It also changes the link in the template to make sure it's incorrect so people are forced to edit it when creating new docs.
Reviewed By: lenaic
Differential Revision: D72866823
fbshipit-source-id: fa7be286f996049b3f06e2defa5a8c486d63091b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50663
Changelog: [internal]
Adds additional documentation about pragmas and feature flags for Fantom.
Changes the diagram to mention that feature flags are passed to the Fantom CLI.
Reviewed By: andrewdacenko
Differential Revision: D72865960
fbshipit-source-id: abfd167279195495064f3c4dbdcaff92dd865bcf
Summary:
This PR introduces a rewrite of `DynamicFromMap.java` to Kotlin as requested in https://github.com/facebook/react-native/issues/50513.
## Changelog:
[ANDROID] [CHANGED] - Migrated `DynamicFromMap.java` to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/50597
Test Plan:
1. Implement unit tests for `DynamicFromMap.kt` - `DynamicFromMapTests.kt`
2. Ensure the tests pass: `./gradlew test`
3. Run the RN tester app on new & on old architectures
Reviewed By: javache, rshest
Differential Revision: D72853616
Pulled By: cortinico
fbshipit-source-id: 855acdc7fa7810ab9f223b0be7778c028a646de5
Summary:
Backing out https://github.com/facebook/react-native/pull/50244 as it is causing unexpected issues internally.
## Changelog:
[iOS][Changed] - Revert "Add warning when a component is loaded with the interop layer"
Reviewed By: cortinico
Differential Revision: D72857290
fbshipit-source-id: cfae6ccf85a472ae03983349fc7a2620e157865d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50658
The root cause of this is D67857739, confirmed via bisect.
The ReactInstanceIntegrationTest.cpp tests caused some sort of state poisoning. Because of that all tests in the same buck module that ran after, failed. These cpp tests have a retry mechanism where failing tests are retried, and because in that situation the integration tests didn't run, they passed there.
This turned into a total of 24 tests being 50% flaky, as every first attempt failed but every second attempt (in isolation) succeeded.
I did a bit of trial and error with resetting InspectorFlags and ReactNativeFeatureFlags (the latter was already being done before D67857739), and added an extra assertion to the tests to make sure that after that, `dangerouslyDisableFuseboxForTest` still worked in the right (but only the right) contexts.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D72860850
fbshipit-source-id: 959e67ff7a43ccc3c35db108bdb1138d8c27d328
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50660
Changelog: [internal]
This is just a simpler way to test for changes in scroll position.
Reviewed By: andrewdacenko
Differential Revision: D72860138
fbshipit-source-id: a92d430399255a278f5c3c72005a5288d28310ab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50644
Changelog: [internal]
This improves the documentation for the feature flag system by extending information about 2 areas:
- Codegen
- `print` command in CLI
Reviewed By: lenaic
Differential Revision: D72852768
fbshipit-source-id: 97932ea078595ef54cd437a433072f83bbdff609
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50654
We realized that when calling
```
npx react-native-community/cli codegen --path . --platform all --outputPath /tmp/codegen
```
We were generating in the android folder some files that are Apple-specific.
With this change, we should stop generating the Apple specific files in Android.
## Changelog
[General][Fixed] - Do not generate Apple specific files for Android
Reviewed By: cortinico
Differential Revision: D72859336
fbshipit-source-id: 443c4dca032e8e68c1da9d829d361d5e0ed007a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49887
## Changelog:
[Internal] -
As in the title.
This was the last Java file in the `events-common` module, so now it can be a pure Kotlin one.
NOTE: I opted to make the base method `Event.getEventData` public (instead of previously protected), as based on the usage patterns by the users this seems to make the most sense in this context.
Reviewed By: cortinico
Differential Revision: D70777597
fbshipit-source-id: fdaa52e4400ad8e86a8711daf359eb5a10974d05
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/50640
Test Plan: Verify that the comments link the classes correctly using Android Studio
Reviewed By: cortinico
Differential Revision: D72848152
Pulled By: javache
fbshipit-source-id: e09b1ddad494885ef3090d7f0f62a782eed922c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50632
Changelog: [internal]
This cleans up the `fixMountingCoordinatorReportedPendingTransactionsOnAndroid` feature flag that is no longer necessary.
Reviewed By: javache
Differential Revision: D72561255
fbshipit-source-id: 0942122832ce40cacc273265e4c95b5fe251dbe6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50643
Changelog: [internal]
Just realized this was missing from the message.
Reviewed By: lenaic
Differential Revision: D72852138
fbshipit-source-id: 27ed4b6e6d8b370cfa34a9878ca9bb0815cb75eb
Summary:
This code is not referenced internally or externally and was part of the DevSplitBundleLoader which was removed in D43597007.
Changelog: [Android][Breaking][Removed] Removed loadSplitBundleFromServer from DevSupportManager interface
Reviewed By: cortinico
Differential Revision: D72790533
fbshipit-source-id: 9e0960af4c528d9019943c89466ab442f34619e1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50545
All usages of Task.call involve a Runnable which returns another Task, which we then extract using `.continueWithTask(Task::getResult)`. Instead inline this behaviour inside `Task.call` to avoid allocation of unnecessary intermediate objects.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D72600051
fbshipit-source-id: 7e7c0c8e1de24b1aeff7addab2eb10272bc73ddb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50546
We do not use this mechanism for exception handing with Tasks, so remove it.
Changelog: [Internal]
Reviewed By: cortinico, fabriziocucci
Differential Revision: D72600053
fbshipit-source-id: f9ae877b05ece66682cb6c291b05257953f5aebb
Summary:
PR is here https://github.com/facebook/react-native/pull/50581
This enables INTERPROCEDURAL_OPTIMIZATION for Hermes in OSS, similar to how we did for libreactnative.so
I also had to bump CMake to 3.30.x to unblock the build failure with `-fuse-ld=gold`
Changelog:
[Internal] [Changed] -
Reviewed By: alanleedev
Differential Revision: D72696879
fbshipit-source-id: e842f6cdf41f6936ef4baeb70e4833a1a0c2d19b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50635
Ships the feature flag introduced by https://github.com/facebook/react-native/pull/50002.
Changelog:
[General][Changed] - Animated components' `ref` will now only reattach when receiving new props if the new props contain different `AnimatedValue` or `AnimatedEvent` instances. (Previously, Animated components' `ref` would always reattach when receiving new props.)
Differential Revision: D72802613
fbshipit-source-id: 4495eb778e3bb9473172c393bd984d93c4ba5f00
Summary:
Deleting ChoreographerCompat as its only method is deprecated and it's unused.
Use Choreographer.FrameCallback instead
changelog: [Android][Breaking] Deleting ChoreographerCompat, Use Choreographer.FrameCallback instead
Reviewed By: alanleedev
Differential Revision: D72817152
fbshipit-source-id: 08624dd07e916116381293cde57a0fdf5452a670
Summary:
ReactModuleWithSpec is deprecated and unused, it was replaced by TurboModule interface.
In this diff I'm removing DoNotStripAny annotation from ReactModuleWithSpec to make sure proguard doesn't retain any reference to it
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D72090838
fbshipit-source-id: 44aa0d6d4b2b592b5b8fea1b9e4578e2df3a9a8e
Summary:
InvalidIteratorException is not used in java, kotlin nor C++. This diff just removes this class
This is not a breaking change due to the lack of usages
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D72090837
fbshipit-source-id: 75aa4a8d2c1abbeb32bd38e5e60cbf7f04be823e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50605
In order to help Proguard to stripping-out bytecode, we need a way to statically enable all Feature Flags used by the New Architecture at build time (e.g. enableBridgelessArchitecture, useTurboModule, etc). The React Native Feature Flag system is mostly implemented in C++ and unfortunately Proguard can’t follow C++ code to understand what feature flags are enabled or disabled at build time.
After analyzing several proposals, we decided to introduce a new internal API called ReactNativeNewArchitectureFeatureFlags, this API will help us detect if an app is using the new architecture at build time.
In order to make this API to work I’ve migrated all usages of new architecture feature flags from ReactNativeFeatureFlags -> ReactNativeNewArchitectureFeatureFlags
changelog: [internal] internal
Reviewed By: mlord93
Differential Revision: D71988912
fbshipit-source-id: a6d58c5b1f39f85370298a347db228e933c6c743
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50604
ReactBuildConfig.UNSTABLE_ENABLE_MINIFY_LEGACY_ARCHITECTURE asume Fabric and TurboModule interops are disabled, in this diff I'm adding an assertion to validate this at runtime
changelog: [internal] internal
Reviewed By: mlord93
Differential Revision: D71854550
fbshipit-source-id: a4b3acfe4c3227115300b100be4d6222d5eace8e
Summary:
FrameworkAPI classes are not part of the public API, this diff will remove all FrameworkAPI classes from our public API tracking
changelog: [internal] internal
Reviewed By: alanleedev
Differential Revision: D72805466
fbshipit-source-id: b16791ab854017be681ceabd61b628d2d0ba0c5c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50627
Changelog: [internal]
This defines 2 new priorities in Fabric, matching the definitions in React:
* Continuous
* Idle
They're exposed to React via 2 new properties in `nativeFabricUIManager`: `unstable_ContinuousEventPriority` and `unstable_IdleEventPriority`.
It also adds the mapping from the raw event priorities to the Fabric event priorities.
This change doesn't have any effect at the moment. For these to come into effect, we need to:
1. Fix the mapping between Fabric priorities and React priorities in the React repository. See https://github.com/facebook/react/pull/32847
2. Enable the `fixMappingOfEventPrioritiesBetweenFabricAndReact` feature flag.
Reviewed By: javache
Differential Revision: D72791968
fbshipit-source-id: 525b6e5c99dc0ddc1e5c60fdb5b73f0555e5f0d3
Summary:
We currently have a high granularity of different React Native systrace markers. These different markers are not consistently applied and we only enable a subset of them by default in our tracing workflows. As we migrate more and more tracing to Perfetto the tags also become less relevant and will be replaced by Perfetto categories and tracks in the future.
This stack aims to simplify this setup by reducing all systrace tags to single TRACE_TAG_REACT.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D72672912
fbshipit-source-id: 1b6b14fc4ef6d6830bba41d7977f277d63ff5117
Summary:
Changelog: [internal]
(This is "internal" because the `PerformanceObserver` API isn't stable yet).
This cleans up the feature flag to enable the LongTasks API to the availability of the API itself isn't gated behind this specific one.
Reviewed By: rshest
Differential Revision: D72784109
fbshipit-source-id: 8ca45d66cebbd80729829c928bebb13f4a38b7ab
Summary:
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made ReactHostImpl.java nullsafe
Reviewed By: cortinico
Differential Revision: D72384082
fbshipit-source-id: 999903b1bf98ea61d2431ace5ca6584535ca4857
Summary:
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D72384065
fbshipit-source-id: 0f1df2a870d1975b0c522a2e6a17e8959aab6c7c
Summary:
This diff converts to Kotlin the following file: BridgelessAtomicRef.java
as part of our ongoing effort of migrating the codebase to Kotlin.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D72777272
fbshipit-source-id: b6e10ce32b701614cb323adde7d3df2aa2a8f293
Summary:
This PR aims to migrate FileReaderModule from Java to kotlin as part of https://github.com/facebook/react-native/issues/50513
## 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]Migrate FileReaderModule to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/50562
Test Plan: Tested on RN tester with both new and old arch
Reviewed By: arushikesarwani94
Differential Revision: D72726333
Pulled By: cortinico
fbshipit-source-id: 130393373a258f18f8baaa96745da8fdebd62436
Summary:
This is not mentioned on the spec https://drafts.csswg.org/css-ui/#outline-offset but web adds the outline-offset to the border-radius of the outline. With this change now we render outline in this case like web
Related issue: https://github.com/facebook/react-native/issues/50582
Changelog: [General][Fixed] - Outline now takes into account outline-offset to calculate its border-radius, same as web.
Reviewed By: joevilches
Differential Revision: D72749009
fbshipit-source-id: b3cd39e09e7856b6ccd45aab541cd51f05559832
Summary:
This class doesn't have any FIXMEs to fix, so we can just annotate it and protect against future issues!
Changelog: [Android][Fixed] Mark ReactApplicationContext.java as nullsafe
Reviewed By: javache
Differential Revision: D72704847
fbshipit-source-id: cd6907630839a8be2a6fb1d0a673357aef1395fc
Summary:
This class doesn't have any FIXMEs to fix, so we can just annotate it and protect against future issues!
Changelog: [Android][Fixed] Mark Inspector.java as nullsafe
Reviewed By: javache
Differential Revision: D72704854
fbshipit-source-id: fcd15a3cc2e9ea1ed90ecca13c068188b859afac
Summary:
This class doesn't have any FIXMEs to fix, so we can just annotate it and protect against future issues!
Changelog: [Android][Fixed] Mark JavaScriptModuleRegistry.java as nullsafe
Reviewed By: javache
Differential Revision: D72704846
fbshipit-source-id: d1bca84cd2f4543e154ab8e7948821b176088d64
Summary:
This class doesn't have any FIXMEs to fix, so we can just annotate it and protect against future issues!
Changelog: [Android][Fixed] Mark JSBundleLoader.java as nullsafe
Reviewed By: javache
Differential Revision: D72704848
fbshipit-source-id: 7995bda8200fff96ff66e54eb503fee53f8a19dd
Summary:
This class doesn't have any FIXMEs to fix, so we can just annotate it and protect against future issues!
Changelog: [Android][Fixed] Mark JSONArguments.java as nullsafe
Reviewed By: javache
Differential Revision: D72704849
fbshipit-source-id: a545bca24d4d95930f0e334c5295584e3c03c10c
Summary:
This class doesn't have any FIXMEs to fix, so we can just annotate it and protect against future issues!
Changelog: [Android][Fixed] Mark ModuleSpec.java as nullsafe
Reviewed By: javache
Differential Revision: D72704851
fbshipit-source-id: 4cccc70ac846f1aa90831557841d2e621847bfc4
Summary:
This class doesn't have any FIXMEs to fix, so we can just annotate it and protect against future issues!
Changelog: [Android][Fixed] Mark ReactContextBaseJavaModule.java as nullsafe
Reviewed By: javache
Differential Revision: D72704852
fbshipit-source-id: 65abc94d59aefc64ff214bd70ead16d9011dec20
Summary:
This class doesn't have any FIXMEs to fix, so we can just annotate it and protect against future issues!
Changelog: [Android][Fixed] Mark ReactMarker.java as nullsafe
Reviewed By: javache
Differential Revision: D72704853
fbshipit-source-id: 2d022f407070ab473a43281fab6f28c53fa09f21
Summary:
This class doesn't have any FIXMEs to fix, so we can just annotate it and protect against future issues!
Changelog: [Android][Fixed] Mark NativeModule.java as nullsafe
Reviewed By: javache
Differential Revision: D72704850
fbshipit-source-id: a71f3acddb0382410739b9632fba509fffcfebfd
Summary:
This is not a TextInput and is totally unused (whoops).
Changelog: [Internal]
Reviewed By: cortinico, Abbondanzo
Differential Revision: D72683433
fbshipit-source-id: 1218701fdc473117774a9bdb6f94b6a4508599a4
Summary:
I've implemented a feature that automatically bundles the Metro Bundler's IP address into Android builds. This change aligns the Android development experience with iOS, allowing the app to maintain a connection to the Metro Bundler even when disconnected from USB.
Currently, in iOS builds, the IP address of the computer running the Metro Bundler is automatically bundled into the app, ensuring seamless connectivity even when the device is disconnected from USB. In contrast, Android developers must manually input the IP address if the USB connection is lost, which can be tedious and error-prone.
More info in discussion thread: https://github.com/react-native-community/discussions-and-proposals/issues/870
I anticipate that a change where making IP the default method of connection will result in a lot of people running into issues where they can't connect to Metro server (for example, if they're on a different network, or they disable wifi). So I also changed the default error message you get in case the app can't connect to the bundler and updated the "Change Bundle Location" dev menu.
The previous error message
```
Unable to load script. Make sure you're either
running Metro (run 'npx react-native start') or
that your bundle 'RNTesterApp.android.bundle' is
packaged correctly for release.
```
was changed to:
```
Unable to load script.
Make sure you're running Metro (npx react-native start)
or that your bundle 'RNTesterApp.android.bundle' is
packaged correctly for release.
The device must be on the same WiFi as your laptop to
connect to Metro.
To use USB instead, shake the device to open the dev
menu and set the bundler location to 'localhost: 8081'
and run:
adb reverse tcp:8081 tcp:8081
```

And the new dev menu UI looks like this:

The two buttons with "10.0.2.2:8081" and "localhost:8081" are suggestions which when tapped fill the input with the text from the button. The first button suggests the IP of the development machine, and the second one is hardcoded to localhost:8081.
## Changelog:
[ANDROID] [CHANGED] - Automatically use Metro bundler IP address when installing apps on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/49166
Test Plan:
I've tested the implementation on a physical device and on emulator and it's working solid. However, I would invite further testing in order to catch possible edge cases.
I've recorded common scenarios
Scenario 1:
Device doesn't have the app installed.
We connect the device via USB, install the app and open it.
Device is on the same network as the dev machine.
Bundler location is by default set to the IP of the dev machine.
When starting app, the app is able to connect to the dev machine and download the bundle.
Scenario 2:
Device doesn't have the app installed.
Wi-Fi is turned off on the device but device is connected via USB
We install the app and open it.
Bundler location is by default set to the IP of the dev machine.
When starting app, the app is not able to connect to the dev machine and shows the error message.
After opening the dev menu we see that the IP is set to the IP of the dev machine.
We click the "localhost" option in the dev menu and click apply
After that the app is able to connect to the dev machine and download the bundle (via USB) since the traffic is forwarded using adb reverse.
Notes:
When we set an IP in the dev menu, the app will persist it.
If we connect the device via USB and reinstall the app the persisted data stays the same, so the previously set IP will be used.
However, the IP of the dev machine will be displayed as an option in the dev menu.
https://github.com/user-attachments/assets/cc2da5d4-de07-4980-a61c-68ca53db74c7https://github.com/user-attachments/assets/407b8871-8b83-4a6b-a833-f87ddc0afc82
Reviewed By: huntie
Differential Revision: D69664231
Pulled By: cortinico
fbshipit-source-id: 5a339be50a17a59202416b99e72f4397d8ff4805
Summary:
We only use fbsystrace API's directly from cxxreact and reactperferflogger targets, so export the dependency and the preprocessor flag there so we do not have to duplicate (and potentially forget to do this) from all other targets in react-native.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D72704827
fbshipit-source-id: 845c174b4f9ce0a67dd80be3f6274234328bbdb9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50592
For unclear reasons this is crashing on some devices when dereferencing the module ref. Instead we can just access the existing global_ref to the module instance and avoid any deallocation timing issues.
Also added some additional safeguards and validation against incorrect JNI invocations.
Changelog: [Android][Fixed] Fix crash when TurboModule event emitters are used on arm32
Reviewed By: cortinico
Differential Revision: D72716972
fbshipit-source-id: 3803329048d8388b3d30c9cb55a857e399569eea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50594
Some tests are failing due to unsatisfied error when looking for C++ classes of feature flags, we fix this by calling ReactNativeFeatureFlagsForTests.setup()
changelog: [internal] internal
Reviewed By: yungsters, sbuggay
Differential Revision: D72721786
fbshipit-source-id: c41c05428b1f99db9b03bb67cd9ddc47ebec84b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50591
Changelog: [internal]
This implements linting for Markdown files in React Native via `markdownlint`. We already have Prettier support for Markdown, but this adds some missing functionality, especially validation of local links.
Reviewed By: cortinico
Differential Revision: D72649666
fbshipit-source-id: 5e2c369332b270850d6d04d8960e6ce717f5ba7a
Summary:
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made FabricUIManager.java nullsafe
Reviewed By: cortinico
Differential Revision: D72705994
fbshipit-source-id: 56786a5df78322e833401c94dafae4e9335feefe
Summary:
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made TextAttributeProps.java nullsafe
Reviewed By: rshest
Differential Revision: D72460127
fbshipit-source-id: b5b098d8763ed45579c50068033374dfc88afa86
Summary:
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D72460132
fbshipit-source-id: 4ff177555f4d035be82ec6a134227f9ed2076fb9
Summary:
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made ReactTextViewManager.java nullsafe
Reviewed By: javache
Differential Revision: D72460124
fbshipit-source-id: a75705ac4ab486ccaa9162dee5bfd8cae77967c7
Summary:
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: arushikesarwani94
Differential Revision: D72460133
fbshipit-source-id: 7673e962e50946b504e3bd9446b3aef962271241
Summary:
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D72460130
fbshipit-source-id: fbc073e7b644326e85a05227c1e2e72e3dd5b870
Summary:
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D72460128
fbshipit-source-id: 5165055b1023a9eab86b97ef6cdfa9553c063ec0
Summary:
https://developer.android.com/reference/android/widget/TextView#setEllipsize(android.text.TextUtils.TruncateAt) explicitly allows setting setEllipsize's argument in TextView to null to turn off ellipsizing, which is what we want for `clip`
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made ReactTextAnchorViewManager.java nullsafe
Reviewed By: alanleedev
Differential Revision: D72460123
fbshipit-source-id: 26d91d273ead5906060772f65a32fbf4389d0db3
Summary:
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D72460131
fbshipit-source-id: d2b82fe1abcfd828490820f31862339bce9785b6
Summary:
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made ReactBAseTeextShadowNode.java nullsafe
Reviewed By: alanleedev
Differential Revision: D72460122
fbshipit-source-id: 772b19016fa1558b549d73ad2b23f891ce2f57f6
Summary:
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D72460134
fbshipit-source-id: b5e8864ddd7454ef23c5632dc2c8e502050dfe2b
Summary:
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made ViewManagerRegistry.java nullsafe
Reviewed By: alanleedev
Differential Revision: D72384049
fbshipit-source-id: dbca38ee6379e2e64b37c1d265c001585344661d
Summary:
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D72384050
fbshipit-source-id: ac88074a45752a5512daa09fce8c385b256b3d41
Summary:
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made TouchTargetHelper.java nullsafe
Reviewed By: rshest
Differential Revision: D72384076
fbshipit-source-id: 344d93484cb465f4841256d302a6d9eec1467643
Summary:
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D72384058
fbshipit-source-id: 543da56ed4410625f17d143b127aa5cc882e0327
Summary:
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made ThemedReactContext.java nullsafe
Reviewed By: alanleedev
Differential Revision: D72384053
fbshipit-source-id: 39ce998cfce1de358f13b4f068f180dfd1d88378
Summary:
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D72384062
fbshipit-source-id: 70b7b4490e002016a83746336b9bb397e917a858
Summary:
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made JSPointerDispatcher.java nullsafe
Reviewed By: alanleedev
Differential Revision: D72384071
fbshipit-source-id: 474671024632f7cdce7547855d0631c6a7005e8b
Summary:
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D72384057
fbshipit-source-id: fd10242d14dd3e9cc2f6cd72dcac693b0f52c818
Summary:
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made PromiseImpl.java nullsafe
Reviewed By: alanleedev
Differential Revision: D72384070
fbshipit-source-id: 142a0e001af42ebb8cc1c8301b3ec7f586191d92
Summary:
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D72384080
fbshipit-source-id: f859a21826bd1dd9d6fa0da82df5a4f0e9e79264
Summary:
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made NativeModuleRegistry.java nullsafe
Reviewed By: javache
Differential Revision: D72384075
fbshipit-source-id: bebc637a757c9f86d6260f9076010de9d7c80d4a
Summary:
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D72384051
fbshipit-source-id: 6cc3ab112a676fe6dfcfa1a4aa74e0dcd0e53e4a
Summary:
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made ModuleHolder.java nullsafe
Reviewed By: alanleedev
Differential Revision: D72384056
fbshipit-source-id: 42bfdd9b73bdb599ab67b6fe8759c80665156d22
Summary:
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D72384081
fbshipit-source-id: a45f551089f9484d11d0701c98a06467da667b36
Summary:
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made JsonWriterHelper.java nullsafe
Reviewed By: alanleedev
Differential Revision: D72384060
fbshipit-source-id: ce41674cc5dbadcd70029396607ac046100e2be7
Summary:
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D72384061
fbshipit-source-id: 7a238fae907398ad785b169db7232068eef5617b
Summary:
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made DynamicFromObject.java nullsafe
Reviewed By: alanleedev
Differential Revision: D72384066
fbshipit-source-id: 6f187f8a87a2c5d239c671880404eb81f0e22d3e
Summary:
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D72384067
fbshipit-source-id: b9cc92e41f29cd5af4d277ee8ec0cb3c432bdeec
Summary:
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made DynamicFromMap.java nullsafe
Reviewed By: alanleedev
Differential Revision: D72384077
fbshipit-source-id: 70fb921fed06e9f89eb69c558692d1d7705fe2e5
Summary:
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D72384073
fbshipit-source-id: fb9cc4d6da6ee78785e70c8b298434f61c60c1dd
Summary:
D65596278 marked the non-primitive return types from ReadableArray as optional, so we have to follow suit
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made DynamicFromArray.java nullsafe
Reviewed By: alanleedev
Differential Revision: D72384069
fbshipit-source-id: c67dc5bfb540af9190f740d565e5bda63d1caaa8
Summary:
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D72384068
fbshipit-source-id: 83f4b75b19dcccf752e53fd301ccda7b42a5c611
Summary:
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made BaseJavaModule.java nullsafe
Reviewed By: alanleedev
Differential Revision: D72384078
fbshipit-source-id: aba0f261f3b3e77133ff2a148bf4903c73c54691
Summary:
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D72384074
fbshipit-source-id: de616024dcca4c2d14b329aa020267c8a3d0ee56
Summary:
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made Arguments.java nullsafe
Reviewed By: cortinico
Differential Revision: D72384054
fbshipit-source-id: 87ad373d8663d8342d2ec8b757cec2a756210f45
Summary:
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D72384064
fbshipit-source-id: 12272e3b1b0a7900515071cee9d95469e4d95d6c
Summary:
Implemented ReactEditTextInputConnectionWrapper in Kotlin as part of Kotlin-ifying RN
## Changelog:
- Removed ReactEditTextInputConnectionWrapper.java
- Added ReactEditTextInputConnectionWrapper.kt
Pick one each for the category and type tags:
[ANDROID] [CHANGED] - Kotlinify ReactEditTextInputConnectionWrapper
Pull Request resolved: https://github.com/facebook/react-native/pull/50573
Test Plan: Run RN-Tester and interacted with TextInputs with both new architecture enabled and disabled
Reviewed By: rshest
Differential Revision: D72704246
Pulled By: cortinico
fbshipit-source-id: fec358d157c6ba09fecfa98bf431b18eee7824b0
Summary:
Some minor fixes in the RNTester that were bugging me a bit:
- Playground tab icon is not displaying the correct icon when the tab is active.
- The RNTTestDetails button is being displayed when there is nothing to display.
- Export the data for the Playground tab correctly to display the description.
## Changelog:
[INTERNAL] - RNTester: Fix playground icon & test details button
Pull Request resolved: https://github.com/facebook/react-native/pull/50530
Test Plan:
<details>
<summary>Screenshots</summary>
| Before | After |
|------------------------------------|------------------------------------|
|  |  |
</details>
Reviewed By: NickGerleman
Differential Revision: D72576804
Pulled By: cortinico
fbshipit-source-id: 8555677a5121fe908c18d349e80ce8097d144fe5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50588
Changelog: [internal]
This configures Prettier to format all markdown files in `__docs__`.
Reviewed By: lenaic
Differential Revision: D72706239
fbshipit-source-id: 67b4c82528c89e497c0ff1aacbc30d76f4d29a3e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50587
Changelog: [internal]
This does an initial formatting of all Markdown files that are going to be formatted by prettier from now on.
Reviewed By: lenaic
Differential Revision: D72706240
fbshipit-source-id: b365a94e5d74945a121966fddcb43776ebc534e0
Summary:
* EventBeatManager's deprecated constructor is removed
* No need to keep a ref to jhybridobject_ (it's invalid to keep an alias_ref like this anyway)
* Use HybridClassBase to reduce the number of objects
Changelog: [Android][Removed] Removed deprecated EventBeatManager(ReactApplicationContext) constructor
Reviewed By: mdvacca
Differential Revision: D71984490
fbshipit-source-id: 01482ddd3128ef5f495682e75897e2a6549274a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50553
Adding nanosecond resolution for macOS to the NativeCPUTime native module. This allows for running Fantom benchmarks on macOS with high resolution CPUTime counters.
This change adds the internal `getCPUTimeConversionFactor` function which is needed to convert the output from `mach_absolute_time` to a double representing time in nanoseconds. The native module calls `getCPUTTimeConversionFactor` once in the constructor and stores the result for future calls. The conversion factor defaults to 1.0 for all other platforms.
Changelog: [internal]
Reviewed By: rubennorte
Differential Revision: D72631963
fbshipit-source-id: 33fa1bfc576e634187091bfa668106e31cc62214
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50559
This diff migrates the following file to Kotlin - DevSupportManagerBase.kt
as part of our ongoing effort of migrating the codebase to Kotlin
This file was 1000LOC+ so its migration is quite involved.
I had to look into nullability of various parameters. Most notably the `Array<StackFrame?>` -> `Array<StackFrame>`.
This also is the last file left in the devsupport package that needs to be migrated to Kotlin.
Changelog:
[Android] [Breaking] - DevSupportManagerBase is now converted to Kotlin. If you're subclassing this class, you will have to adjust some of the parameters as types have changed during the migration.
Reviewed By: javache, mdvacca
Differential Revision: D72637098
fbshipit-source-id: b87d5f17e30d69fe9c09ec9b49f96818df34ea3b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50558
This diff migrates the following file to Kotlin - DevServerHelper
as part of our ongoing effort of migrating the codebase to Kotlin
Changelog:
[Internal] [Changed] - DevServerHelper to Kotlin.
Reviewed By: javache
Differential Revision: D72632266
fbshipit-source-id: 5dab7206dcf11de042d9e274e33a38a4491f1d17
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50580
This follow ups to us enabling INTERPROCEDURAL_OPTIMIZATION to libreactnative.so and enables
INTERPROCEDURAL_OPTIMIZATION for the app module as well.
Changelog:
[Android] [Changed] - Enable INTERPROCEDURAL_OPTIMIZATION for libappmodules.so in OSS
Reviewed By: rshest
Differential Revision: D72696658
fbshipit-source-id: ec07c7df9a639b5c3df8923ec384db90a78463e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50569
This diff makes all the *Systrace files internal.
as part of our ongoing effort of reducing the API surface.
Changelog:
[Internal] [Changed] -
Reviewed By: mdvacca
Differential Revision: D72646992
fbshipit-source-id: d085da9cf841fc2e8a026b8d09d8a17550505c7a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50563
This diff makes all the classes inside `com.facebook.react.views.text.internal.span` internal.
Those classes are already inside an `.internal` package. By making them `internal` with the Kotlin keyword
we're making harder for them to be accidentally referenced outside React Native.
as part of our ongoing effort of reducing the API surface.
Changelog:
[Internal] [Changed] - com.facebook.react.views.text.internal.span is now internal
Reviewed By: mdvacca
Differential Revision: D72644962
fbshipit-source-id: dbb5a45e6121cb49509469d1d40c3b278cc62368
Summary:
Users should not be using `getCurrentActivity()` method on `ReactContextBaseJavaModule`.
Instead they should use `getReactApplicationContext.getCurrentActivity()`
This correctly deprecates this method for 0.80.x
Changelog:
[Android] [Deprecated] - Correctly deprecate ReactContextBaseJavaModule.getCurrentActivity() method
Reviewed By: mdvacca
Differential Revision: D72449062
fbshipit-source-id: f74bf94980447497e7e9049ede2b44c1d1f0d48b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50557
This diff migrates the following file to Kotlin - BundleDownloader
as part of our ongoing effort of migrating the codebase to Kotlin
Changelog:
[Internal] [Changed] - BundleDownloader to Kotlin
Reviewed By: javache
Differential Revision: D72627995
fbshipit-source-id: 9d65473c4d4a0962f78b0f71fc24530415a0e908
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50560
This diff migrates the following file to Kotlin - StackTraceHelper
as part of our ongoing effort of migrating the codebase to Kotlin
I've moved the method `convertProcessedError` to `internal` because it was already using a parameter of type `ProcessedError` which is itself internal.
Changelog:
[Internal] [Changed] - StackTraceHelper to Kotlin
Reviewed By: rshest
Differential Revision: D72569103
fbshipit-source-id: 8c544b83deda82c7a3d1a04d8cd0c9e12c9b6d46
Summary:
This diff removes the usage of getShadowNodeClass() on apps that are purely running on the new architecture.
The implications of this change are:
- all shadow node classes will be stripped-out by proguard
- props exposed in shadow Nodes won't be included in the native view configs, this is fine becuase all core components are already using static view configs, props included in LayoutShadow node are covered by: BaseViewConfig.android.js
changelog: [internal] internal
Reviewed By: javache, cortinico, rshest
Differential Revision: D72602551
fbshipit-source-id: caada701f80253830df0085fdbbac47a2aa6d71b
Summary:
In this diff I'm introducing the ReactNativeFeatureFlags.disableShadowNodeOnNewArchitectureAndroid() feature flag, this will be used to control the usage of shadow nodes in apps that are purely running on the new architecture.
The default value for this feature flag is true because we are assuming this is the right value long term (this is just a toggle)
changelog: [internal] internal
Reviewed By: alanleedev
Differential Revision: D72602553
fbshipit-source-id: 3eb1a151e74c1728374a1d37b4151a0928801de5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50566
This diff makes the following file internal - package com.facebook.react.internal
as part of our ongoing effort of reducing the API surface.
Changelog:
[Internal] [Changed] - com.facebook.react.internal pakcage is now internal
Reviewed By: mdvacca
Differential Revision: D72645991
fbshipit-source-id: 406c922b06ad883e00c63116e8efccd29e088ced
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50570
This diff makes the following file internal - ReactRawTextShadowNode and ReactRawTextManager
as part of our ongoing effort of reducing the API surface.
The only meaningful user of this API is this library:
https://github.com/iyegoroff/react-native-text-gradient
Which is umaintained (last supported version is RN 0.59) so I'm not considering this breaking.
Changelog:
[Android] [Changed] - Make ReactRawTextManager internal. We verified no popular libraries are impacted by this change
Reviewed By: mdvacca
Differential Revision: D72647702
fbshipit-source-id: 59a3646fdbc8f11907b4cf5056ff88c6dcec1cf8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50365
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made FabricUIManager.java nullsafe
Reviewed By: GijsWeterings
Differential Revision: D71979601
fbshipit-source-id: 599d87f0783a566c837aa70975a62f5f908a2294
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50371
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D71979591
fbshipit-source-id: 77369affbe4fd7411f149a4a2de869b48a1faa1a
Summary:
This PR aims to migrate UiThreadUtil from Java to kotlin as part of https://github.com/facebook/react-native/issues/50513
## 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]Migrate UiThreadUtil to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/50536
Test Plan: Tested on RN tester with both new and old arch
Reviewed By: cortinico
Differential Revision: D72602041
Pulled By: arushikesarwani94
fbshipit-source-id: 9f45a139805819a21039eb640a0bd1583a3acde9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50565
This annotation is unused. It was referenced in the past with Buck1 OSS but now we can safely remove it.
Changelog:
[Internal] [Changed] -
Reviewed By: fabriziocucci
Differential Revision: D72645219
fbshipit-source-id: 0327fa562276193ad9f48dc81ea7a9fa0da19eee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50374
This diff breaks down ScrollView props into ScrollViewBaseProps to generate more readable TS types, re-exports AnimatedComponent and sets the default SectionList Item type to `any`.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D72061941
fbshipit-source-id: 439fcdb1540288d6e610cd535b1fed82243c3b7c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50531
# Changelog: [Internal]
This should not have any functional changes, mostly refactoring the previous code, splitting it into smaller methods, better documentation and added tests.
Main changes are:
1. We are going to use smart pointers for `ProfileTreeNode`
2. Split single static method into multiple smaller methods of one class, less cognitive load and smaller context window
Reviewed By: robhogan
Differential Revision: D72401690
fbshipit-source-id: a1eed5501349dcd811661d91f3bf126a0daaacf2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50538
Promises created from `Linking.sendIntent` calls never resolve, leaving them dangling. This change fixes the issue in two spots:
1. By calling promise.resolve directly after the startActivity call
1. By wrapping startActivity in a try/catch so any exceptions thrown are forwarded to the promise as a rejection
Changelog: [Android][Fixed] - Ensure Linking.sendIntent promises resolve or reject
Reviewed By: NickGerleman
Differential Revision: D72606918
fbshipit-source-id: cd437bf65bb631bc04f99b4d2e3d637f7e98b25e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50556
This class is effectively unused, I'm removing it.
It was package private also so no one in OSS could easily use it.
Changelog:
[Internal] [Changed] - Remove unused JSDebuggerWebSocketClient
Reviewed By: GijsWeterings
Differential Revision: D72567055
fbshipit-source-id: aa2fa62c05488d1560c0acfa0b21e2d934c34be2
Summary:
Looks like Jest E2E had significant issues with this test on both android and ios RNTester. I think it's because the view with the testID did not have any contents, which means the accessibility tools have trouble getting the proper context from it. By changing it to a nested view (with some padding to better inspect the borders, since that's what's important in this test) I think we have a better, more stable test case this way
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D72571911
fbshipit-source-id: a85266cf4a1696fdaedcc97ed2a7a05f086d35bd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50549
As part of D72558674, I made SurfaceHandlerBinding.setProps nullable, to align with D71979601 - but I didn't realize this wasn't properly handled on the JNI side.
Changelog: [Android][FIxed] Fix crash when passing null initialProps
Reviewed By: lenaic
Differential Revision: D72632625
fbshipit-source-id: 82db1791ceb7c96248b6eea2eb1e6395edc308a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50528
Changelog: [internal]
This adds basic documentation for the IntersectionObserver Web API implementation in React Native.
Reviewed By: lenaic
Differential Revision: D72573107
fbshipit-source-id: 14ed318ae3691550bbe14a6da1184013ce0c60a9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50527
Changelog: [internal]
This just defines an outline for the expected docs to be added to RN.
Reviewed By: GijsWeterings
Differential Revision: D72573497
fbshipit-source-id: a8e1c2cc0c6b966656d1089cd33b547174ace873
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50525
Changelog: [internal]
Just a rename of the file and moving relevant documentation to the README.
Reviewed By: GijsWeterings
Differential Revision: D72562795
fbshipit-source-id: d675037376a0345dd7d178cf5863f4093eb74542
Summary:
This diff migrates the following file to Kotlin - CxxInspectorPackagerConnection
as part of our ongoing effort of migrating the codebase to Kotlin
Changelog:
[Internal] [Changed] - CxxInspectorPackagerConnection to Kotlin
Reviewed By: rshest
Differential Revision: D72566596
fbshipit-source-id: 046e7549841f64d73fed56d8bc8d70f2d3ea63e8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50519
This diff migrates the following file to Kotlin - MultipartStreamReader
as part of our ongoing effort of migrating the codebase to Kotlin
Changelog:
[Internal] [Changed] - MultipartStreamReader to Kotlin
Reviewed By: rshest
Differential Revision: D72561124
fbshipit-source-id: d616bfc547ea6a773ebc1c45f97111ae7c7ec85a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50526
This change wants to automate the rotation of the issue triaging squad on Discord.
This is taking us a few minutes every week to rotate the oncall.
This change can save us some time.
The configuration file format is supposed to be like this:
```
{
"userMap": {
"discord-username1": "discord-id1",
"discord-username2": "discord-id2",
"discord-username3": "discord-id3",
"discord-username4": "discord-id4"
},
"schedule": {
"date1": ["discord-username1", "discord-username2"],
"date2": ["discord-username3", "discord-username4"],
}
}
```
## Changelog
[Internal] - Automate the issue triage oncall rotation
Reviewed By: cortinico
Differential Revision: D72569435
fbshipit-source-id: 435c13350cf503e99302775674e78a20e328e68d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50518
This diff migrates the following file to Kotlin - BridgeDevSupportManager
as part of our ongoing effort of migrating the codebase to Kotlin
Changelog:
[Internal] [Changed] - BridgeDevSupportManager to Kotlin
Reviewed By: arushikesarwani94
Differential Revision: D72558373
fbshipit-source-id: 07a16dc479e967677b1aab8a6d4a4366994fd490
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50522
This diff migrates the following file to Kotlin - BridgelessDevSupportManager
as part of our ongoing effort of migrating the codebase to Kotlin
Changelog:
[Internal] [Changed] - BridgelessDevSupportManager to Kotlin
Reviewed By: arushikesarwani94
Differential Revision: D72558016
fbshipit-source-id: 9c84f89dfca03991b1feb6f8c9ffe846350aafed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50520
This diff migrates the following file to Kotlin - DebugOverlayController
as part of our ongoing effort of migrating the codebase to Kotlin
Changelog:
[Internal] [Changed] - DebugOverlayController.java to Kotlin
Reviewed By: arushikesarwani94
Differential Revision: D72557349
fbshipit-source-id: dd4a1c7204206189c176b36f81c6d54f5f780b10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50521
This diff migrates the following file to Kotlin - DebugCorePackage
as part of our ongoing effort of migrating the codebase to Kotlin
Changelog:
[Internal] [Changed] - Migrate to Kotlin - DebugCorePackage
Reviewed By: javache
Differential Revision: D72556867
fbshipit-source-id: dc37538da7089f532dc3a617a8e7dbccc6e187e3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50402
While investigating pointer events, I noticed that all Android views fire `onPointerLeave`/`onPointerEnter` in rapid succession on every button press. This is because Android fires `ACTION_HOVER_EXIT` on every frame before firing `ACTION_DOWN` (in the same frame). The logic in JSPointerDispatcher needed to be updated to account for this.
Unfortunately, `ACTION_HOVER_EXIT` events have no means of distinguishing between whether they were driven by the mouse actually leaving the view's bounds or by a button press. Some OS implementations fire this event on the frame just before leaving the view's boundaries while others fire after, so pure X/Y position isn't helpful enough. The button state property on `ACTION_HOVER_EXIT` also never gets set in some OS.
To work around this issue, this change posts a callback to the very next frame after receiving `ACTION_HOVER_EXIT`. If no `ACTION_DOWN` event was received in the same frame, it calls all the way through the existing logic. But, if an `ACTION_DOWN` event *is* received, we compare the event timestamps and if they match we don't post `onPointerLeave`.
Changelog: [Android][Fixed] - Prevent onPointerLeave from dispatching during button presses
Reviewed By: vincentriemer
Differential Revision: D72078450
fbshipit-source-id: dcc7cfa4086963ed8599147d60d8406c54cd5d69
Summary:
Since we've made SurfaceHandler internal, there's no need to maintain a separate interface between it and the actual Binding implementation class.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D72558674
fbshipit-source-id: d7ac15b0e608c3aa7d05e46f1078cef1e154f846
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50481
It's here! kinda...this only works internally right now, so no OSS usage which is explicitly gated to be off. We can't really avoid exposing the types so here we are.
Changelog: [Internal]
Reviewed By: jorge-cab
Differential Revision: D72428425
fbshipit-source-id: 9642e5db46f9bd34ff505b0e37987da52857b6e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50303
This feature is being tested internally right now. We cannot really avoid exposing the type but we are going to make this no-op for now in OSS until we are confident we can roll it out fully
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D71919847
fbshipit-source-id: b1730b8af5180c4513ce1f0d58b3a6526fffed84
Summary:
I was helping a team with some keyboard link accessibility and they had this strange bug where a link was not keyboard accessible despite having `accessible={true}`. Something that fixed it for them was adding an `accessibilityLabel`, which makes no sense.
Turns out there is a bug when the link encompasses the entirety of the `Text` component. We have a special case for handling links of this manner, and right now we are not setting the `frame` property which is responsible for outlining the element when it takes focus.
This property is not one defined by UIKit, rather it is defined in RCTAccessibilityElement. We use it to derive the accessibilityFrame which has to be in screen coordinates. If you do not set the frame property then it is supposed to use the bounds of the container. This does not work properly, seemingly bc the name "frame" gets mangled internally in UIKit leading to UB. I changed the name the "something" and it works.
To remedy this lets just change the name
Changelog: [iOS] [Fixed]
Reviewed By: javache
Differential Revision: D72338838
fbshipit-source-id: da91d0c28baeb6765d4d604f3e47c91952167f9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50516
This diff migrates the following file to Kotlin - DevSupportManagerFactory
as part of our ongoing effort of migrating the codebase to Kotlin
Changelog:
[Android] [Changed] - Migrate to Kotlin - DevSupportManagerFactory - We couldn't find any implementation of this class in OSS. Some Kotlin implementers might have to change the method signatures. However this interface is not supposed to be extended in OSS.
Reviewed By: javache
Differential Revision: D72556310
fbshipit-source-id: 35d1ed3c332296d3be5244fdab92a890d7ea3c40
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50517
This diff migrates the following file to Kotlin - ReactInstanceDevHelper
as part of our ongoing effort of migrating the codebase to Kotlin
Changelog:
[Android] [Changed] - Migrate to Kotlin - ReactInstanceDevHelper. Some users implementing this class in Kotlin could have breakages. As this is a devtools/frameworks API we're not marking this as breaking.
Reviewed By: javache
Differential Revision: D72555226
fbshipit-source-id: e7e5523c56de8697def0a509c03e9fe89c6d5839
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50514
When building React Native for mac catalyst on intel architecture, we are observing a build failure in RCTInstance.
See issue: https://github.com/facebook/react-native/issues/50388
Apparently, the compiler don't understand that `errorData[@"isFatal"]` is a BOOL, so we are helping it by extracting the `boolValue`.
## Changelog:
[iOS][Fixed] - Avoid build failure on Catalyst (x86_64)
Reviewed By: cortinico
Differential Revision: D72558024
fbshipit-source-id: 152d89b02ae250a8ae54fe2df658c018d5f63f45
Summary:
Changelog: [internal]
This is stable after the last couple of fixes, so we can enable it by default. Enabling this just improves the accuracy of `IntersectionObserver` and the Event Timing API, and we still haven't shipped those to stable.
Reviewed By: GijsWeterings
Differential Revision: D72561256
fbshipit-source-id: 4b505f1df9c7c495d316e6fbf1498af94aaca959
Summary:
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made NetworkingModule.java nullsafe
Reviewed By: cortinico
Differential Revision: D71979590
fbshipit-source-id: 0ddf764f4707d2ee76ab99bc1a09a4e2a7e6b794
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50347
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D71979581
fbshipit-source-id: 4ed264ff43794b6aafc2a0ee419a660a6b5b0440
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50366
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made BlobModule.java nullsafe
Reviewed By: cortinico
Differential Revision: D71979598
fbshipit-source-id: bbef5548d05e0b77ea03cf72f41a384fe7294d59
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50364
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D71979588
fbshipit-source-id: f5ec8bced87ea0c6c1c193be51ebc78396388d0e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50370
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made TurboModuleManager.java nullsafe
Reviewed By: cortinico
Differential Revision: D71979605
fbshipit-source-id: b8da8f1ad12f5f6d63e7bd876d7c4912d69a4c4d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50358
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D71979595
fbshipit-source-id: 19bfcea537b7b62536eafa8e1d0b3f8b50666e22
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50357
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made TurboModuleInteropUtils.java nullsafe
Reviewed By: cortinico
Differential Revision: D71979599
fbshipit-source-id: ffd7006f28db4daf8cd47ce1cd8ff6e3192c0ad1
Summary:
Per discussion in D71979599
Changelog: [General][Fixed] Throw ParsingException when ReactModule doesn't conform to TurboModule invariants
Reviewed By: cortinico
Differential Revision: D72383857
fbshipit-source-id: 2d0282b136312d414234246584d2ae60858955b6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50367
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D71979600
fbshipit-source-id: be36f4c409a0423b3d3ccdf2c28d96c7a3f50201
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50512
Reland of D72389708
This renames the method to be more aligned to the fact that we're using this entrypoint both for internal
and for OSS users.
I've also added a `assertLegacyArchitectureOnlyWhenMinifyEnabled` that will run only for internal builds.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D72552028
fbshipit-source-id: 2594df9ef8056f9931960117770c4b7cddd4e922
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50511
Reland of D72384347
ReactMarker is currently loading the whole `reactnativejni` which we should not be loading in NewArch.
This is resulting in a warning fired for all the NewArch users with `legacyWarningsEnabled`.
I'm cleaning this up by moving it inside `reactnativejni_common`.
Changelog:
[Internal] [Changed] - Move ReactMarker to `reactnativejni_common` as it's used in NewArch also
Reviewed By: javache
Differential Revision: D72552075
fbshipit-source-id: bbc75aada1564f6f54ea70a8dd4f5145d4a3ffaa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50495
Changelog: [internal]
This migrates the last remaining usages of these polyfills to the built-in classes.
Reviewed By: yungsters
Differential Revision: D67828652
fbshipit-source-id: 5ff039d7413aed49d882ff03e722531cdd195488
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50494
Changelog: [internal]
Removes the dependency on the `event-target-shim` npm package now that we're using a custom implementation within `react-native`.
Reviewed By: yungsters
Differential Revision: D67828636
fbshipit-source-id: 8727f8caa2bd4badd7162eb7b993dcc768e74b85
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50485
Changelog: [internal]
This cleans up the experiment to test the new implementations of `XMLHttpRequest`, `FileReader` and `WebSocket` using the built-in `EventTarget` definition.
This effectively replaces the legacy implementations with the ones using the built-in `EventTarget` class in stable.
Reviewed By: yungsters
Differential Revision: D68625225
fbshipit-source-id: 7ccefe5d8612baca283146cdbca7f7f1d51b4ffa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50499
We enocuntered an issue internally where the `RCTInstance` was ready before the modules were done registering statically.
When this happens, it can occur that we iterate over an array that is going to be modified.
With this change, we are introducing several changes:
- By default the logs are not outputted, so the array is not going to be populated
- we are making a copy of the array before we start iterating, so even if the original reference is updated, the iteration is safe
- we are not emitting logs if in release mode. This will protect production from this issue. Also, these warns are not going to be useful in production anyway.
## Changelog:
[Internal] - fix crash when RCTInstance is ready while modules are initialized
## Facebook:
This fixes T220205371
Reviewed By: Abbondanzo
Differential Revision: D72512518
fbshipit-source-id: 32e561111d034455a6a778d05af4a96602b74bfb
Summary:
ReactMethod will remain to be supported in the New Architecture, we are unmarking it
changelog: [internal] internal
Reviewed By: shwanton
Differential Revision: D72491698
fbshipit-source-id: 656b36711dcdfc0a776ac05b1f7f431d6416f9dd
Summary:
Changing these object arguments to `$ReadOnly` permits passing in values that are `$ReadOnly` (e.g. `payload` argument to `enqueueNativeEvent`).
Changelog:
[Internal]
Reviewed By: lyahdav
Differential Revision: D72474879
fbshipit-source-id: 27341131724f4f572b78563975774a5b20dee8f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50489
ParagraphState is shared between ParagraphTextView and ParagraphComponentView, but we only need one copy. We were forgetting to clear this on ParagraphTextView when recyling.
Changelog: [iOS][Fixed] ParagraphState is correctly deallocated when recycling Text
Reviewed By: cipolleschi
Differential Revision: D72454038
fbshipit-source-id: 43afa4eaea183cc66b64d16870c1403debff985a
Summary:
# Changelog: [Internal]
We should avoid allocating multiple of these, since they can get really big.
`RuntimeSamplingProfile` may contain up to 10k of `Sample` for every second of sampling. Every `Sample` may contain up to 500 of call frames, each of which may have a copy of strings like `functionName` and `url`.
> NOTE: The actual logic for deduplicating strings and not allocating too many of them is not part of this diff and will be published separately. Even with deduplication, there is a reason to avoid copying the profile.
Reviewed By: javache
Differential Revision: D72254364
fbshipit-source-id: fa7907fb5cabbd2ac99d3e4e05a93bcb07f7f7c7
Summary:
# Changelog: [Internal]
This was changed in D70402439.
Since these hexadecimal numbers are serialized as strings, we don't need to includes empty bits, this could save us few kilobytes of the trace in json format.
Also, this is the default for Chromium, so we shouldn't probably diverge.
`0x00000001` -> `0x1`
Reviewed By: robhogan
Differential Revision: D72459307
fbshipit-source-id: 5cc4ccbe25cdc16946e745184ad17dfcd51c6449
Summary:
# Changelog: [Internal]
`"ProfileChunk"` trace events can actually be big, depending on the number of the unique nodes reported in a single chunk.
We should avoid copying it for memory and performance reasons.
Reviewed By: robhogan
Differential Revision: D72459306
fbshipit-source-id: db3583c6c6397bb6ee8a0eb33a06a48bc10e82b8
Summary:
This renames the method to be more aligned to the fact that we're using this entrypoint both for internal
and for OSS users.
I've also added a `assertLegacyArchitectureOnlyWhenMinifyEnabled` that will run only for internal builds.
Changelog:
[Internal] [Changed] -
Reviewed By: mdvacca
Differential Revision: D72389708
fbshipit-source-id: 23830df2f71cc816c7ca178b735a930e794efe47
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50471
ReactMarker is currently loading the whole `reactnativejni` which we should not be loading in NewArch.
This is resulting in a warning fired for all the NewArch users with `legacyWarningsEnabled`.
I'm cleaning this up by moving it inside `reactnativejni_common`.
Changelog:
[Internal] [Changed] - Move ReactMarker to `reactnativejni_common` as it's used in NewArch also
Reviewed By: javache
Differential Revision: D72384347
fbshipit-source-id: 83965c3e4eb7847184856485d1cc1c478b2888d5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50479
In D72273163 the only reference to RN feature flag `throwExceptionInsteadOfDeadlockOnTurboModuleSetupDuringSyncRenderIOS` was removed, so this diff removes the feature flag. Also it removes remnants of D69922771 which are no longer needed.
Changelog: [Internal]
Reviewed By: shwanton
Differential Revision: D72427164
fbshipit-source-id: 398583ac14910a396839140c06011efa084fe04d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50470
This diff introduces a new property called `legacyWarningsEnabled` for `gradle.properties` that
toggles the Legacy Arch warnings for users.
I've also introduced a new `ReactNativeApplicationEntryPoint` that is generated by RNGP. This class
effectively wrap `DefaultNewArchitectureEntryPoint` by setting warnings and also invoking SoLoader.
It will reduce the errors in the user space.
As of now warnigns appear in Logcat, but I'm looking into adding some UI in a subsequent diff.
Changelog:
[Android] [Added] - Add a `legacyWarningsEnabled` property to enable Legacy Warnings on NewArch
Reviewed By: mdvacca
Differential Revision: D72383907
fbshipit-source-id: bcd659a23ec5b468958124f0f6650ff72d01ce81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50490
Changelog: [internal]
This follows the good practice in Fantom tests.
Reviewed By: javache
Differential Revision: D72454795
fbshipit-source-id: 412ee53f61073c63295a23fd7decd6f19a72bf99
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50484
Changelog: [internal]
This cleans up the `enableUIConsistency` feature flag (shipping the feature) after we verified it was stable and performance in production.
Reviewed By: yungsters
Differential Revision: D72387602
fbshipit-source-id: 11d225d962f7e3a47e858d039b7fd5c70a6cadfd
Summary:
Found this unused class with static code analysis. It is internal and has no OSS usages, so it seems like it can be safely deleted.
## Changelog:
[INTERNAL] - Remove unused com.facebook.react.fabric.mounting.mountitems.SendAccessibilityEvent class
Pull Request resolved: https://github.com/facebook/react-native/pull/50478
Test Plan:
```sh
yarn test-android
yarn android
```
Reviewed By: fabriziocucci
Differential Revision: D72445544
Pulled By: javache
fbshipit-source-id: ebbb035da22111e41b04131596d3ec61d4e1423c
Summary:
This PR adds a bunch of OSS libraries to the testing matrix.
We use these OSS libraries internally in our Meta application, so we want to make sure that our changes don't break them.
## Changelog:
[Internal] - Add OSS libraries used internally to the testing matrix
Pull Request resolved: https://github.com/facebook/react-native/pull/50477
Test Plan: GHA - Tested in a sample job firts:
Reviewed By: cortinico
Differential Revision: D72401647
Pulled By: cipolleschi
fbshipit-source-id: c0c2f4b2525b58822c2cc6225fe64210a9513275
Summary:
Use nightlies to test reanimated with RN nightlies
## Changelog:
[Internal] - use reanimated nightlies together with react native nightlies to spot breaking changes
Pull Request resolved: https://github.com/facebook/react-native/pull/50428
Test Plan: GHA - Tested triggering it from a PR in this job: https://github.com/facebook/react-native/actions/runs/14197051228?pr=50428
Reviewed By: cortinico
Differential Revision: D72243345
Pulled By: cipolleschi
fbshipit-source-id: 297ec0073dfc32ec5a5e90630b93867fac0b564f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50480
The map in the script has an if in it checking for proper release channel. For feature flags that do not pass this if, they do not have an alternative return, so `map` just maps this to `undefined`. That means there is still an element in this array which gets joined by 2 new lines. As a result every new feature flag will add 2 new lines of white space making these files look rather silly.
Fix is to filter undefined out.
Changelog: [Internal]
Reviewed By: shwanton
Differential Revision: D72427349
fbshipit-source-id: 87e1d63c8854652296ce9160ab7171a948983d54
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50467
Changelog: [Internal]
Adds a transform that is able to divide properies of interaces, types and classes into sections:
- properties
- properties typed as functions
- methods
ands sorts them alphabetically within the groups.
Reviewed By: huntie
Differential Revision: D72381050
fbshipit-source-id: 20781dc44e19e63cbb5706a02e513fc0e9bb2412
Summary:
The original diff caused some breakages.
Changelog: Backout [Android][Fixed] Made Task.java nullsafe
Differential Revision: D72433889
fbshipit-source-id: 53f7e730455ccaadde197a0f400fc6e834c1ffdd
Summary:
Image component was missing an override which enables setting accessibility values and properties.
The main issue is the lack of this prevented Image component from being accessed by VoiceOver.
Changelog: [iOS][Fixed] - Fixed accessible prop no-opts on Image components
Reviewed By: joevilches
Differential Revision: D72410952
fbshipit-source-id: 5612205aca1710fe4bfed6132efeb59065ebf0b3
Summary:
Mark concrete classes of shadow node as LegacyArchitecture
These classes won't be included in legacy architecture apks
changelog: [internal] internal
Reviewed By: joevilches, mlord93, Abbondanzo
Differential Revision: D72351188
fbshipit-source-id: 4727cdd1486b2fafb87fe3b512440af3264ad189
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50249
This change introduces a flag to turn off the legacy architecture warning if they become too annoying.
The flag can be set in the Info.plist of the React Native architecture and it is controlled by the key: `RCTLegacyWarningsEnabled`.
* If the key is missing or with a value of `YES`, logs are enabled
* If the key has a value of `NO`, react native will not output any log.
We decided to use the Info.plist file to configure the logs because in that way it will work also with React Native prebuilds.
## Changelog:
[iOS][Added] - Add flag to enable or disable legacy warning.
Reviewed By: cortinico
Differential Revision: D71814001
fbshipit-source-id: b6ae6b032ff7add6bae3d73dba490adeaceffa1f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50244
This change adds warning to React Native whenever a component is loaded using the interop layer.
The warning is emitted only once per component.
## Changelog:
[iOS][Added] - Add warnings when components are loaded using the interop layer.
Reviewed By: cortinico
Differential Revision: D71808323
fbshipit-source-id: ce864f73c7789512d4e5e67368b5aa67f94e0570
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50441
When useFabricInterop is disabled, deleting component descriptors in Component Registry is failing since https://github.com/facebook/react-native/pull/47321 removed the Fabric Interop check from the ComponentDescriptorRegistry.cpp which was added earlier in https://github.com/facebook/react-native/pull/42294
Adding back the logic of Fallback component descriptor and error for the same.
Changelog:
[General][Fixed] Fixing Fabric Interop layer bug defaulting to UnstableLegacyViewManagerAutomaticComponentDescriptor irrespective of feature flags.
Reviewed By: javache
Differential Revision: D72266017
fbshipit-source-id: 1f3093d37dbe2b96ca26aa80c0a59d5c3026e9cf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50440
Making the following changes to definition of `useFabricInterop` feature flag:
1. Changing default value to True for both internal and OSS.
2. Changing expected Release Value to false since aiming at disabling interop finally with new architecture strict mode.
3. Hence changed the `ossReleaseStage` from `canary` to `none`
4. Removing all existing over-rides of `useFabricInterop` to True now that the default is True itself.
5. Adding the over-ride to false for Facebook since that doesn't need the interop as is already in new architecture without interop mode.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D72266336
fbshipit-source-id: ff16c5b9d0f39837706a86bd0d178a66a8f2e920
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50448
In preparation for API snapshot generation and README documentation, move into dedicated dir.
Changelog: [Internal]
Reviewed By: iwoplaza
Differential Revision: D72306094
fbshipit-source-id: 3663f9ba9987a59918bae54cfc5a27555b90a9f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50355
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made Task.java nullsafe
Reviewed By: cortinico
Differential Revision: D71979582
fbshipit-source-id: f4104e5deb1d0538fe8b4968dc1411036a3e9634
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50361
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D71979592
fbshipit-source-id: 07f3b74362b85803eec90c0c974a88d061d8e816
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50354
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made ReconnectingWebSocket.java nullsafe
Reviewed By: cortinico
Differential Revision: D71979606
fbshipit-source-id: d71e26fe37bdf5abbe7b933d0fee25e05d0da87d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50368
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D71979580
fbshipit-source-id: 0eaeaf327421db47a8499a9b6154fa6d5ab8a4fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50353
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made DialogModule.java nullsafe
Reviewed By: cortinico
Differential Revision: D71979604
fbshipit-source-id: 556b2b10ef0879bf7cd4eac6eaf3c9c3cc1c5413
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50351
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D71979584
fbshipit-source-id: 52e29ac578edcbcd9bd14de4d327564d54f421cf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50352
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made FileReaderModule.java nullsafe
Reviewed By: cortinico
Differential Revision: D71979585
fbshipit-source-id: 3bef5ff48d1d27838d2668367785a85b2b863f05
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50360
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D71979587
fbshipit-source-id: 50c248def66360f2a063d9eb213cfae5d6787943
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50363
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made BlobProvider.java nullsafe
Reviewed By: cortinico
Differential Revision: D71979597
fbshipit-source-id: a6fba0d83f3558b3bed21de484b59ee6b17bb643
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50350
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D71979586
fbshipit-source-id: 155fc505d131acc1fa3444692928448b8567cbd5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50362
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made MountingManager.java nullsafe
Reviewed By: cortinico
Differential Revision: D71979607
fbshipit-source-id: 0a41e3a6405500c29ec4710ea3ed57e6705f1b4a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50356
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D71979593
fbshipit-source-id: 4dbe6ae7f44694b77ebf64170cb71393b532b981
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50348
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made MountItemDispatcher.java nullsafe
Reviewed By: cortinico
Differential Revision: D71979589
fbshipit-source-id: 0133fa6bd56d5595e8397029517b43d0a95b260b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50349
Added nullsafe FIXMEs for easier reviewing of next diff, where we fix them
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D71979596
fbshipit-source-id: a463b916328d4aecb6b8d91c37be170a8f6fb355
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50437
Currently we do have `NativeArray`, `NativeMap` being tightly coupled with the old arch (i.e. everything inside `libreactnativejni.so`).
Those classes however are primitives used also by the New Arch and they should be accessible even without the bridge infra.
I've noticed this dependency while working on the Legacy Arch warnings.
Here I'm refactoring those primitives to live in a separate `libreactnativejni_common` module that can be loaded indipendently.
Changelog:
[Internal] [Changed] - Decouple NativeMap and NativeArray from `reactnativejni`
Reviewed By: javache, mdvacca
Differential Revision: D71635967
fbshipit-source-id: 64b0fc26491977a0e6c5be4688ff91969c81d680
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50436
Changelog: [Internal]
`is_idle` was a confusing concept that I didn't find useful when researching why disconnections happen. Instead, I'd like to know when the last communication with inspector proxy took place.
Reviewed By: hoxyq
Differential Revision: D72251072
fbshipit-source-id: 10f83bde6c8f3ed4b661bcfbef57f86f34039e5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50435
Changelog: [Internal] when reporting how many cdp messages passed inspector proxy, also report their total size
Reviewed By: hoxyq
Differential Revision: D72245498
fbshipit-source-id: 777274527b7e180c984b11414bec54d0e6f9d27b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50464
Runners in GHA has been updated by github and they now ship with CMake 4.0. (actions/runner-images#11926)
This version is not compatible with React Native, so we are pinning cmake to 3.36.1
## Changelog:
[Internal] - Pin cmake to 3.36.1
Reviewed By: cortinico
Differential Revision: D72379834
fbshipit-source-id: ab09009102118e6590f02cf57fa6f9149482f62b
Summary:
We should not be adding files inside Jest's __mocks__ folder inside the generated podspec.
This takes care of it.
Context: https://github.com/reactwg/react-native-new-architecture/discussions/282
Changelog:
[Internal] [Changed] - Exclude __mocks__ folder from codegen podspec generation
Reviewed By: fabriziocucci
Differential Revision: D72318736
fbshipit-source-id: 73a8c3f3cd84794ead9e7ce622f7ac4299d943f1
Summary:
Currently markers are ignored in RN apps. Utilizing newly added instant track event type for sytrace so the markers are displayed nicely on the timeline. The time delta decoding will be addressed separately for proper timestamp assignment during backend processing.
## Changelog:
[Internal] [Added] - Support for logging mark events with fbsystrace
Reviewed By: javache
Differential Revision: D72094455
fbshipit-source-id: 4cd8f53ddd0b40dfded8d6d8df367698515588c7
Summary:
Make RCTScreenSize and RCTScreenScale initialize during React Native init.
After this diff, there shouldn't be any sync dispatches to the main queue. So, we can just introduce an error into RCTUnsafeExecuteOnMainQueueSync.
## Note
If people manually dispatch to the main queue like so, react native can still deadlock:
```
dispatch_sync(dispatch_get_main_queue(), ^{});
```
Changelog: [Internal]
Reviewed By: lyahdav
Differential Revision: D72273163
fbshipit-source-id: 6211851b380b4f5cd556f48f4d717a6f53d65d32
Summary:
I'll need to use feature flags in this file. And those are only accessible from c++.
Changelog: [Internal]
Reviewed By: lyahdav
Differential Revision: D72326982
fbshipit-source-id: 4c9dfd0e5baa69d979b12914f289d58be6e123a8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50432
This diff adds lint rule to keep React imports consistent across the react native repo. There is a fix suggestion in case if only React is imported.
Changelog:
[internal]
Reviewed By: NickGerleman
Differential Revision: D72244838
fbshipit-source-id: b783d6320520d76c2e5d5ce5c5b7c2a4548d50fe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50433
Make React imports consistent across react-native source code to also align with Flow tooling.
flow-api-translator adds `import * as React from 'react';` if there is no React import and React namespace has to be used after translation.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D72238732
fbshipit-source-id: 5f8cfeab26f397684b1d802731729be7071b5da7
Summary:
This method is redundant. You could just call RCTScreenScale()
Changelog: [iOS][Removed] Delete RCTComputeScreenScale
Reviewed By: philIip
Differential Revision: D72258778
fbshipit-source-id: 0b469169efc4f2def85b2e6b736f3c4570e6b428
Summary:
This is dead code. Let's remove this for now.
This api is unsafe: if it's called from a non-ui thread, it may dispatch to the ui thread synchronously.
Changelog: [iOS][Removed] - Remove RCTFloorPixelValue
Reviewed By: NickGerleman
Differential Revision: D72260694
fbshipit-source-id: d032917643c957a395ee380ef925a047abd5dace
Summary:
## Problem
If RCTScreenScale() is called from a non-ui thread, it will synchronously dispatch to the ui thread.
If the calling thread is the javascript thread, this could deadlock React Native.
## Changes
Move the method calls to the ui thread.
In the future, once all call-sites are migrated to the ui thread, we will just make these methods assert that they're being called from the ui thread.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D72177192
fbshipit-source-id: daadf713f059d33e8fff4559b4184f9d4b6b420d
Summary:
In expo-updates, we would like to handle exceptions on app launch. We used to do this by reassigning our own `DefaultJSExceptionHandler` to the property on the `ReleaseDevSupportManager `. This class has been migrated to kotlin and is now final so we can no longer do this. Instead of having the `defaultJSExceptionHandler` typed as `DefaultJSExceptionHandler` we'd like to change it to the interface, `JSExceptionHandler` so we can do this https://github.com/expo/expo/blob/93b7e9b1724a7be11b9d79c0313a2e5a2fd5e5bf/packages/expo-updates/android/src/main/java/expo/modules/updates/errorrecovery/ErrorRecovery.kt#L118C82-L118C97
## Changelog:
[ANDROID] [CHANGED] Change `defaultJSExceptionHandler`'s type to `JSExceptionHandler` on the `ReleaseDevSupportManager`
Pull Request resolved: https://github.com/facebook/react-native/pull/50400
Test Plan: RNTester runs without issue in a release build.
Reviewed By: huntie
Differential Revision: D72173667
Pulled By: cortinico
fbshipit-source-id: 978fd696322432e638a90014ff3c8c2b09fae761
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50392
## This diff
Defines an exports field for the "react-native/virtualized-lists" package. Limits internal use of subpath
imports to virtualized-lists package, and exports all currently used APIs one the root level.
Changelog:
[General][Breaking] - Subpath imports to the internal react-native/virtualized-lists package are not allowed.
Reviewed By: huntie
Differential Revision: D72162344
fbshipit-source-id: 828dab8e569f019fc48084af475e152b898f5bb5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50391
No need for the indirection here of a heap allocated pointer.
Since we have the RootComponentDescriptor we generally don't need it in any other component registry.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D72058916
fbshipit-source-id: 0c29f26f4c56c4353eda251fe06a475e3b6085da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50379
## Changelog:
[Android] [Added] - Allow invoking `synchronouslyUpdateViewOnUIThread` from c++ via `UIManager`
implementation is provided by SchedulerDelegate on the platform
Reviewed By: javache
Differential Revision: D71648772
fbshipit-source-id: bba0f7e9e2deafd074d28ff5cece6b7738c4d123
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50320
Define `"exports"` field on the main `react-native` package.
**Notes**
Module resolution should be equivalent to the previous implicit `"main"` field (backwards compatible).
- Exports all module subpaths to JavaScript (Flow) source files, with and without `.js` suffix (unchanged ✅)
- These are restricted to the `flow/` and `Libraries/` subdirectories (ℹ️ this should be unchanged, matching any JS imports apps may have today)
- Still includes 3P integration scripts such as `./jest-preset.js` and `./rn-get-polyfills.js` (unchanged ✅)
- Exports `./package.json` (unchanged ✅)
- TypeScript should:
- fall back to the `"types"` field (unchanged ✅)
- OR to `"."`,`"./*"` when Package Exports support is enabled via `compilerOptions`, and use the *adjacent `.d.ts` file* (unchanged ✅)
Changelog:
[General][Breaking] - The `react-native` package now defines package.json `"exports"`.
- While these expose existing JavaScript and TypeScript modules, this change may affect deep imports of non-JS files via Node in third party tools.
- Imports from `src/` and `src/private/` directories are disallowed.
Reviewed By: robhogan
Differential Revision: D71968187
fbshipit-source-id: 28ff941692d1822a916457c4fb891e200e3bca61
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50308
CxxCallbackImpl is used in new architecture, in this diff i'm removing LegacyArchitecture annotation from CxxCallbackImpl class
changelog: [internal] internal
Reviewed By: alanleedev
Differential Revision: D71820292
fbshipit-source-id: 54748cc23aa7091841a025e41ad43dcaa60923cd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50376
This makes a couple of tweaks to `SafeReleaseJniRef` to let it be used in more places:
1. Add a default ctor for null state
2. Bridge `get()` to return raw JNI ref, for use when calling Java functions directly (compared to current use case of hybrid objects)
3. Keep JNI environment attached to thread longer term, instead of repeated attach/detach, to allow use for higher frequency objects.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D71933838
fbshipit-source-id: 622cc70d2d7483475406314abcbcf92d3d2ff227
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50330
Changelog: [Internal]
Make the error reported when a debugger is created for a device that does not exist generic, and not including any specific details to make them easier to aggregate
Reviewed By: hoxyq
Differential Revision: D71979796
fbshipit-source-id: 88badc51043e35ff91d7db81c5966ed5ffce9109
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50341
Ships tge `scheduleAnimatedCleanupInMicrotask` feature flag, which changes the cleanup of `AnimatedProps` to occur in a microtask instead of synchronously during effect cleanup (for unmount) or subsequent mounts (for updates).
Changelog:
[General][Changed] - When an `Animated` component is unmounted, any completion callbacks will now be called in a microtask instead of during the commit phase.
Reviewed By: javache
Differential Revision: D71942778
fbshipit-source-id: cbe636d5cff84dfeca2f21ead374609c536e91ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50339
Explicitly sets the default `reactRuntimeTarget` when invoking `require('hermes-parser').parse` so that it'll be easier to find these configurations when upgrading to `'19'`.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D72006705
fbshipit-source-id: 4994917152a2a4a767b871d4a36092c0c5391324
Summary:
This workflow bumps the Podfile.lock automatically when a new release happens.
I decided not to use a js script in this case because all the commands are bash commands for git or cocoapods, therefore wrapping them all in a JS file would have added little to no benefit and only overheads.
## Changelog:
[Internal] - Bumps podfile.lock automatically
Pull Request resolved: https://github.com/facebook/react-native/pull/50345
Test Plan:
GHA - tested as a separate workflow first, hardcoding the latest RC
https://github.com/facebook/react-native/actions/runs/14127895380/job/39581024861?pr=50345
The flow correctly fails as the Podfile.lock has already been bumped in the release branch.
Reviewed By: fabriziocucci
Differential Revision: D72050261
Pulled By: cipolleschi
fbshipit-source-id: 5c0666e80b037319c365fcf4d52e8e367c3445ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50337
# Changelog: [Internal]
This should not have any functional changes, it only prevents the WebSocket from being killed on Android, when we are sending Profile-related Trace Events.
For large traces, a single message could be more than 16MB, because we send a unique string url for every call frame.
Reviewed By: huntie
Differential Revision: D71993748
fbshipit-source-id: f0bfddfb0bb87631e72b573142abdf0d7d87ba48
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50335
Changelog: [internal]
This defines the internal technical documentation for the MutationObserver API, as an example of how to define docs using the new strategy and structure.
Reviewed By: javache
Differential Revision: D71890748
fbshipit-source-id: 3ef19c784dff7aea7a2e2d08302640d5eefacc30
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50334
Changelog: [internal]
This updates the documentation for the feature flag system to adhere to the new documentation strategy and structure.
Reviewed By: javache, rshest
Differential Revision: D71889753
fbshipit-source-id: 7ff47cf613ac01012e7329485d2b97e997a97c07
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50333
Changelog: [internal]
This defines a placeholder for the main entrypoint for the React Native internal technical documentation.
Reviewed By: javache, mdvacca, rshest
Differential Revision: D71889755
fbshipit-source-id: 453518a0b7ec2cf433884a87446a7a622418d0b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50332
Changelog: [internal]
This defines a detailed strategy on how to approach internal technical documentation in React Native, including defining a template for subsystem documentation.
Reviewed By: javache, rshest
Differential Revision: D71889754
fbshipit-source-id: 5ce630b2e71f8c7b6aaf027a5833bcbdf0dfa5de
Summary:
Regression introduced in D71735505 where I tried to ensure fabricEventEmitter was always non-null. Instead log a soft error when this happens, so we don't drop the event silently.
Changelog: [Android][Fixed] Fixed crash when event is emitted after instance is shutdown
Reviewed By: mdvacca
Differential Revision: D71967092
fbshipit-source-id: 990b6414b41a2709d70a6deae38f5aa043203a20
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50325
axOrderViews is an optimization I came up with so that we could find and queue all the views on a single tree traversal. It initializes the array with the size of the accessibilityOrder array and places each view where its nativeID is. If there is no view corresponding to the nativeID then that axOrderViews element will be null. So to fully ignore nativeIDs that don't correspond to any View we can just filter the nulls
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D71977739
fbshipit-source-id: a3f2138eebe06808ce413355df5d9beb2f4ff388
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50230
Currently, `AnimatedProps` invokes `findNodeHandle` to both connect and disconnect the native `AnimatedNode` instances to corresponding `viewTag`s.
Not only is this slow and wasteful (because `findNodeHandle` requires traversing the fiber tree), but it prevents deferring disconnection to after the fiber tree has been unmounted.
Disconnecting after unmount is necessary when the `scheduleAnimatedCleanupInMicrotask` feature flag is enabled, which is necessary to avoid invoking animation completion callbacks in the commit phase that unmounts animated views.
I have verified that `disconnectAnimatedNodeFromView` is needed and handles being called after fibers are unmounted.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D71745805
fbshipit-source-id: ce8c2c95d38c4d5adbb79bac3c07b0872211cf51
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50311
We are going to initially expose this with the `experimental_` prefix to indicate that it has not been battle tested yet.
Changelog: [Internal]
Reviewed By: jorge-cab
Differential Revision: D71939365
fbshipit-source-id: e9481b6bd4f253fb97c11fc9d7bf3708ffe79635
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50316
This should only be used internally
Changelog: [Android][Removed] Remove FabricSoLoader from public API
Reviewed By: Abbondanzo
Differential Revision: D71965740
fbshipit-source-id: 41c2377a9efcaa21378b2ac49af0c1a544589371
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50315
Make it clearer that the only purpose of this class is to manage the soloading of the core bridge so file.
Changelog: [Internal]
Reviewed By: Abbondanzo
Differential Revision: D71965759
fbshipit-source-id: d333f3e768a2359b082d4df279548cbd4b58ec76
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50319
Originally removed in 0.71, leaving a README file as an FYI, which is now removed.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D71968498
fbshipit-source-id: 81d380570df346f709a35727090c8e3b8b043183
Summary:
to resolve use_frameworks build error. this is an edge case happening only when there's objective-c files import to `React_RCTAppDelegate`. Xcode will have `include of non-modular header inside framework module` error originally. this is the generated umbrella header for jsitooling is incorrect. even the header path are correct, they are not modular headers.
~this pr adds a workaround to import header from outside the module.~ updates: this pr uses a forward declaration to prevent exposing the dependency in umbrella header.
## Changelog:
[IOS] [FIXED] - `JSRuntimeFactoryCAPI.h` build error for `use_frameworks` build
Pull Request resolved: https://github.com/facebook/react-native/pull/50252
Test Plan:
to reproduce the build error, we can build `USE_FRAMEWORKS=static bundle exec pod install` from rn-tester. we also need to import `React_RCTAppDelegate` from objective-c files. in this case, we can add `import React_RCTAppDelegate;` in rn-tester's main.m
```diff
--- a/packages/rn-tester/RNTester/main.m
+++ b/packages/rn-tester/RNTester/main.m
@@ -8,6 +8,9 @@
#import <UIKit/UIKit.h>
#import "AppDelegate.h"
+@import React_RCTAppDelegate;
+// This also triggers the error
+//#import <React_RCTAppDelegate/React-RCTAppDelegate-umbrella.h>
int main(int argc, char *argv[])
{
```
Reviewed By: fabriziocucci
Differential Revision: D71963188
Pulled By: cipolleschi
fbshipit-source-id: 5d566ae5aadb9efc032aacfe32862ea289134f87
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50288
Add hints about why devices running in the background might not report debuggable pages:
- Taking them from background might be enough
- Force killing them to restart them properly might be needed on Android.
Changelog:
[General][Internal]
Reviewed By: huntie
Differential Revision: D71888615
fbshipit-source-id: dda54b15daa7eebd1bc28a4d327a9b3d006397a4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50287
Using keys intersection to iterate over Props and PassThroughProps is not legal in TS. The issue can be mitigated by using intersection of AnimatedProps and PassThroughProps.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D71898246
fbshipit-source-id: 8505989f60622654034e5a775b884945dd9388ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50295
Enabling `useFabricInterop` by default for internal apps since before D71582553 iOS wasn't using useFabricInterop in it's codebase and old architecture with Interop enabled is harmless.
This is to keep the current behaviour consistent.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D71908601
fbshipit-source-id: 825338db486d8f64c44c2d4c28394d8b789c4195
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50299
## Changelog
[General] [Fixed] – Add explicit `folly/dynamic.h` include where it is actually used
## Internal
This symbol is used in the file, so ensure we actually declare it. That way we do not need to depend on some other header to provide the symbol
Reviewed By: NickGerleman
Differential Revision: D71910330
fbshipit-source-id: 4fbb584cafc688bd58f6863370efc1ede3a4c5f1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50225
Updates `index.js.flow` to export (what should be) all public types for `react-native`, closely matching the resolved exported types of `types/index.d.ts` (current manual TS defs).
- Note that this first pass doesn't have to be exhaustive (not yet load bearing) — however, I've done a best-effort scan, which passes our current `__typetests__` fixtures.
**Approach: Explicit type imports in `index.js.flow`**
We have a number of options for how we organise and re-export values and types from the new index file — for now, we're opting for explicitly exporting each symbol here.
- While this clutters the index file somewhat, it also provides a single scannable source of truth — without introducing / altering each contributing module's type exports (we might want to do this eventually, but we're far from having strong organisation denoting the public API boundary). It's self-documenting that the index file contains all root exports by name.
- At the same time, we currently have some exceptions that use `export [type] *` to line up with TypeScript `namespace`s. We aim to review and update these within this release cycle, to enforce the above system.
Changelog: [Internal] - The `react-native` package now exports all public types in Flow (fbsource)
Reviewed By: rubennorte
Differential Revision: D71741575
fbshipit-source-id: 770e2b490e494ee195f4240358fec39f69145a94
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50298
Given EventDispatcher already synchronously calls EventListener, this convenience method for listening to events directly from EventEmitter was short-sighted. We will revisit how to handle JS vs. UI dispatched events for NativeAnimated purposes in future diffs. For now, this reverts https://github.com/facebook/react-native/pull/49998
This change is not being marked as breaking since the change that added this API has not yet been shipped to stable.
## Changelog
[General][Removed] - EventEmitter addListener and removeListener APIs
Reviewed By: zeyap
Differential Revision: D71909828
fbshipit-source-id: 9246de5c7a33368d182369a2d6eb57aa960b415b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50229
Makes a few internal improvements to `AnimatedProps`:
- Change `__connectAnimatedView` and `__disconnectAnimatedView` to be private methods, so that we can confidently change their type signatures.
- Pass `#targetInstance` into those methods, so that the responsibility of verifying `#targetInstance`'s non-nullability is hoisted to the call sites.
There should be no observable runtime behavior change.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D71740601
fbshipit-source-id: 6abc6faf63f3c3274fd2d92baf0958d2471d4a63
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50228
Properly annotate the type of `#animatedView` in `AnimatedProps` and rename it to `#targetInstance`.
Otherwise, no runtime behavior change.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D71739606
fbshipit-source-id: c97e4bd323ad9b1c08fd4976f13b6b20e8fe4793
Summary:
JsErrorHandler throwing again masks what the real problem is.
Changelog: [Internal]
Reviewed By: tmikov
Differential Revision: D71920942
fbshipit-source-id: 1697f6f4c779d5c896df1be8e696a185f1c2c828
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50306
`LengthPercentage` is a class representing a length, or a percentage of a reference length.
Having a function on it, specific to resolving asymetrical corner radius is the wrong organization. Let's move it to where it belongs.
Very technically breaking, but I would be shocked if anyone is using this API.
Changelog: [Internal]
Reviewed By: jorge-cab
Differential Revision: D71922893
fbshipit-source-id: 4660c861e21c1dffae15d3f463c135a494124e2a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50233
Ships the `disableInteractionManager` feature flag, which disables `InteractionManager` and replaces its scheduler with `setImmediate`.
Changelog:
[General][Changed] - InteractionManager is deprecated and will be removed in a future release. Its behavior has been changed to be the same as `setImmediate`, and callers should migrate away from it.
Reviewed By: javache
Differential Revision: D71766877
fbshipit-source-id: 36710fdf17c92f8cdee141e43a3c4d0bd9ef0e81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50174
Add `httpReasonPhrase` util and use to populate CDP `Response.statusText` value.
AFAIK, neither platform, and none of our dependencies, reliably provide this mapping — so this is implemented directly.
Changelog: [Internal]
Reviewed By: vzaidman
Differential Revision: D71470037
fbshipit-source-id: f3f6437d0fb3227858b5910a71170e3a634aa962
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50286
Configures a thinner version of `NetworkReporter.cpp` (the entry point to `jsinspector_network`) in production builds (i.e. dev or profiling build, as gated by `REACT_NATIVE_DEBUGGER_ENABLED`).
Even though enabling the CDP Network domain isn't reachable in prod, this will reduce the compiled code footprint of `jsinspector_network`.
We also don't need `glog` here any more — remove dep.
**Implementation notes**
The reason to gate the logic within each method, with inline `#ifdefs`, rather than swapping between complete implementation files, is because each `report*` function will also have load-bearing logic (for the Performance API) in all prod builds. Therefore, this will reduce duplication (and file switching) down the line — and can be understood at a glance with this pattern.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D71636694
fbshipit-source-id: 50e7c008bb6fd128fe1248d767832b36ccb0219b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50173
Refactors the internals of `NetworkReporter` (and the `jsinspector_network` library) to better organise concepts before we scale to more Network CDP events.
- Introduces `cdp::network` structs modelling CDP `Network` domain events and data types.
- Moves implementation details in converting input data objects to CDP types into `CdpNetwork.cpp` and `HttpUtils.cpp`.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D71470039
fbshipit-source-id: 0c04ffb40efbbb6d6d9782959f5adb33c9097ccb
Summary:
These modules don't actually use ui things in their setup. So, they don't need to be set up on the main queue.
Changelog: [Internal]
Reviewed By: lyahdav
Differential Revision: D71849447
fbshipit-source-id: d9d6ee043cac112731c27ff920e857fccdd54bc0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50110
## Rationale
Rendering can now include main -> js sync calls.
If we allow js -> main sync calls during rendering, react native can deadlock.
So, this diff moves the js -> main sync calls to "main queue module setup", which occurs before rendering.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D71347452
fbshipit-source-id: 894f21c703981c633fc0966e1edd647251d0fe2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50302
Changes `eslint-config-react-native` to stop overriding rules that are disabled by `eslint-config-prettier`, which disables rules that conflict with Prettier formatting.
This also adds a Jest unit test to enforce that this invariant even as the configs change.
Changelog:
[General][Changed] - `eslint-config-react-native` now respects rules disabled by `eslint-config-prettier`.
Reviewed By: kassens
Differential Revision: D71922014
fbshipit-source-id: 55ba46e880d6129a417e864ab2fbb5704c57997b
Summary:
I made a mistake before, it seems we should use std::size_t to prevent bits truncation.
## Changelog:
[IOS] [FIXED] - Fabric: Fixes color hash type to prevent bits truncation
Pull Request resolved: https://github.com/facebook/react-native/pull/50285
Test Plan: N/A
Reviewed By: javache
Differential Revision: D71895413
Pulled By: cipolleschi
fbshipit-source-id: 26cc036bee851902e11abfa8ed5c5c8222421b09
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50242
Similar to D71636694, adds conditional compile to `RCTInspectorNetworkReporter.mm` to minimize code size and operations performed in production builds.
Specifically:
- Expensive copy of `httpBody` is eliminated.
- Other optional fields that are only mapped when CDP support is enabled are also omitted.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D71637716
fbshipit-source-id: 6c7688b1ac82d2b1047b42a812834a7dfb37cd0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50142
This is a first pass at integrating `NetworkReporter` in our networking stack on iOS (`RCTNetworking.mm`).
**Implemented events**
Wires up minimal events sufficient to populate the Chrome DevTools Network panel:
- `Network.requestWillBeSent`
- `Network.responseReceived`
- `Network.loadingFinished`
**Other notes**
`RCTNetworking` is used (tentatively) as the integration point since it:
- Is the default implementation for the network stack on iOS.
- Should allow us to pair with originating JS call site down the line.
- Intercepts Blob requests (at least `RCTImageLoader`).
- Sits outside the user-configurable `RCTNetworkingResponseHandler` and `RCTNetworkingRequestHandler` concepts.
- Is where network events are currently sent to JavaScript (`sendEventWithName`).
NOTE: Reminder: `NetworkReporter` is currently a no-op without the `fuseboxNetworkInspectionEnabled` experiment set.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D71470038
fbshipit-source-id: 069d77473c333a98f796b3dffa670a39b3016b2b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50290
Changelog: [internal]
Small rename as the official name of the API is LongTasks.
Reviewed By: yungsters
Differential Revision: D71734777
fbshipit-source-id: fac085e3b0d304f7d05087143c15d32cf2b0971b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50265
This is a fun one!
"Improvements" consist of
* Performance is better now. Previously we did a tree walk for each ID in the array, now its just one :)
* Properly handles coopting (more on that below)
**Performance**
The previous implementation naively walked the tree until it found the right nativeId for each nativeId in the prop. This new algo just does a single tree walk and collects the views that have the right nativeIds as we are doing that walk.
**Coopting**
Our iOS code implements a form of accessibility coopting, where an element can "speak for" a descendant. This happens when some parent element does not have an accessibility label but a descendant does. We look at the subtree and grab every node that has a label and lift it up to the aforementioned element without a label. This enables some nice a11y features like wrapping `Text` in a `View` and letting the `View` just read all the `Text` inside (imagine a button with a label, you would only want to focus the button and just read the text instead of the text itself).
This feature is nice but it becomes buggy when we introduce `accessibilityOrder`. Previously, there was no way to access nested elements on iOS, the platform prohibits this. However, you can get around this by using `accessibilityElements`, which our `accessibilityOrder` prop maps to. So you could define the order as `['parent', 'child']` and access both elements just fine. However, if that `parent` is a `View` that coopts `Text`, we have some issues. The `View` will read the `Text` but then when the user swipes we focus the `Text` and read it again!
To get around this we check up the superview chain in RCTParagraphViewComponentView looking for Views that might coopt us and a cooresponding accessibilityElements with said candidates. If there is such a View we do not announce ourselves. Performance is iffy here, we need to iterate up to root for all text focusing, but this should be fairly fast for all intents and purposes and I have not noticed any lag when changing focus ordering.
Changelog: [Internal]
Reviewed By: jorge-cab
Differential Revision: D71562476
fbshipit-source-id: 31fd935df0764459403464bd645aae2e664c69cb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50215
Backwards compatible updates to `CoreEventTypes`, `Image`, `Switch`, `TextInput` to align types and reduce root exports.
The effects of this change can be seen in `packages/react-native/types/__typetests__/index.tsx` (smoke test file against current manual TypeScript definitions).
Under Flow, exports on each `*EventData` type are directly removed (unreferenced).
Changelog:
[General][Deprecated] - Deprecate `*EventData` types on `Image`, `Switch`, `TextInput` components. These can be substituted for `*Event`, e.g. `NativeSyntheticEvent<ImageLoadEventData>` becomes `ImageLoadEvent`.
Reviewed By: NickGerleman
Differential Revision: D71734361
fbshipit-source-id: 287c775e840319242984d248169c267abf8f032b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50275
This change adds a check to automate a step in the release process: https://github.com/reactwg/react-native-releases/blob/main/docs/guide-release-process.md#verify-assets-have-been-uploaded-to-maven
The script will poll maven for 90 minutes and return when the artifacts are available. If, after 90 minutes, artifacts are not available, it exits with code 1 that should fail the Release workflow. The Release Crew should have a look at what's happened.
## Changelog:
[Internal] - Automate the check for artifacts being on Maven
Reviewed By: fabriziocucci
Differential Revision: D71825014
fbshipit-source-id: 8879bf9c8fc4519e86b55ad8f9bd3ecf3f8ecfb7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50283
In OSS we have some libraries written in Swift, like Flashlist, that depends on these pods.
However, if a pod is not configured to define modules, those pods cannot be imported by Swift. Therefore, the libraries above will failed to be installed in a project.
This change adds the defines_modules directive to those pods and make the library work again.
This fixes https://github.com/facebook/react-native/issues/50246
## Changelog
[Internal] - Make React-hermes and React-renderercss defines modules
Reviewed By: fabriziocucci
Differential Revision: D71892679
fbshipit-source-id: b03b65986fbdbe781b616f31dfb6bceb38b8b3b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50232
While reviewing the `avoidStateUpdateInAnimatedPropsMemo` experiment, I noticed that the control and test groups were invoking `areCompositeKeysEqual` differently:
- Test group was passing in `allowlist`.
- Control group was not passing in `allowlist`.
Passing it in is technically more correct, but let's restore the control group behavior for now to isolate the tested changes.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D71746745
fbshipit-source-id: aa34db0532ef53ead08bbd632aab0994b31b9340
Summary:
The React Native monorepo depends on `jest-config` in `jest.config.js` but does not specify it as a dependency. This means we got it as a phantom / transitive dependency. In React Native macOS, I am testing using Yarn 4 with pnpm layout to protect against such dependencies (See https://github.com/microsoft/react-native-macos/pull/2366). The simplest way to fix this is to just declare it as a dependency.
## Changelog:
[INTERNAL] [FIXED] - Add jest-config as a dependency
Pull Request resolved: https://github.com/facebook/react-native/pull/50280
Test Plan: This change should be a no-op in React Native, we already had the package in our lock.
Reviewed By: yungsters, huntie
Differential Revision: D71891841
Pulled By: robhogan
fbshipit-source-id: 5b4720e9e09e25b2f1eebb80675bfe4f3a48e2dc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50261
Since now we have the optimization of only running the custom accessibility order when we define the tree as dirty we need to add a hierarchy change listener on all ViewGroups within the parent to notify accessibility services of potential changes in hierarchy and so mark the subtree as dirty.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D71821636
fbshipit-source-id: 25649efa1679024a205e94c340511dc58783d575
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50240
StrictAnimatedComponentType was introduced to incrementally adopt sctricter animated types at the time. After aligning AnimatedProps it is no longer necessary and can be swapped with AnimatedProps.
Changelog:
[Internal] - Removed StrictAnimatedComponentType from createAnimatedComponent.
Reviewed By: huntie
Differential Revision: D71804845
fbshipit-source-id: e8adbfde1a48fd3f4fc94f4cc0938bd64384c418
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50038
Changelog: [Internal]
Creating a new feature flag to gate change for integrating c++ native animated
Reviewed By: rozele
Differential Revision: D71216797
fbshipit-source-id: 9669628a0789701ab6d447a8561027f3a335ef4f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50271
In the next version of Flow, support for `$PropertyType` will be removed in favor of indexed access types. The final 2 usages in react-native is in `ReactNativeTypes`, which is synced from upstream react. Sync of https://github.com/facebook/react/pull/32733 is currently blocked by test failures, so I will add the temporary shim to unblock releases.
Changelog: [Internal]
Reviewed By: panagosg7
Differential Revision: D71849353
fbshipit-source-id: d4787fe17ae52aa50d54f9fb7fb8b14c149aa1e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50260
Changelog: [internal]
Created new directory `react-native/src/private/__tests__/utilities` and moved `ensureInstance` and `isUnreachable` to it.
Reviewed By: yungsters
Differential Revision: D71826787
fbshipit-source-id: 50a50a54ab928c9060282a9f2256ad97dd856ba4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50258
Changelog: [internal]
Minor reordering of tests in `Fantom-itest`, fix of describe block for `enqueueScrollEvent` and fix incorrect usage of `enqueueScrollEvent` instead of `scrollTo` in `scrollTo` tests.
Reviewed By: yungsters
Differential Revision: D71820977
fbshipit-source-id: 07637e2d18cde96c78c83285ba28201260e42f3c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50257
Changelog: [internal]
## Context
We have some tests that make sure certain objects are deallocated/released at the right times, but those are generally hard to get right. The main reason is that WeakRefs semantics are tied to the tasks and microtasks in JS, but we handle them both inside and outside the Event Loop in Fantom tests.
This leads to some surprising behavior where things we expect to have been deallocated weren't because of some innocent looking code.
## Changes
This introduces a safety mechanism in Fantom to enforce that WeakRefs are always dereferenced inside the Event Loop, by patching the method in `WeakRef` and checking if we're in the Event Loop using Fantom APIs.
It also updates the existing test using WeakRefs to fix the new errors thrown by this patch, and to serve as a "good example" on how to use WeakRefs to do memory testing.
Reviewed By: yungsters
Differential Revision: D71815397
fbshipit-source-id: 8faab1898d9112ec365b41867179abb8b251e337
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50219
* Make FabricEventDispatcher private, we already have a public EventDispatcher interface
* Rename ReactEventEmitter to EventEmitterImpl, to make it clearer it aligned with EventDispatcherImpl
* Update docs to make it clearer what's part of the old architecture
Changelog:
[Android][Removed] Removed FabricEventDispatcher from public Android API
[Android][Removed] Removed (un)registerEventEmitter from EventDispatcher interface
Reviewed By: lenaic
Differential Revision: D71735505
fbshipit-source-id: f0b56298cc38d08101ccdcdf0bda5487204e7bdc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50247
Rather than nooping the RCTSurfacePresenterObserver in RCTNativeAnimatedTurboModule, we should just not register the observer when using ReactNativeFeatureFlags::animatedShouldSignalBatch.
## Changelog
[Internal]
Reviewed By: shwanton
Differential Revision: D71735004
fbshipit-source-id: 5176497197314a9b07fc9bd77828f7a2af2650ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50236
If you do something like
```
<Text>
<Text accessibilityRole="link">
I am a link!
</Text>
</Text>
```
we do not announce "link".
We skip any sort of spans on the entire text on iOS, which I feel like is not ideal. This case would be common enough, and users may not have access to the top level text component.
Note Android correctly handles this already.
Changelog: [iOS] [Fixed] - Correctly announce "link" on nested text if its the entire text element
Reviewed By: javache
Differential Revision: D71770798
fbshipit-source-id: 4a0781a95cb27cf244d6d2b1d1df8a0451964301
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50245
Follows D69867335, but uses the system `[[UIDevice currentDevice] systemName]` API to get the case sensitive OS name (as opposed to the `RCTPlatformName` concept, which is lowercase "ios").
Ultimately, this value is displayed as a user facing label in the debugger.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D71809427
fbshipit-source-id: 3f62bba94df16329c934a7671bcaa489c6797cb6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50214
This diff is a second step toward the TS AnimatedProps alignment. In this change the rest of the extended types and recursions in `WithAnimatedValue` are applied.
Changelog:
[Internal] - Aligned AnimateProps to match TS types.
Reviewed By: huntie
Differential Revision: D71623036
fbshipit-source-id: d4777e25c3bf3119608938ee4cd246cdc4c4f7ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50195
In Flow, all AnimatedProps properties are set to `any` and misaligned with Typescript definitions. This diff is a first step toward the TS AnimatedProps. The problem can be broken down into a few parts, at each point more types will be extended in WithAnimatedValue and the rest will be set to `any`. This approach enables smoother migration and validation.
Changelog:
[Internal] - Check for Builtin and Nullable types in WithAnimatedValue to align closer to TS types.
Reviewed By: huntie
Differential Revision: D71551006
fbshipit-source-id: 9316227f4ba32bdaa5be8097483a03ae19bf516f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50221
This was already rolled out by default previously, but we wanted to complete further testing internally before cleaning up the flag.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D71735311
fbshipit-source-id: b9d32787081fbe3d7fb740067d3709624028fa23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50223
This is an implementation detail of React and better not make it leak everywhere. It's not used quite often even in react-native codebase, so it's better to just suppress the error on each call site. Currently it's typed as any, so there is not much type safety lost anyways.
Changelog: [Internal]
Reviewed By: alexmckenley
Differential Revision: D71687426
fbshipit-source-id: 7373bcd9bedcfcb95a10fa02e6a04399ccab91f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50216
Call TouchesHelper directly from TouchEvent and remove the need for `RCTModernEventEmitter.receiveTouches`. This enables `Animated.Event` to process these events too, since they are now being delivered just like any other event.
Changelog:
[Android][Fixed] Enables Animated.Event to be used with onTouchMove in the new architecture.
[Android][Removed] Removed deprecated EventDispatcher#receiveTouches
Reviewed By: Abbondanzo
Differential Revision: D71114177
fbshipit-source-id: 61ca43ef5334b5514c4980a05b61b674d9a52c5b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50231
Changelog: [Internal]
RCTDeviceInfo uses KVO to listen to frame changes in the application's keyWindow. On initialization, it reads the global keyWindow and adds itself as a listener. When RCTDeviceInfo is cleaned up, it reads the global keyWindow again, and removes itself as an observer.
However, this makes an assumption that the keyWindow is always the same. This is not always true - for example, when a UIAlert is presented, the OS creates a new temporary keyWindow to host the alert in order to make sure it is the first responder. If the cleanup is called then, the app will crash because there is no RCTDeviceInfo observing it. Another example is the LogBox, which also temporarily creates a new keyWindow.
The fix is simple, we can capture a reference to the application's keyWindow on initialization, but make sure it is weakly held as the keyWindow is usually managed by iOS. Then, when we remove the listener, it is always guaranteed it is the window that we are observing.
Reviewed By: javache, cipolleschi, realsoelynn
Differential Revision: D71667722
fbshipit-source-id: 103baf980b79b413fb29e6c3deff81dae33671c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50218
These were added in D70129295 to BaseViewManager but did not exist in the JS interface.
Changelog: [Internal]
Reviewed By: Abbondanzo
Differential Revision: D71737288
fbshipit-source-id: 751d26fb9116daf45d09f3853fe37cad29a8903a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49982
In D68708899, we removed dataURI inlining of sources and source maps into `Debugger.scriptParsed` CDP notifications.
After that, all message handling for which we need to preserve order is implemented completely synchronously, so there's no need for a promise queue to preserve order.
This removes the redundant queue.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D71036230
fbshipit-source-id: d17fb7d06a038b379fe45b4e1c742dbf8ff12f78
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50036
This is my friday round of fixing some warnings in our codebase.
Those are all minor bits that should be fixed.
Changelog:
[Internal] [Changed] -
Reviewed By: huntie
Differential Revision: D71209124
fbshipit-source-id: 40aa231e049025bbff9dff8a572784bb1a9f324b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50187
D70668516 broke some SSTs, where asset that previously was black, showed up as clear.
I was assuming that was because we fixed a separate bug where assets could erroneously show as black layer, but these tests were actually just using a black asset.
Real bug here, is that the change led to only setting image when we have a displayLink, ie showing on screen, where before, we set image (implicitly at first frame) as layer content.
This change fixes that behavior, so first frame is rendered as part of off-screen view rendering, for images considered animatable.
Changelog:
[iOS][Fixed] - Fix animated images missing from offscreen render
Reviewed By: cipolleschi
Differential Revision: D71590856
fbshipit-source-id: f5da690b27f2da0f6979f25ece031ff0d418cca6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50193
This fix makes sure that we convert to JSException only NSException thrwn by sync methods.
Currently, nothing in the stack will be capable of understanding that js error if it is triggered by an exception raised by an asyc method.
See https://github.com/reactwg/react-native-new-architecture/discussions/276 for further details
We need to cherry pick this in 0.78 and 0.79
## Changelog:
[iOS][Fixed] - Make sure the TM infra does not crash on NSException when triggered by async method
Reviewed By: fabriziocucci
Differential Revision: D71619229
fbshipit-source-id: b87aef5dd2720a2641c8da0904da651866370dc6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50175
This change logs warning in the RN Dev Tools and in the Xcode console when a legacy module is used through the interop layer.
The `moduleName.methodName` warning is logged only once per usage not to flood the users with Warnings.
## Changelog:
[iOS][Added] - Add warnings when a legacy module is used in the Interop Layer.
Reviewed By: cortinico
Differential Revision: D71561348
fbshipit-source-id: f3ec830ddb07c4d0ab34534ad2baf95e75b1a3b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49897
This change introduces the first warning for the New Architecture warning.
When modules are registered through the RCT_EXPORT_MODULE (or its variants) a warning is emitted.
Note: currently it is only emitted on the Xcode console.
I'm looking into ways to emit it also in the RN DevTools console.
## Changelog:
[iOS][Added] - Show warnings in the New Architecture when modules are loaded using RCT_EXPORT_MODULE
Reviewed By: cortinico
Differential Revision: D70789672
fbshipit-source-id: 06cb6cafbe7f65142a92d2e1ab9bc4ff59d0312a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50194
Changelog: [internal]
Just a small improvement of the diagram to make it more symmetrical and expand on what parts of the system are used within the rest of the RN repo.
Reviewed By: javache
Differential Revision: D71620577
fbshipit-source-id: 6b9398f416fd529eea192e82cad844212278492c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50192
Third party libraries depend transitively agains the React-renderercss modules because it is imported by Fabric.
Without this change, the use_frameworks on iOS does not works when a 3P library is imported.
This changes fix the behavior and we need to cherry pick them in 0.79.
## Changelog:
[iOS][Fixed] - Make sure 3p libraries depends on React-renderercss to work with use_frameworks
Reviewed By: fabriziocucci
Differential Revision: D71618395
fbshipit-source-id: 70c12dcbeb2dfa5fd7513c27d5c069a1f3c95966
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50170
This is needed in D71470038 and later, where submodules of `jsinspector-modern` need to operate with CDP message payloads. We functionally split out these files as a library to avaoid a dependency cycle.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D71551561
fbshipit-source-id: 527479399d7563883c1b6599f884b7857e79bd77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49824
The way this works is each element on the list of `accessibilityElements` says that each element should go before the next element in its list. For example:
Imagine the default focus order:
```
[A, B, C, D, E]
```
If I set `accessibilityElements` to be:
```
[E, D, C, B, A]
```
That's just re ordering the focus order to be reversed, but what happens if I miss elements?
If I set `accessibilityElements` to be:
```
[D, B]
- D should go before B
```
Then my resulting order will be:
```
[A, D, B, C, E]
```
Because we follow the default order, then we find `B` but `D` should go before `B` so we first go to `D` and then finally go back to `B` and then continue our default order
This algorithm works with nested elements and it doesn't need to be exhaustive
We are also borrowing the concepts of Containers and elements from iOS.
We will disable views according to iOS logic to facilitate code shareability
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D70129295
fbshipit-source-id: 5ada03c7e5eb71a7b0a9d205296c2fa4366a3643
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50080
I'm renaming ReactNativeFeatureFlagsProviderHolder -> ReactNativeFeatureFlagsJavaProvider to make naming consistent with documentation and remove the concept of "Holder" which is not part of the original design
changelog: [internal] internal
Reviewed By: rubennorte
Differential Revision: D71333170
fbshipit-source-id: be89c3aafe5d9b1c9699aff224c7c8511bdf9327
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50180
Prepare for the change that makes `React.ComponentType` an alias of `component(...Props)`, which comes with stricter checking and making the props automatically readonly.
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D71566900
fbshipit-source-id: cefcc10fda9a9777532f25b325412b0d50ebb9b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50106
## Changelog:
[General] [Added] - Create TurboModuleWithJSIBindings interface
So c++ TurboModules can initialize some private members with reference to `jsi::Runtime`
Reviewed By: lenaic
Differential Revision: D71396842
fbshipit-source-id: 59d32e4cbf2c5081912a4c828acc66ceb8702855
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50158
Compile-out UIManagerModule from FpsDebugFrameCallback
The setViewHierarchyUpdateDebugListener does not exists on Bridgeless and NotThreadSafeViewHierarchyUpdateDebugListener is deprecated and marked for deletion on the new architecture.
The new architecture exposes a different API called ItemDispatchListener that's a sort of replacement for NotThreadSafeViewHierarchyUpdateDebugListener. Although it's not the same.
FpsView is broken in old/new arch and needs to be rebuild, I believe this behavior needs to be rethinked in the future. For now I'm excluding usages of NotThreadSafeViewHierarchyUpdateDebugListener and setViewHierarchyUpdateDebugListener for apps running on the new arch enabled by default.
changelog: [internal] internal
Reviewed By: rshest
Differential Revision: D71050642
fbshipit-source-id: 662deb064ffc2322b560618fac3203ab4e86c277
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50164
Based on analysis this method is only used by legacy architecture, this diff adds an assert if NativeModuleRegistry.onBatchComplete() is used in new architecture
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D71050638
fbshipit-source-id: 7a9791230880d2431e6b136735653a8ab4c34d7d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50160
In this diff we are removing UIManagerModule from NativeAnimatedModule
This code wasn't executing when fabric is enabled, with this change the code that references UIManagerModule will be stripped out
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D71050641
fbshipit-source-id: fbedd5b9e1a9efb45c2fb7558d97fc639897c28c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50157
UIManagerType.DEFAULT is becoming confusings As we are expanding the usage of the New architecture everywhere.
That's why I'm depreacting this constant and introducing UIManagerType.LEGACY.
changelog: [Android][Deprecated] Deprecate UIManagerType.DEFAULT, replaced by UIManagerType.LEGACY
Reviewed By: alanleedev
Differential Revision: D70738948
fbshipit-source-id: 9793a6cce3b931f9c0de4e0c2026852119f392b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50172
This specific warning is only for React Native users.
We don't need this warning on console for RNtester so I'm excluding react-native-github
project from the list of project where this warning gets fired.
Changelog:
[Internal] [Changed] - Do not warn for JSC deprecation on react-native-github
Reviewed By: mdvacca
Differential Revision: D71556035
fbshipit-source-id: 8ab625eb2c090416119903dbc9c29afac51c91bd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50104
Changelog:
[General][Internal] raises an event report when an attempt to open the debugger for not supported apps is made
Reviewed By: robhogan
Differential Revision: D71398802
fbshipit-source-id: 66b90a0286ee0844ced4319381e3a0581ce540b5
Summary:
fix: https://github.com/facebook/react-native/issues/50132
The goal of this PR is to ensure selected TextInput scrolls to the selected range when text or selection change.
The background of this feature check is to implement a rich text editor.
## Changelog:
[IOS][FIXED] - Selection range not respected when changing text or selection when selection is forced
Pull Request resolved: https://github.com/facebook/react-native/pull/50166
Test Plan:
Tested with the sample linked to this pull request.
As TextInput is a controlled component
Here is a video of the sample with the patch: https://drive.google.com/file/d/1lS9_70quNqND_E8MjLFcRG6HoHcDkfmv/view?usp=drive_link
First TextInput shows the initial issue reported in the ticket.
Second TextInput shows the global behavior of the controlled component, the 2 buttons allows to force focus and the force text values
I have also backport this part on 0.77.1 and test it in my app, it works fine for me (let's see if I have QA feedback)
Reviewed By: javache
Differential Revision: D71544064
Pulled By: cipolleschi
fbshipit-source-id: ca49a3a2ca0f5f87307054efda31b0c779c31496
Summary:
Expose eager initialization method on `RCTRootViewFactory` (iOS) so that application can prepare `ReactHost`/Bridge before actually creating a root view. Then creating a root view is significantly faster.
## Changelog:
[IOS] [ADDED] - allow eager initialization of `RCTRootViewFactory`
<!-- 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/49986
Test Plan:
Invoke `initializeReactHostWithLaunchOptions:` before calling `viewWithModuleName:` and measure the time difference vs not using eager initilization:
Before
- calling `viewWithModuleName:`: 63.39ms, 47.91 ms, 60.18ms
After:
- calling `initializeReactHostWithLaunchOptions`: 52.41 ms, 81.03 ms, 60.52 ms
- calling `viewWithModuleName`: 0.49 ms, 0.63 ms, 0.47 ms
Test run 3 times on iPhone simulator on M1 mac.
Reviewed By: javache
Differential Revision: D71548601
Pulled By: cipolleschi
fbshipit-source-id: 86ecfb8bec4c2657537caf32af49545b21d3656b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50131
Outlines and stubs methods on the `NetworkReporter` class, and the `Network.getResponseBody` CDP request on `NetworkIOAgent`. Together, these form the APIs to implement for CDP network debugging.
Also updates internal mutex use to `std::atomic<bool>`.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D70708526
fbshipit-source-id: f44bd0d246a38883dd591752fb2d3ed4567de4a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50115
## Rationale
Rendering can now include main -> js sync calls.
If we allow js -> main sync calls during rendering, react native can deadlock.
So, this diff moves the js -> main sync calls to "main queue module setup", which occurs before rendering.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D71348561
fbshipit-source-id: 1c57ba1d40b062712fd53b9dac0bc8ecd60b425d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50113
## Rationale
Rendering can now include main -> js sync calls.
If we allow js -> main sync calls during rendering, react native can deadlock.
So, this diff moves the js -> main sync calls to "main queue module setup", which occurs before rendering.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D71348559
fbshipit-source-id: 918f145d817866a5d08087c1a4a0e151f783109e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50112
## Rationale
Rendering can now include main -> js sync calls.
If we allow js -> main sync calls during rendering, react native can deadlock.
So, this diff moves the js -> main sync calls to "main queue module setup", which occurs before rendering.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D71347448
fbshipit-source-id: f62a92a35011a7c8de0a7ee35047cc94f23106d1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50109
## Rationale
Rendering can now include main -> js sync calls.
If we allow js -> main sync calls during rendering, react native can deadlock.
So, this diff moves the js -> main sync calls to "main queue module setup", which occurs before rendering.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D71347449
fbshipit-source-id: 1fa010fd08a2d0b809f36a4c8df973b86e4610f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50111
## Rationale
Rendering can now include main -> js sync calls.
If we allow js -> main sync calls during rendering, react native can deadlock.
So, this diff moves the js -> main sync calls to "main queue module setup", which occurs before rendering.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D71480047
fbshipit-source-id: e36a4dd317bbbf46a6766f01fbf4d69a83a45c17
Summary:
We will use main queue setup of native modules to solve this problem instead.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D71341038
fbshipit-source-id: 77e2064c732a5572d063a240f769fa7a79530f1b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50040
This diff implements main queue module setup.
Sometimes, people need to capture uikit things, and use them from javascript. In those cases, people can write main queue modules. These modules will be eagerly initialized on the main queue, during react native init.
## On Necessity
**Sync** dispatches to the main thread from the js thread can deadlock react native. And **async** dispatches to the main thread from the js thread sometimes might not be enough: it could lead to flickery rendering. So, we need to allow people to capture ui thread things, before any js executes.
## Caveat
This api is dangerous and discouraged. All react native surfaces will pay the cost of one surface introducing a main queue module. It could also slow down common/critical interactions in your app, if you're not careful.
We will introduce performance logging for this infrastructure. So that we can monitor and file tasks, when main queue module init starts taking "too long."
Changelog: [General][Breaking]: Introduce beforeload callback arg into ReactInstance::loadScript
Reviewed By: mdvacca
Differential Revision: D71084243
fbshipit-source-id: 8fdb84761ac69468afc428f4f79eff6322449e3c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49957
## Changes
This diff introduces the api for "main queue modules" into turbo modules.
This will occur occurs before any rendering.
## Rationale
Rendering can now include main -> js sync calls. If we allow js -> main sync calls during rendering, react native can deadlock.
With this diff, we can move the js -> main sync calls to before any rendering happens.
## APIs
**Buck API:**
Plugin:
```
react_module_plugin_providers(
name = "AccessibilityManager",
native_class_func = "RCTAccessibilityManagerCls",
unstable_requires_main_queue_setup = True,
)
```
**OSS API:**
[codegenConfig](https://reactnative.dev/docs/the-new-architecture/using-codegen) in package.json:
```
"codegenConfig": {
"name": "<SpecName>",
"type": "<types>",
"jsSrcsDir": "<source_dir>",
"android": {
"javaPackageName": "<java.package.name>"
},
"ios": {
"modules": {
"AccessibilityManager": {
"className": "RCTAccessibilityManager",
"unstableRequiresMainQueueSetup": true
}
}
}
},
```
Changelog: [iOS][Added] Introduce unstableRequiresMainQueueSetup api to modules
Reviewed By: cipolleschi
Differential Revision: D70413478
fbshipit-source-id: 78d89437c2869a979ae5c94f08b01087686dfae7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50140
Extends `react-native-codegen` to support the `.fb` filename suffix used to gate source code that is only relevant for Meta internal use cases.
Changelog:
[Internal]
Reviewed By: cipolleschi
Differential Revision: D70808462
fbshipit-source-id: a6772d6504f76724b8474df6799bc69a76a2f81b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50147
Noticed a couple bugs here, around a crash from assertion internal to the caching map which hashes on the AttributedString, that may or may not be related.
1. We are missing `baseTextAttributes` for both hashing and equality (which is mostly innocuous, but still wrong)
2. We were not hashing or comparing `textAlignVertical`
3. For equality, we were comparing parent shadow view tag and metrics, but for hashing, we were hashing the whole ShadowView.
I think #3 could cause issues, since we could see different hash despite equality, which could break invariants.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D71500246
fbshipit-source-id: 462749d5ca10d10bf0dab88089253a2bb8e603fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50139
adding this event to Pressable because it is going to be consumed after to track if pressable location is moved
Changelog:
[General] [Added] - Expose `onPressMove` as base prop for `Pressable`
Reviewed By: thurn
Differential Revision: D71429258
fbshipit-source-id: 79acaa735764a47a21d89042d3e4b9c114c72950
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50117
D70870978 failed the compat check because it modified a union by removing an element in the middle:
```
'global' | 'self'
```
from
```
'global' | 'application' | 'self'
```
This caused the compat check to complain that index 1 in both unions: `self` didn't match `application` and thus it was a type incompatibility.
We should have been comparing these as an unsorted array of options, which first sorts, then treats differences as added/removed elements instead of incompatbile elements.
If in the example above the removed element was the last one from the union, it would have been fine.
Once these are classified as added/removed, the VersionDiffer is able to check whether that change is allowed in fromNative or toNative.
Changelog: [General][Fixed] Compatibility Check: Allow union changes when the new element is in the middle of the union
Reviewed By: makovkastar
Differential Revision: D71433054
fbshipit-source-id: 20a73f0ba0576daf30cec97bae969b31baf7f468
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50135
We settled on a different name here so gotta change some code with the old name. This is not exposed yet so this change is chill
Changelog: [Internal]
Reviewed By: jorge-cab
Differential Revision: D71471884
fbshipit-source-id: c30384802ef51e5aae830b27299859db05f2520b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50075
This is an exploratory change to see how it will look like to build core from SPM.
In this change we are building three pieces of React native (using the Podspec names for simplicity):
- React-jsi
- React-debug
- React-logger
- React-MapBuffer
They depends on a local ReactNativeDependency.xcframework we can build using the prebuild-io script.
## CHANGELOG:
[INTERNAL] - set up initial Swift PM configuration
Reviewed By: cortinico
Differential Revision: D70567840
fbshipit-source-id: 3f65a3e7c3dd39f71f6d4c04726712a5968e0a97
Summary:
This PR fixes https://github.com/facebook/react-native/issues/48657
- Memory usage for creating a blob lowered from _( nearest 2^N greater than the file size)+1KB_ previously To _(file size)+1KB_. This is achieved by avoiding internal calls to java.io.ByteArrayOutputStream.ensureCapacity by creating a buffer based on file size.
- Increases the max file size a Blob can be created from before hitting a OutOfMemoryException.
- Major performance increase by avoiding buffer copying
## Changelog:
[ANDROID] [CHANGED] - Speed and Memory usage improvements to Android Blob support
[ANDROID] [FIXED] - Creating of Blobs from large files now works. File size can now be upto available (free) heap size.
Pull Request resolved: https://github.com/facebook/react-native/pull/50121
Test Plan: Used the App here to test Android Blob creation. https://github.com/giantslogik/blob-large-file-fetch.
Reviewed By: cortinico
Differential Revision: D71464835
Pulled By: javache
fbshipit-source-id: 38de7d83bcaee265fc6e7183f6b1160027cd4cb2
Summary:
In the final XCFramework we no longer need to place resource bundles in a subfolder called Resources - they should be located directly in the framework folder.
This commit fixes this by removing copying to the Resources folder. I also removed a few unneeded tests since we know that we are in a valid folder at this point.
bypass-github-export-checks
## Changelog:
[INTERNAL] - Moved resource bundles up one level
Pull Request resolved: https://github.com/facebook/react-native/pull/50101
Test Plan: Run RNTester with RCT_USE_RN_DEP=1 and verify that it launches
Reviewed By: cortinico
Differential Revision: D71464608
Pulled By: cipolleschi
fbshipit-source-id: 6cfdda0c6785ffeb13c170f9fd2dd9f5b889d490
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49998
We have listeners for EventDispatcher, but we don't have any listener capabilities for synchronous hooks from events on the UI thread.
This proposal adds an affordance for generic event listeners that can be attached by the host platform mounting manager, e.g., to wire events to NativeAnimated event drivers.
## Changelog
[General][Added] - EventEmitter `addListener` and `removeListener` APIs
Reviewed By: javache
Differential Revision: D71050838
fbshipit-source-id: a7f298c71bd882a573781c2fe1fb5a1ae79f301c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50032
In the new architecture, Android dispatches all events with folly::dynamic payloads. Various other callsites in some host platforms similarly dispatch events with folly::dynamic payloads.
Events disptached with folly::dynamic payloads have alignment with the `EventPayload::extractValue` method, added for integration with other capabilities like native animations.
When combined with a general pupose synchronous listener on facebook::react::EventEmitter, this should allow easier integration with host platform native event animation drivers.
## Changelog
[Internal]
Reviewed By: javache
Differential Revision: D71198197
fbshipit-source-id: 5e49e3b0fb01079870fbc7fc7e74ca0db354cda5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49988
NativeAnimated currently depends on folly::dynamic event payloads for event-driven animations. While some events (e.g., ScrollEvent.h) have an `asDynamic` implementation, not all events do. In practice, NativeAnimated just needs to be able to extract an numeric value from a path to drive an animation.
Rather than converting events to dynamic, or otherwise special casing event handling, this change allows arbitrary payloads to implement `EventPayload::extractValue` to retrieve JS property path values directly from events, without intermediate conversions to dynamic.
## Changelog
[Internal]
Reviewed By: javache
Differential Revision: D71046682
fbshipit-source-id: 3544335ff9d50da87ced015de587b97204173b57
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49848
Adds a new method to reset the server host in PackageConnectionSettings to its default state rather than relying on providing a blank string
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D70584220
fbshipit-source-id: 2862eee5f71bfe318da7199f2288367433d6f887
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50100
While moving the generation of `ReactCodegen.podspec` from Cocoapods to Codegen, we wrongly copied some parts of the script and now it is generating folders with a `,` as a suffix.
This change fixes the problem and prevent the generation of such folders.
## Changelog:
[Internal] - Avoid generating `ios,` folders
Reviewed By: fabriziocucci
Differential Revision: D71395049
fbshipit-source-id: 1e6024af6e24834a682865792e64d056fb94e027
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50068
Note: this involved tightening up some signatures in Kotlin files
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made DevSupportManagerBase.java nullsafe
Reviewed By: mdvacca
Differential Revision: D71126381
fbshipit-source-id: 01c08e2fc61eff885911fa9c295d504fa7ea334c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50067
Note this diff is only adding FIXMEs that will be removed in the next diff. This diff exists to make the next diff easily reviewable
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D71126382
fbshipit-source-id: d90966e62372395e864425c82321dc1fc04c1413
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50066
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made BundleDownloader.java nullsafe
Reviewed By: alanleedev
Differential Revision: D71126383
fbshipit-source-id: 94e9e9dfc1db83d32046e370c895fa889dabf116
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50065
Note this diff is only adding FIXMEs that will be removed in the next diff. This diff exists to make the next diff easily reviewable
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D71126388
fbshipit-source-id: a9f08b4ce101202cebe13107cc9c6a660deaf58f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50064
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made DebugOverlayController.java nullsafe
Reviewed By: mdvacca
Differential Revision: D71126394
fbshipit-source-id: 77bba33f4f14566e133fa9e9649631bcffa3f0c9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50063
Note this diff is only adding FIXMEs that will be removed in the next diff. This diff exists to make the next diff easily reviewable
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D71126397
fbshipit-source-id: b1cdea896d6cd9d25f9075e0bf35b9e16bf6ef65
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50062
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made CxxInspectorPackagerConnection.java nullsafe
Reviewed By: mdvacca
Differential Revision: D71126386
fbshipit-source-id: 94b6fca6972e5f08c22df7bebe6f853b5ceb20a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50061
Note this diff is only adding FIXMEs that will be removed in the next diff. This diff exists to make the next diff easily reviewable
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D71126390
fbshipit-source-id: 8ab63944b0e6ce3c78b14414e8a992c1321114f1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50060
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made DevServerHelper.java nullsafe
Reviewed By: rshest
Differential Revision: D71126391
fbshipit-source-id: 0d39b23d0d96f32f25ac1003d849428000777852
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50059
Note this diff is only adding FIXMEs that will be removed in the next diff. This diff exists to make the next diff easily reviewable
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D71126395
fbshipit-source-id: fb42b12dae542bde6e0e9e58baeaab054ed8c49e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50058
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made JSDebuggerWebsocketClient.java nullsafe
Reviewed By: mdvacca
Differential Revision: D71126385
fbshipit-source-id: 8707e8c6b8092c0c301dc81a363758b60f38086a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50057
Note this diff is only adding FIXMEs that will be removed in the next diff. This diff exists to make the next diff easily reviewable
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D71126392
fbshipit-source-id: 96464734a2edc7ec242cd3f3646222587d89eb2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50056
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made MultipartStreamReader.java nullsafe
Reviewed By: mdvacca
Differential Revision: D71126393
fbshipit-source-id: 3b621be82cd874c608cb610ba35dff0be7cbd195
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50055
Note this diff is only adding FIXMEs that will be removed in the next diff. This diff exists to make the next diff easily reviewable
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D71126389
fbshipit-source-id: f41d3fbdfdfcde28a8bfc1d52efaca6a8b0fcb1a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50054
Gone trough all the FIXMEs added in the previous diff by the nullsafe tool, marked the class as nullsafe and ensured no remaining violations.
Changelog: [Android][Fixed] Made StackTraceHelper.java nullsafe
Reviewed By: javache
Differential Revision: D71126387
fbshipit-source-id: 3456dde049b50e48ad703fe8312cf57b8d849515
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50053
Note this diff is only adding FIXMEs that will be removed in the next diff. This diff exists to make the next diff easily reviewable
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D71126384
fbshipit-source-id: 6a2e348f75b0b589de080bf060c4669db82a69c6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50091
Changelog: [internal]
If a library uses mount hooks to perform mount operations, it's possible to get concurrent modifications of the list of pending surface IDs to report.
This fixes that potential error by making a copy of the list before dispatching the mount notifications.
Fixes https://github.com/facebook/react-native/issues/49783.
Reviewed By: javache
Differential Revision: D71387739
fbshipit-source-id: 96c723ef2d6bcc659c4452434b7a4d5af26117ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50090
Changelog: [internal]
I refactored `FabricUIManager` in D54547194 / https://github.com/facebook/react-native/pull/43337 and accidentally removed setting this flag to avoid scheduling redundant tasks in the UI thread to report mount. This fixes it.
Reviewed By: javache
Differential Revision: D71387374
fbshipit-source-id: cad8a3ead2434738325560902cbab817e5d5dde7
Summary:
Headers are currently copied into each arch in the final xcframework. This is not necessary and will cause a lot of duplication since these files are the same for all archs.
This commit fixes this by only copying headers when we build the final XCFramework:
- ReactNativeDependencies.podspec: Changed the prepare script to be more resilient to different header structs, since we have multiple ways of packaging our tarballs locally and on the servers
- build.js: Removed copying headers when building frameworks
- compose-framework.js: Added copying headers once to the root of the XCFramework.
- rndependencies.rb: updated docs with correct ENV vars
bypass-github-export-checks
## Changelog:
[INTERNAL] - Changes the header structure in our XCFramework to avoid duplication
Pull Request resolved: https://github.com/facebook/react-native/pull/50085
Test Plan: Run RNTester with RCT_USE_RN_DEPS=1 to use prebuilt RN Deps.
Reviewed By: javache
Differential Revision: D71385183
Pulled By: cipolleschi
fbshipit-source-id: 160d56dea7f61d1b8d0a45b80f6c0789647358e6
Summary:
We had some issues with the Swift package build step where we saw an error message when we included resources and couldn't find out why this was happening.
After systematically going through the generated swift package file and looking for a reason I found a mistake.
When we generate the Package.swift file we pass all compilerFlags from the configuration of the target to both cpp/c flags - which in the case of the folly target ends up being passed to the dependency scanner which isn't too happy about this c++ flag.
The solution was to split `compilerFlags` into `cCompilerFlags` and `cxxCompilerFlags`.
This commit fixes this by:
- split `compilerFlags` into `cCompilerFlags` and `cxxCompilerFlags`.
- Updated configuration with correct settings
- Updated Package.swift generation to use these new flags
- Fixed issue with the copy bundles step that didn't copy the directory in some cases.
## Changelog:
[INTERNAL] - Fixed processing resources in the generated swift package for the RN Dependencies/prebuild
## Test-plan
Test by prebuilding RNDependencies, include the XCFramework in a new app and try to load resource bundles:
```obj-c
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
std::string input = "3.1416 xyz ";
double_conversion::DoubleToStringConverter::EcmaScriptConverter();
LOG(INFO) << "Hello from GLOG";
fmt::print("Hello, world from FMT!\n");
BOOST_ASSERT(100 == 100);
double result;
fast_float::from_chars(input.data(), input.data() + input.size(), result);
LOG(INFO) << "Answer :" << result;
NSArray *frameworks = [NSBundle allFrameworks];
for (NSBundle *framework in frameworks) {
NSString *frameworkName = framework.bundleURL.lastPathComponent;
if ([frameworkName isEqualToString: @"ReactNativeDependencies.framework"]) {
[self loadBundle:framework bundleName:@"ReactNativeDependencies_glog"];
[self loadBundle:framework bundleName:@"ReactNativeDependencies_boost"];
[self loadBundle:framework bundleName:@"ReactNativeDependencies_folly"];
break;
}
}
return YES;
}
- (void) loadBundle:(NSBundle*)framework bundleName: (NSString*)bundleName {
NSBundle *bundle = [NSBundle bundleWithURL:[framework bundleURL]];
NSURL *bundleURL = [bundle URLForResource:bundleName withExtension:@"bundle"];
NSBundle *resourceBundle = [NSBundle bundleWithURL:bundleURL];
NSURL* url = [resourceBundle URLForResource:@"PrivacyInfo" withExtension:@"xcprivacy"];
if (url == nil) {
LOG(ERROR) << "Could not find PrivacyInfo.xcprivacy in the " << [bundleName UTF8String] << " bundle";
} else {
LOG(INFO) << "Found PrivacyInfo.xcprivacy in " << [bundleName UTF8String] << ".";
}
}
```
Pull Request resolved: https://github.com/facebook/react-native/pull/50050
Reviewed By: javache
Differential Revision: D71316215
Pulled By: cipolleschi
fbshipit-source-id: 53093f962874101f5618997fdac3dd4550768da5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50092
`oldProps` can be null, so this is an unsafe dereference. We also typically compare with `_props`, which represents the previous state of the component.
Changelog: [General][Fixed] Fixed crash in RCTPullToRefreshViewComponentView#updateProps
Reviewed By: cipolleschi
Differential Revision: D71388015
fbshipit-source-id: deff9c581ee207c4481056a720c10dfd661f088d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50088
Changelog: [internal]
This fixes a crash when using the `fixMountingCoordinatorReportedPendingTransactionsOnAndroid` feature flag. The problem was that we were accessing the surface handler registry safely, but there were cases where invalid surface handler references were being kept in the registry.
Reviewed By: javache
Differential Revision: D71387111
fbshipit-source-id: 643fcdf10c4c5751d77e276efb37795b7af726bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50077
Currently, `DevServerHelper` will fetch malformed URLs if the supplied `resourcePath` has a leading slash.
This diff adds a warning and automatically trims the leading slash when this happens.
Changelog:
[Android][Changed] - Leading slash supplied to `DevServerHelper.downloadBundleResourceFromUrlSync` will now be trimmed and emit a warning.
Reviewed By: robhogan
Differential Revision: D71333088
fbshipit-source-id: 636c9c6c6919d1e9d4a829ed5ae7253f829e549c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50071
Pull Request resolved: https://github.com/facebook/react-native/pull/50070
Changelog:
[General][Internal] Send code and close reasons when we close the connection to any websockets from the dev middleware
This should improve the debuggability of our code.
Reviewed By: robhogan
Differential Revision: D71314509
fbshipit-source-id: 1d6fc57a8601bcea78e95a87d423c7c46c51e799
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49950
Changelog: [GENERAL][CHANGED] - Changed `react-native-codegen` to support types under `CodegenTypes` namespace
## Summary
Currently, codegen relies on deep importing types under `react-native/Libraries/Types/CodegenTypes` to be properly type-checked. Updating codegen to support types under a single namespace will enable us to provide a single import from the package with access to all relevant types.
Reviewed By: huntie
Differential Revision: D70967809
fbshipit-source-id: 41241dcc51965f4243acd34e8b63475cb56ca67a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50030
In Flow importing Node from react is equivalent importing ReactNode in Typescript. During translation Node is not translated to ReactNode but React.Node is translated to React.ReactNode. The easiest solution is to migrate all "Node" types to "React.Node" so that the translation is correct. To make sure that everyone follow the lint rule is added that checks for Node imports from react.
Changelog:
[Internal] - Added lint rule preventing "Node" imports from react and migrated "Node" types to use React namespace in react-native
Reviewed By: javache, huntie
Differential Revision: D71189533
fbshipit-source-id: baea8feb46be3dc30b6e58bcefe140655ec0530a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50027
Changelog: [IOS][CHANGED] - Overwrite betterHitTest in RCTScrollViewComponentView instead of changing layout metrics of the container view
## Summary:
In https://github.com/facebook/react-native/pull/49855 I changed the container view of `RCTScrollViewComponentView` to be `RCTViewComponentView` instead of `UIView` so the touches would bass through its `betterHitTest` implementation (along with udating its layout metrics so the right path in the function is chosen). This resulted in some issues and the alternative approach of customizing the hit testing of the ScrollView itself might be a better approach.
This PR changes overwrites the `betterHitTest` method in a way that the `containerView` is entirely skipped during hit testing, instead forwarding the call to its children. This way, it won't prevent touches outside its frame from being delivered to children that extend out of the frame.
Reviewed By: cipolleschi
Differential Revision: D71187882
fbshipit-source-id: 9d0c79048f389b9bee37dea1e59226b54ddbe6f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50028
Changelog: [IOS][CHANGED] - Replace a workaround for measuring multiline text with `maximumNumberOfLines` on iOS with a proper solution
## Summary:
In https://github.com/facebook/react-native/pull/49549 support for `numberOfLines` was added to iOS `TextInput`. Along that, a workaround for measuring multiline text with limited number of lines was added to avoid an edge case coming from `NSTextContainer` measuring empty lines even if they are over the line limit.
This PR handles that case properly by counting and measuring individual lines to properly handle the offending edge case.
Reviewed By: NickGerleman
Differential Revision: D71111841
fbshipit-source-id: 6adb4450a13fcc845604622ea76576658a7537aa
Summary:
As discussed with huntie, this is not a breaking change.
Changelog:
[Internal] [Changed] -
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D71201094
fbshipit-source-id: 3a27e621ac7718e4574c7981e5d64802e36e74cd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50035
changelog: [internal]
to make it easier to write JSDocs, let's export functions directly from index.js instead of using proxy object.
Reviewed By: rubennorte
Differential Revision: D71200977
fbshipit-source-id: 0b53c0d3f73577c19253537b9e884459a4920643
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50022
RCTHostTests.mm calls `makeHermesRuntime`, which is from `hermes.h`. Explicitly include the header so that RCTHostTests isn't getting it indirectly.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D71146426
fbshipit-source-id: 5a5f5a466e1920797c4531773ca23f53eb1203b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50033
changelog: [internal]
All public APIs should be covered with tests, this diff adds tests for Fantom.scheduleTask.
Reviewed By: rubennorte
Differential Revision: D71195921
fbshipit-source-id: dc7f0f889b9633b1e641dc8887fd506bc4753fe5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50013
The diff incorporates event-target-shim types that will be referenced by generated TS types to make sure that the public API does not change unexpectedly. The generated tsconfig contains path property which tells Typescript to use copied types instead of the downloaded event-target-shims types.
Changelog:
[internal] - Moved event-target-shim types to react-native package.
Reviewed By: huntie
Differential Revision: D71044389
fbshipit-source-id: b2837cc880a2161f7ff716470fd6eb4644d514e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50019
Changelog: [internal]
This adds some basic tests for the API to show that it's working correctly.
This was in response to https://github.com/facebook/react-native/issues/49684. If there are use cases that we think are incorrectly handled, we should add them to this test.
Reviewed By: cortinico
Differential Revision: D71128943
fbshipit-source-id: 73876ba514c23ec8f829723500fa408512b90222
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49942
iOS flushes NativeAnimated operations to the UI thread in one of two ways:
1. Some operations flush immediately when the operation is queued, namely startAnimation, stopAnimation, and setValue.
2. Other operations rely on flushing from one of the previous operation types, or a UIManager mount callback.
This behavior leads to non-determinism in flushing of some operations like `setOffset` or `startListeningToAnimatedNodeValue`, where if these operations are created, out-of-band from "flushed" operations, they will not take affect until the next React commit.
This change wires up the `animatedShouldSignalBatch` feature flag to queue operations on the JS thread, and flush them after `NativeAnimated.finishOperationBatch` is called.
## Changelog
[Internal]
Reviewed By: javache
Differential Revision: D70904592
fbshipit-source-id: 6bc7a8614cbe5e275d4d7bf5310da9f0090c0e10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49989
Changelog: [internal]
This experiment didn't yield any significant wins and there are some failing e2e tests which seem suspicious, so better be safe and keep the current version.
Reviewed By: javache
Differential Revision: D71050517
fbshipit-source-id: da14fdd49e8d39cdcdc1dd579a50af3bf894d08a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50014
This was unintentionally made public during the Kotlin migration (D67791375), revert back to internal visibility, and update some of the deprecation comments.
Changelog: [Android][Removed] TouchesHelper is no longer part of the public API
Reviewed By: Abbondanzo
Differential Revision: D71114176
fbshipit-source-id: 2bd8882039fb972e1c2632a503292080c56a2f22
Summary:
If you use this preset to create library code, it is often helpful to be able to still read the transpiled code, even when sourcemaps are available.
This change adds a compact option which allows for disabling the default behavior that removes whitespace from the transpiled files.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[GENERAL] [ADDED] - Add `compact` option to `react-native/babel-preset` to allow disabling whitespace removal
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/49979
Reviewed By: rshest
Differential Revision: D71109024
Pulled By: robhogan
fbshipit-source-id: ab205cca2a82b56955d1e1c55e288dcbe7754f8f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50002
Creates a new feature flag, `avoidAnimatedRefInvalidation`, to experiment with changing `useAnimatedProps`, so that the returned ref callback is no longer invalidated when `props` changes.
When we introduced `useAnimatedPropsMemo` and stabilized `AnimatedProps` (which is only invalidated when `AnimatedValue` and shallow `AnimatedEvent` instances are changed in an update), we should have also made this change. It was an oversight that we did not do this.
Avoiding unnecessary invalidation of the ref callback is important to reduce extra work and unpredictable semantics associated with unnecessary detaching and re-attaching of refs.
Changelog:
[Internal]
Reviewed By: lunaleaps, jbrown215
Differential Revision: D71074781
fbshipit-source-id: 82386a79b8e9bed0b74d9b85978af66f453a7ad0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49991
This change adds nightly support for prebuilds.
t works the same way hermes works: if the react native version contains nightly, we try to use that version to download the right tarball.
To work, it needs to use the `RCT_USE_RN_DEP` env variable.
## Changelog
[Internal] - Add Nightly support to consume ReactNativeDependencies
Reviewed By: cortinico
Differential Revision: D71050926
fbshipit-source-id: 9f461b5f17fde960d92b4082bc60f76959e82cdf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49978
This change connects the RNDependencies we prebuild in CI with the other iOS jobs we have.
By doing so, we aim to speed up the build time in CI, saving time and money.
## Changelog:
[Internal] - Connect the ReactNativeDependencies in CI
Reviewed By: cortinico
Differential Revision: D71034587
fbshipit-source-id: 14f1237f4fb57ee103a80be1718042d66ff7b0d7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49970
This change add supports to pass a tarball from a local file to the ReactNativeDependencies podspec, so that we can build React Native using a local copy or the RNDependencies and we can use it also in CI.
## Changelog:
[INTERNAL] - Add support for local tarballs
Reviewed By: cortinico
Differential Revision: D71032641
fbshipit-source-id: d83c96c8c12f3add45f8f5ea15fa0eac06d0bedf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49968
Updates all the core podspec to use the new `ReactNativeDependencies` podspec
## Changelog:
[INTERNAL] - Updates Modules in core to use the new dependencies.
Test Plan:
✅ Run Rn-Tester and verify that it works as expected both building deps from source and using prebuilt tarballs
✅ Add third-party library (react-native-reanimated) and perform the same tests to verify that it works with the changed podspec and utilities
Reviewed By: cortinico
Differential Revision: D71032639
Pulled By: cipolleschi
fbshipit-source-id: e53179a8c1b47ee2b945f5cb5dfaf3f6f2755af2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49971
Updated the Cocoapods infrastructure to use the new the `ReactNativeDependencies.podspec`
## Changelog:
[INTERNAL] - Configured the Cocoapods infra to use the new `ReactNativeDependencies.podspec`
Test Plan:
✅ Run Rn-Tester and verify that it works as expected both building deps from source and using prebuilt tarballs
✅ Add third-party library (react-native-reanimated) and perform the same tests to verify that it works with the changed podspec and utilities
Reviewed By: javache, cortinico
Differential Revision: D71032638
Pulled By: cipolleschi
fbshipit-source-id: 154c8891d5b8b4b84952274c169479122a4800b1
Summary:
There are two environment variables that is related to ReactNativeDependencies:
- `RCT_USE_DEP_PREBUILD `: If set to 1, ReactNativeDependencies will be built from source.
- `RCT_DEPS_VERSION`: If set to 1, it will override the version of ReactNativeDependencies to be used.
bypass-github-export-checks
## Changelog:
[INTERNAL] - Introduced functions to configure ReactNativeDependencies in Cocoapods
Pull Request resolved: https://github.com/facebook/react-native/pull/49812
Test Plan:
✅ Run Rn-Tester and verify that it works as expected both building deps from source and using prebuilt tarballs
✅ Add third-party library (react-native-reanimated) and perform the same tests to verify that it works with the changed podspec and utilities
Reviewed By: javache
Differential Revision: D70968672
Pulled By: cipolleschi
fbshipit-source-id: bb93e763bd71cec7314565b5a751b226735b404e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49969
Improved RCT-Folly podspec by configuring it as a prepare step, so that we don't need to forward the folly flags to all the others pods and to 3rd party dependencies.
## Changelog:
[INTERNAL] - Configure folly in a prepare step
Test Plan:
✅ Run Rn-Tester and verify that it works as expected both building deps from source and using prebuilt tarballs
✅ Add third-party library (react-native-reanimated) and perform the same tests to verify that it works with the changed podspec and utilities
Reviewed By: javache
Differential Revision: D71032640
Pulled By: cipolleschi
fbshipit-source-id: a34a9b38fa5d5b37a0a193a73659f0d45dd3d660
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50008
The diff adds extraction of triple-slash directives using regex to match and retrieve following reference.
Changelog:
[internal] - Added support for triple-slash directives in generated .d.ts files
Reviewed By: huntie
Differential Revision: D71113674
fbshipit-source-id: 2207d5b455515c44ba585ffecc063914e0818e58
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50011
changelog: [internal]
Majority of time, you want to simply scroll. This diff introduces a convenience method Fantom.scrollTo.
Previously, you would have to write:
```
Fantom.runOnUIThread(() => {
Fantom.enqueueScrollEvent(element, {
x: 0,
y: 60,
});
});
Fantom.runWorkLoop();
```
Now, you can just do:
```
Fantom.scrollTo(element, {
x: 0,
y: 60,
});
```
Reviewed By: rubennorte
Differential Revision: D71113680
fbshipit-source-id: aed49a2f12be8ab30be549235cc7a2b3e35faadb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50009
changelog: [internal]
rename method `scrollTo` to `enqueueOnScrollEvent` to make it obvious that event is only enqueued and not executed.
Reviewed By: rubennorte
Differential Revision: D71027761
fbshipit-source-id: 8a22babc2f5e86196c0b0af75ab65d539048dc72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49975
Removes the "Plugins" category from the non-structural grouping of exports in `index.js`, `index.js.flow`, aligning these with the "APIs" and "Components" categories in our docs.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D71033295
fbshipit-source-id: bd39bb6ff5e30c1ed0a8d56d1ed61d52120fb776
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49990
Changelog: [internal]
This cleans up the flag and makes the Document API essentially part of the DOM APIs flag, after we've verified this is stable in a production experiment.
Reviewed By: sammy-SC
Differential Revision: D68772174
fbshipit-source-id: 3b3d0c4369a648faab3dc7caed8eec2c95fa05b3
Summary:
Android's onAnimationEnd callback is lossy and ocasionally just does not fire. However the LayoutAnimationController maintains a sparse array of animations (with Strong View refs) that is only cleaned when the onAnimationEnd callback is invoked. This results in a leak of Android View objects over time.
To avoid this, the Strong View refs are migrated to WeakReference's and the associated sparse array is cleaned of any invalid layout animations in response to the reset() call.
This closes two leaks:
1. Unbound growth in LayoutAnimationController::mLayoutHandlers
2. Pinning View objects into memory as the sole remaining GC root
## Changelog:
1. Made OpacityAnimation and PositionAndSizeAnimation classes hold weak refs to views only
2. Added a method to LayoutHandlingAnimation to surface if their view ref is gone
3. Added cleanup for Animation with bad view refs
Pick one each for the category and type tags:
[ANDROID] [Fixed]- Fixes memory leak
Pull Request resolved: https://github.com/facebook/react-native/pull/49959
Test Plan: * Primarily code inspection and regression given the intermittent nature of Android's failure to execute the callback.
Reviewed By: alanleedev
Differential Revision: D71037262
Pulled By: javache
fbshipit-source-id: 1fa4eaa2ca839f347a55cb37e2648db972748586
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50001
Updates `react-native/.flowconfig` with the following option:
```
react.runtime=automatic
```
This adjusts Flow to model the current behavior of React and JSX, relaxing the requirement that JSX elements have `React` within scope.
Changelog:
[General][Changed] - Changed Flow for the React Native monorepo, so that `React` no longer has to be in scope when using JSX.
Reviewed By: javache
Differential Revision: D71096283
fbshipit-source-id: 65762ac39206c682b7be5d3f512b2b83f7eb1b49
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50000
This adds some tests that verify that controlled textinput, via text prop, or children creating attributedstring, does not jumble text, so long as JS side does not mutate underlying text content.
The rewriting/max length example does still run into problems here.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D71076703
fbshipit-source-id: 85995e8cc087533b1115f158ba5dad67ed008289
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49999
Changelog: [Internal]
Early initialize call to RCTScreenSize which is used by Modal and will read screen size off the UI Thread to avoid main thread deadlocks
Reviewed By: sammy-SC
Differential Revision: D70999156
fbshipit-source-id: 47fb8666c3330ee67cbcb430060f0cec37ec3c7c
Summary:
We were missing some null checks that could cause a crash.
There seems to be some cases where either the parent or the currently focused View are present on Android's hierarchy but not present on the Shadow Tree, in this cases we can just return a nullptr to fall back to default focusing behavior on Android.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D71050870
fbshipit-source-id: a4b4e533c4e9a59c53190feb4b23db4b436b8ae9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49987
I went through the whole changelog for 0.79 and applied categories to all the entries + did some significant cleanup (remove some entries that were actually internals, grouped and sorted various items)..
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D71003373
fbshipit-source-id: 5a95e619f1cf2ffc84263b92104efee16fd74e53
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49941
This diff introduces annotations into the ios codegen config!
## Before
In the new architecture, people can declare module/component codegen config in [package.json](https://reactnative.dev/docs/the-new-architecture/using-codegen#configuring-codegen)
This config contains the following maps:
- modulesConformingToProtocol
- modulesProvider
- componentProvider
```
"codegenConfig": {
"name": "HelloWorldSampleModule",
"type": "all",
"jsSrcsDir": "specs",
"android": {
"javaPackageName": "com.helloworld"
},
"ios": {
"modulesConformingToProtocol": {
"RCTImageURLLoader": [
"RCTHelloWorldImageURLLoader"
],
"RCTURLRequestHandler": [
"RCTHelloWorldURLRequestHandler"
],
"RCTImageDataDecoder": [
"RCTHelloWorldImageDataDecoder"
]
},
"modulesProvider": {
"HelloWorldImageURLLoader": "RCTHelloWorldImageURLLoader",
"HelloWorldURLRequestHandler": "RCTHelloWorldURLRequestHandler",
"HelloWorldImageDataDecoder": "RCTHelloWorldImageDataDecoder"
},
"componentProvider": {
"FooComponent": "RCTFooComponentClass"
}
}
```
## After
This information is a little bit easier to understand if we group it by module/component (into **annotations**):
(that's what this diff does!)
```
"codegenConfig": {
"name": "HelloWorldSampleModule",
"type": "all",
"jsSrcsDir": "specs",
"android": {
"javaPackageName": "com.helloworld"
},
"ios": {
"modules": {
"HelloWorldImageURLLoader": {
"conformsToProtocols": ["RCTImageURLLoader"],
"className": "RCTHelloWorldImageURLLoader"
},
"HelloWorldURLRequestHandler": {
"conformsToProtocols": ["RCTURLRequestHandler"],
"className": "RCTHelloWorldURLRequestHandler"
},
"HelloWorldImageDataDecoder": {
"conformsToProtocols": ["RCTImageDataDecoder"],
"className": "RCTHelloWorldImageDataDecoder"
}
},
"components": {
"FooComponent": {
"className": "RCTFooComponent"
}
},
}
```
## Migration
The old way is still supported (for now). We will deprecate it soon, and eventually remove it from react native!
Changelog: [iOS][Added] - Codegen: Introduce module/component annotations inside package.json
Reviewed By: mdvacca
Differential Revision: D70822061
fbshipit-source-id: 87ec5664a551c54b9300ba92987f237a601ccfbf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49940
This will just make sure that we don't unintentionally break this script.
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D70919549
fbshipit-source-id: 6d9f2acca46486f1c920afed69609c70f53e6b18
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49992
changelog: [internal]
View culling does not play along with view flattening/unflattening. This diff adds a test case for it + fix. Previously, view culling would crash.
There are still untested branches of view flattening/unflattening where I am trying to come up with test cases.
Reviewed By: rubennorte
Differential Revision: D71047032
fbshipit-source-id: 9f52473743755e49e4bfda0783803cb79591ca27
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49908
There are various batching mechanisms across react-native platforms. The NativeAnimated startOperationBatch and finishOperationBatch methods are a useful way to signal that complete animation graphs are established for atomic flushes to the UI thread.
Setting up this feature flag for use across non-Android React Native platforms.
## Changelog
[Internal]
Reviewed By: javache
Differential Revision: D70827938
fbshipit-source-id: 4c4a74e9a11f75090152637d6195092f5af866a0
Summary:
This PR (https://github.com/facebook/react-native/pull/48182) introduced skipping hidden folders during Codegen generation.
However, when using pnpm, all files are stored in the `.pnpm` folder (see explanation here: https://pnpm.io/symlinked-node-modules-structure).
As a result, some libraries that support the new architecture but lack the `ios.codegenConfig.componentProvider` field - like [FlashList](https://github.com/Shopify/flash-list/blob/main/package.json) - will be skipped during Codegen generation.
This PR explicitly includes `.pnpm` to prevent this issue.
## Changelog:
[iOS][Fixed] - Check .pnpm folder when looking for third-party components.
Pull Request resolved: https://github.com/facebook/react-native/pull/49983
Test Plan:
Tested on:
RN 0.78.0
PNPM: 10
Flashlist: 1.7.3
Reviewed By: cipolleschi
Differential Revision: D71047936
Pulled By: cortinico
fbshipit-source-id: fa9caab23dea8c92ef5f23c997812d348eb19e08
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49981
Changelog: [internal]
(because MutationObserver isn't a public API yet)
## Context
`MutationObserver` is a [JavaScript API](https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver) used to report mutations in the DOM tree. The mutations available on Web are: changing children, changing attributes and changing text. In React Native, only changing children is supported.
Mutation detection needs to happen synchronously when mutations happen (in ShadowTree commits) and the notification is dispatched as a microtask in JS, which means we can only report mutations happening in JavaScript.
There's an assumption that only React (in JS) can change the structure of the tree in Fabric, so we implemented `MutationObserver` considering this assummption.
Unfortunately, while the assumption is correct (we can only mutate children from React) the implementation didn't take into account that commit hooks were triggered from multiple threads, even if the structure doesn't change (e.g.: with Fabric state updates). In this case, we do the checks but we never dispatch the notifications. This can cause crashes (see T217617393) if we try to check for mutations from the main thread while we add new observers in the JS thread (because that logic wasn't thread safe).
This fixes that crash by, in MutationObserver, not only preventing notifications from commits not coming from React, but also preventing the determination altogether.
In order to do this, this modifies the signature of the commit hooks to also pass the commit options, and adds a new field in the commit options with the source of the commit (for now, just "React" or "Unknown").
In `MutationObserver`, before accessing the data structures of the observer, we check if the commit is coming from React, and return early otherwise.
Reviewed By: javache
Differential Revision: D71036705
fbshipit-source-id: 985c8f903375cbf876dce5174e04563f74d7621a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49973
We still depend on the Community CLI directly, supporting local development in `packages/rn-tester`. Bump to latest — contains a number of build improvements, and will align us closer to prod/next.
Changelog: [Internal]
Reviewed By: cortinico, cipolleschi
Differential Revision: D71033085
fbshipit-source-id: ddbf7df5a35951b77c36d111cfd12ad64c3b73f7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49956
This is no longer being used internally so I think we can just remove this for less complexity
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D70983663
fbshipit-source-id: 61ca5212cb45dd1c8b96aee62964ad62b410d6f1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49854
Changelog: [GENERAL][ADDED] - Codegen utility functions and types are now exported from the root package
Up to this point, third-party libraries needed to use deep imports to access codegen utilities and types This diff exports them from the main entry point, as we want to move away from supporting deep imports in OSS as a part of JS Stable API project.
Reviewed By: huntie
Differential Revision: D70628408
fbshipit-source-id: 5a6e1cb870465ede0fbc9eb8912d255aa90aa2a8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49974
Changelog: [internal]
The feature flag system currently logs an error when trying to access common feature flags (flags accessible from everywhere but defined in native) from JS if the native module isn't available.
This forces a pattern in code to check if the module is available before accessing certain feature flags, to avoid showing that error to users in the legacy architecture.
This removes the need for that pattern by adding the check in the feature flag infra itself. If TM infra isn't available, we return default values and don't log the error.
Reviewed By: rozele
Differential Revision: D70975412
fbshipit-source-id: 5544bd96aaaf046ef90ca69bc549bef4e54eb98b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49855
Changelog: [IOS][FIXED] - Fixed touch events not being dispatched to ScrollView's children when they overflow the content container
Closes https://github.com/facebook/react-native/issues/47740.
Changes the ScrollView's container view to be `RCTViewComponentView` instead of `UIView` and sets custom layout metrics to it in a way that it will propagate touch events to all children, even if they overflow its bounds.
Reviewed By: sammy-SC
Differential Revision: D70619894
fbshipit-source-id: 348a1a369489d5208d6037c8d76b223c4ab2d5f7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49582
TSIA, this is a fairly straightforward implementation since iOS likes the shape the data is already in. Note I form a stacking context since I need the native view that has `accessibilityElements` to actually be an ancestor of everything under it
Note I am not exposing anything yet on the JS side, since we need to do Android also
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D69625269
fbshipit-source-id: 836f1bb631646408a5726f126be61c0ff6afe1d0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49960
Fixes https://github.com/facebook/react-native/issues/49106
RN legacy arch, and web, will clip inline content which appears after elipsized text. This is the correct behavior, compared to new arch, which will put it in a random place depending on the platform.
`line-clamp`: https://jsfiddle.net/7xgdke1b/
`text-overflow`: https://jsfiddle.net/7xgdke1b/2/
Fabric renderer does not, funnily enough, having an `isClipped` field on `TextMeasurement::Attachment` that is never used.
This change propagates state for whether an attachment is beyond elipsized area to this measurement, then when we see it, we set empty layout results with `DisplayType::None` so that we don't create native views. We don't layout child views either, but this seems to work out okay, even when removing and re-adding `numberOfLines`.
Changelog:
[General][Fixed] - Fix New Arch handling of inline views when text truncated
Reviewed By: mdvacca
Differential Revision: D70922174
fbshipit-source-id: 8c1f4aadbf53ff64ce55b44d6c7953d9b2e40bc5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49543
When using `ReactScrollView` or `ReactHorizontalScrollView` Views with `removeClippedSubviews` keyboard navigation didn't work.
This is because keyboard navigation relies on Android's View hierarchy to find the next focusable element. With `removeClippedSubviews` the next View might've been removed from the hierarchy.
With this change we delegate the job of figuring out the next focusable element to the Shadow Tree, which will always contain layout information of the next element of the ScrollView.
Changelog: [Android][Fixed] - Fix keyboard navigation on lists with `removeClippedSubviews` enabled
Reviewed By: joevilches
Differential Revision: D69618406
fbshipit-source-id: 1df7f90066dfc685e74a89b29222937777714b87
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49961
As preparation for fixing focus on FlatList we need to prevent the currently focused view from getting clipped. This is because in Android, if the currently focused view gets clipped before transferring focus we crash.
Changelog: [Android][Changed] - Prevent currently focused child from getting clipped when `removeClippedSubviews` is enabled
Reviewed By: NickGerleman
Differential Revision: D70994348
fbshipit-source-id: 8c68eeebd7df8e7d8f788e50a3bbe46b0335ace3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49951
We previously fixed Differentiator generating an incorrect parentTag (https://github.com/facebook/react-native/pull/48055), but this can lead to crashes in Android UI due to reordering that happens in the Android mounting layer. While we have an experiment to disable this reordering (https://github.com/facebook/react-native/pull/46702) this currently has a negative performance impact which needs to be addressed.
As a mitigation, we can make the lookup of parentTag's ViewManager state nullable. We only require this to support `needsCustomLayoutForChildren`, which is not commonly used, and seems acceptable to drop in this scenario.
Changelog: [Android][Changed] Do not crash when parent view state can't be found
Reviewed By: NickGerleman
Differential Revision: D70966621
fbshipit-source-id: 33d0b6a90860788a4c9a8c6cea36c2c72c1392e1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49937
Adding an assert for recycled views still attached to their parent, which would lead to an exception when the view would be added to a new parent.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D70922503
fbshipit-source-id: 7d4daf427306203d603c31999ab138b3aee08e83
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49954
We have a different version of OkHttp internally and in OSS so we need to suppress these for now.
Changelog: [Internal]
Reviewed By: Abbondanzo
Differential Revision: D70975145
fbshipit-source-id: cd2a3ab5cdc52f25c78cb608e917fa3ca378e4f1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49817
changelog: [internal]
Remove feature flag excludeYogaFromRawProps. It did not yield any performance wins and the code to support the feature is spread across multiple classes. Removal simplifies complexity.
Reviewed By: javache
Differential Revision: D70389071
fbshipit-source-id: 21751f56aec8de501ff1e1efafda035069d8ef48
Summary:
Migrate com.facebook.react.uimanager.layoutanimation.OpacityAnimation to Kotlin.
I moved out `OpacityAnimationListener` as well in this PR to separate concerns and align more with the codebase.
## Changelog:
[INTERNAL] - Migrate com.facebook.react.uimanager.layoutanimation.OpacityAnimation to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/49822
Test Plan:
```bash
yarn test-android
yarn android
```
Reviewed By: javache
Differential Revision: D70588884
Pulled By: alanleedev
fbshipit-source-id: 1b70f5e5facd5f47b828090e7c63a218229000cb
Summary:
When using the `login-password` prompt type, there is a TypeScript type mismatch issue. The `callbackOrButtons` parameter returns an object with `{login: string, password: string}` structure, but this type variation is not properly included in the **AlertType** type definition. This causes TypeScript to show type errors when using callback functions that expect credentials in the format `(credentials: {login: string, password: string}) => void`.
## Changelog:
- [General] [Fixed] Add missing type variation `{login: string, password: string}` to **AlertType** type definition to properly support `login-password` prompt callbacks
Pull Request resolved: https://github.com/facebook/react-native/pull/49757
Test Plan: This change is purely type-related and doesn't affect runtime behavior.
Reviewed By: NickGerleman
Differential Revision: D70797036
Pulled By: alanleedev
fbshipit-source-id: 8e27a39f0c8f49083730c683b41b69173715bd68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49927
This change automates updating App's Info.plist with the new `RCTNewArchEnabled` boolean entry. The value depends on how the pod install is set up. In this way, we maintain the previous UX to enable/disable the New Arch.
## Context
The RCT_NEW_ARCH_ENABLE flag is a compile time flag we used for almost two years to configure the iOS apps and to determine whether the app should build with the New Arch or not.
However, given that we are looking into prebuilding React Native, we have to get rid of all the compilation flags, because they would require us to prebuild a combinatorial number of artifacts for react native. For example:
- New Arch / Hermes
- Old Arch / Hermes
- New Arch / JSC
- Old Arch / JSC
- ...
## Backward compatibility
We are going to keep adding the RCT_NEW_ARCH_ENABLED flag in all the dependencies, through the cocoapods inrastructure, so libraries, which are not prebuilt, will be build for the right architecture by the app itself.
## Changelog:
[iOS][Added] -
Reviewed By: cortinico
Differential Revision: D70888212
fbshipit-source-id: 541a818e02ccb96c822de29b0714646d1e69a5a9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49924
This change deprecates the RCT_NEW_ARCH_ENABLEd flag to toggle the New Architecture.
The new approach bring iOS closer to Android: to diasable the New Architecture, user needs to modify the App's Info.plist and add a `RCTNewArchEnabled` boolean entry and set it to `NO`.
The absence of the entry implies that the New Arch is enabled. (Defaults to enabled)
This also deprecates the `RCTSetNewArchEnabled` function because it makes no sense now
## Context
The RCT_NEW_ARCH_ENABLE flag is a compile time flag we used for almost two years to configure the iOS apps and to determine whether the app should build with the New Arch or not.
However, given that we are looking into prebuilding React Native, we have to get rid of all the compilation flags, because they would require us to prebuild a combinatorial number of artifacts for react native. For example:
- New Arch / Hermes
- Old Arch / Hermes
- New Arch / JSC
- Old Arch / JSC
- ...
## Backward compatibility
We are going to keep adding the RCT_NEW_ARCH_ENABLED flag in all the dependencies, through the cocoapods inrastructure, so libraries, which are not prebuilt, will be build for the right architecture by the app itself.
## Changelog:
[iOS][Deprecated] - deprecate the `RCT_NEW_ARCH_ENABLED` and the `RCTSetNewArchEnabled`
Reviewed By: cortinico
Differential Revision: D70885454
fbshipit-source-id: 4b8404ead4900d9787049ebd0b8b3c29b272f913
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49929
X-link: https://github.com/facebook/metro/pull/1459
In the next version of Flow, we will stop bundling many of the builtin libdefs, and they have been moved to flow-typed. This diff checks in them to prepare for the deployment of the next version of Flow.
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D70896122
fbshipit-source-id: aa6bd0b1e653b983a345b0e202c8dad5058a0001
Summary:
GHA passes the version to the script with a `v` prefix. However, when we receive the version from NPM, the `v` prefix is not here.
We can fix the script by dropping the `v` when it is passed to the function.
bypass-github-export-checks
## Changelog:
[Internal] - Fix verifyPackageOnNPM
Pull Request resolved: https://github.com/facebook/react-native/pull/49944
Test Plan: GHA
Reviewed By: cortinico, fabriziocucci
Differential Revision: D70960414
Pulled By: cipolleschi
fbshipit-source-id: 4234103ebe49cf715aea4a1473a8a60978f07a9f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49936
Ensure LegacyArchitectureLogger.assertWhenLegacyArchitectureMinifyingEnabled is called only once per class loading in kotlin
changelog: [internal] internal
Reviewed By: alanleedev
Differential Revision: D70922132
fbshipit-source-id: ce4d68dc2ab0f61266e4bb5cddfc175c364f568a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49938
Recycling a `ReactViewGroup` will lead to all child views being removed from the view. To avoid having view recycling corrupt the clipping state set for the child views, ahead of base view recycling preparation this diff disables `removeClippedSubviews` so that layout changes don't run over all child views that will end up being removed anyway.
The bug reported earlier should already have been resolved by D70672120 since the view recycling of a child view would remove the view from the parent. Meaning the ReactViewGroup can only have subviews that are not prepared for recycling, any recycled view would have been removed from their parent (the ReactViewGroup)
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D70921641
fbshipit-source-id: a8b311169b268c09400d2b62008184e379f6fe79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49934
The typing of internal version of jest and the libdef in react-native has diverged a bit. This diff aligns the typing for `describe`
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D70917375
fbshipit-source-id: 9c2ab98a08394aa187712f4966748a8a60e202b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49900
This appears to fix an issue where removing a sibling with zIndex breaks drawing of the next sibling. The theory is that eager return in `onViewRemoved` prevents the view from reverting into a state where it no longer uses custom draw order. However, tracing back history, this eager return was [added](https://github.com/facebook/react-native/pull/43389) to fix a bug in Reanimated. cc bartlomiejbloniarz to confirm if [this Reanimated issue](https://github.com/software-mansion/react-native-reanimated/issues/5715) resurfaces from this change.
Fixes#49838
## Changelog
[Android][Fixed] Fixes issue with z-indexed sibling removal
Reviewed By: NickGerleman, cipolleschi
Differential Revision: D70795631
fbshipit-source-id: 500af92226be29af73f36f911ffff27a0c083ae9
Summary:
Currently, when integrating into a native app using ReactNativeFactory, when we forget to set `dependencyProvider` we get a random crash exception instructing us (depending on native modules in our app) about an unrecognized selector:

After this change we get a proper error informing us that we for got to set dependencyProvider:

## Changelog:
[IOS] [ADDED] - Useful error message about setting dependency provider
Pull Request resolved: https://github.com/facebook/react-native/pull/49843
Test Plan: CI Green
Reviewed By: cortinico
Differential Revision: D70631515
Pulled By: cipolleschi
fbshipit-source-id: d99c8fa12fdb0624a01fe16c50fe0f2d10554f94
Summary:
Migrate com.facebook.react.bridge JavaScriptContextHolder & JavaScriptExecutor to Kotlin.
In this PR I also marked the return of HermesExecutor.initHybridDefaultConfig as non-nullable to keep the conversion without logic changes. I checked that this was changed unintentionally to nullable in 12e321daf0 but I think it was not supposed to be.
## Changelog:
[INTERNAL] - Migrate com.facebook.react.bridge JavaScriptContextHolder & JavaScriptExecutor to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/49909
Test Plan:
```bash
yarn test-android
yarn android
```
Reviewed By: javache
Differential Revision: D70871012
Pulled By: Abbondanzo
fbshipit-source-id: 1c15927056baf166e520e896e92bebf664fa0229
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49931
This change fixes the app startup in the Old Architecture by implementing the loadSourceForBridge:onProgress:onComplete method in the RCTDefaultReactNativeFactoryDelegate object.
The method was missing here, so the Bridge was never trying to load the JS bundle from Metro, resulting in an empty app.
## Changelog:
[iOS][Fixed] - Implement the loadSourceForBridge:onProgress:onComplete in the RCTDefaultReactNativeFactoryDelegate.
Reviewed By: cortinico
Differential Revision: D70898811
fbshipit-source-id: 3e5d519a1965e92ace91ca6d5b316a9069279448
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49906
Task.call is equivalent to a try-catch and wrapping the result in a Task. Inlining this is cheaper than creating a TaskCompletionSource and a Runnable.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D70803554
fbshipit-source-id: 0886176be974eff67c983ce1475ad685a8021b14
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49926
Those files can be fully removed as it's not referenced at all in OSS/Internal
Changelog:
[Internal] [Changed] -
Reviewed By: fabriziocucci
Differential Revision: D70888664
fbshipit-source-id: 4cacc449aa141e0465f771bf8c52d573d4227ef5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49922
Spamming the DB with "heartbeat" events with close to 0 ping didn't give us any useful information. Instead, report high ping situations.
Changelog:
[General][Internal] Remove reporting all device and debugger heartbeat events, only report heartbeats with high round trip latency
Reviewed By: GijsWeterings
Differential Revision: D70707457
fbshipit-source-id: 6bc8a55fd32dfa60fb4f7764ac00a6218417dcb5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49907
These tests have been disabled for a while due to feature flags being introduced, fusebox flags with native dependencies, and the removal of Powermock.
Changelog: [Internal]
Reviewed By: Abbondanzo
Differential Revision: D70803553
fbshipit-source-id: d1ae6e4ca6c0d22e6a8c89bf01b28333929fa8a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49912
Changelog: [internal]
This migrates all Fantom tests to use package-relative imports from `react-native` instead of relative paths.
Note that a lot of the current deep imports (e.g.: `import ReactNativeElement from 'react-native/src/private/webapis/dom/nodes/ReactNativeElement'`) will not be necessary when we release those APIs as public.
Reviewed By: sammy-SC
Differential Revision: D70779722
fbshipit-source-id: f0d28e00ca9881dc2a3cd151b75327b26711277e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49911
Changelog: [internal]
The approach in Fantom tests is to use the public API as much as we can, but forcing us to use relative imports in tests makes it harder to see what's the public API and what's not. This disables the lint rule so we can use package imports in Fantom tests without warnings/errors.
Reviewed By: sammy-SC
Differential Revision: D70779721
fbshipit-source-id: b244e6a36060e6bc60318fe285ffcf3a81a78acd
Summary:
- Update ignore micromatch pattern to filter out `__test_fixtures__` from build output
- Remove `babel/plugin-transform-object-rest-spread`
- Remove `babel/plugin-transform-async-to-generator`
- Remove `babel/plugin-transform-destructuring`
The `package.json:engines:node` field is already set to `>=18` which makes the three Babel transforms that were removed redundant.
## Changelog:
[INTERNAL] [CHANGED] - Remove fixtures files and outdated Babel transforms from `react-native/codegen` build output
Pull Request resolved: https://github.com/facebook/react-native/pull/49916
Test Plan: - Ran against Node 18
Reviewed By: robhogan
Differential Revision: D70885090
Pulled By: cortinico
fbshipit-source-id: 328b75a6031a7ca6a9b3ed170061ffb0a47d6d93
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49898
Changelog: [internal]
In the method to access the native node reference from elements, we weren't considering the case where the element is the `documentElement`, which is a special case we were handling correctly in the case of native node references from nodes (where we also handle it possibly being a document node).
Because of this, methods in `Element` and `ReactNativeElement` weren't working correctly on the `documentElement`. We didn't catch this initially because we only tested the traversal methods defined in node in the test for `ReactNativeDocument`.
This fixes the issue.
Reviewed By: javache
Differential Revision: D70792748
fbshipit-source-id: c42d05a066efaffccade94e9d3835fb7172e2335
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49896
This change makes possible to opt-out from the New Architecture.
Env variables are always `string`s in ruby and the check was always failing because it was comparing it with a number (always false)
## Changelog:
[iOS][Fixed] - enable back the opt-out from the New Architecture
Reviewed By: cortinico
Differential Revision: D70789827
fbshipit-source-id: 7d3f96c3db22f2715dec2b649534b20e3273ea3e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49860
changelog: [internal]
now that Fantom supports tests with <Modal />, add a test to cover scenario where <ScrollView /> is inside of <Modal />.
Reviewed By: rubennorte, rshest
Differential Revision: D70696834
fbshipit-source-id: 5f51917ac5c6a2cf451906e302ee2b62c15449ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49859
changelog: [internal]
this will be used for testing purposes in Fantom.
This diff also cleans up `ModalInjection.js` which is unused.
Reviewed By: rubennorte
Differential Revision: D69883384
fbshipit-source-id: 4ff278ef174c95fd5a93f70519f14c5190a5ada5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49894
Update `babel` entries in `yarn.lock` and run:
`yarn update-babel-flow-lib-defs`
...from Metro, to regenerate our Flow definitions from Babel source, then sync to RN.
Changelog: [Internal]
Facebook
D70778791 updated some `xplat/js/yarn.lock` Babel entries, which caused `xplat/js/tools/metro/scripts/__tests__/babel-lib-defs-test.js` to start failing only when Yarn had *not* been run in `xplat/js/tools/metro`, because the hoisted `xplat/js` Babel deps were a greater version than the locked `xplat/js/tools/metro` Babel deps.
This realigns them and updates the types to unbreak the test both internally an in OSS.
Reviewed By: vzaidman
Differential Revision: D70785807
fbshipit-source-id: 59ee8adc296f9ca155dde04c1429273656a26244
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49895
Minor thing, but the fact that these fixture `package.json`s for testing a release script reference real Metro packages and versions always trips me up when I'm updating Metro (grepping, etc).
There's no need for them to mention Metro - any non-RN package is sufficient to test that the script preserves other dependencies. This swaps them for dummy packages.
Changelog: [Internal]
Reviewed By: vzaidman
Differential Revision: D70789598
fbshipit-source-id: 32f394bf1f783534b76d260908538d7b5716ef1f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49885
Updates all `metro*` dependencies to the latest `^0.82.0`.
The breaking changes in this release apply only to frameworks and integrators.
This update brings `package.json#exports` resolution enabled by default, and lazy hashing for much faster Metro startup.
Release notes:
https://github.com/facebook/metro/releases/tag/v0.82.0
Changelog:
[General][Changed] Update Metro to ^0.82.0
Reviewed By: vzaidman
Differential Revision: D70778791
fbshipit-source-id: ffb55ed384d721205aa4d7f528c63c0b0a38abc5
Summary:
acquireWakeLockNow was static before but wasn't marked as static in https://github.com/facebook/react-native/commit/9afad527b831ec0c5d50e88daacbaacbc476d478 when changing code to Kotlin.
This breaks react-native-firebase but I've submitted the bug report there as I guess it might be fixed there too.
## Changelog:
[ANDROID] [FIXED] - Marked acquireWakeLockNow as static
Pull Request resolved: https://github.com/facebook/react-native/pull/49875
Test Plan: No tests as it reverts the broken change
Reviewed By: rshest
Differential Revision: D70773675
Pulled By: javache
fbshipit-source-id: d7363702dfec078b7e6d2693d05b8ab87e818522
Summary:
This PR adds a step in CI to sign the xcframework if we have a certificate available
bypass-github-export-checks
## Changelog:
[Internal] - Sign XCFrameworks in CI
Pull Request resolved: https://github.com/facebook/react-native/pull/49871
Test Plan: GHA
Reviewed By: cortinico
Differential Revision: D70734340
Pulled By: cipolleschi
fbshipit-source-id: 244422bdf9a8e0a2075a727a91805f762d4f95c9
Summary:
This pull request includes a minor change to the `React-cxxreact.podspec` file in the `ReactCommon/cxxreact` package. The change corrects a typo in the `HEADER_SEARCH_PATHS` configuration.
## Changelog:
[IOS] [FIXED] - Corrected the path from `"$(PODS_ROOT)/fas_float/include"` to `"$(PODS_ROOT)/fast_float/include"` in the `HEADER_SEARCH_PATHS` configuration.
Pull Request resolved: https://github.com/facebook/react-native/pull/49879
Reviewed By: rshest
Differential Revision: D70773742
Pulled By: javache
fbshipit-source-id: 0823732bf45c8c17ee7d4c0c3542be5c286445ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49873
In the old architecture, when we were passing a `null` value as a parameter in a function that accepted nullable parameter, the null value was mapped to `nil` on iOS.
After my changes in [d4236791e2](https://github.com/facebook/react-native/commit/d4236791e238a614d2fadf5c5659874d983ab029), in the New Architecture, through the interop layer, legacy modules were receiving an `NSNull` object instead of nil.
This was breaking those modules which started crashing or observing undesired behavior.
This change fixes the issue by making sure that, in those cases, a `nil` value is passed.
Note that nested objects in the old architecture were correctly receiving NSNull, so nested objects were behaving correctly already.
## Changelog:
[iOS][Fixed] - Properly pass `nil` for nullable parameters instead of `NSNull` for legacy modules
Reviewed By: javache
Differential Revision: D70723460
fbshipit-source-id: 384f48b6dbb3f54c369b31b6d2ee06069fa3591c
Summary:
Fixes https://github.com/facebook/react-native/issues/49819 . Details about how the issue was introduced in the issue description.
bypass-github-export-checks
## Changelog:
[IOS] [FIXED] - Fixed: extraModulesForBridge callback not called when New Architecture enabled
<!-- 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/49849
Test Plan:
Without the change:
1. Open `packages/rn-tester` project
2. In `AppDelegate.mm`, implement `extraModulesForBridge` and add a breakpoint / output something
3. Run the app in iOS <-- Verify that the method is not executed
With the change:
1-3. Same as above <-- verify that the method is called correctly
> [!NOTE]
> As far as I could tell, there is no test suite for this specific codepath, so I didn't write a test for this change. Happy to write one if someone can guide me a little bit.
Reviewed By: rshest
Differential Revision: D70724196
Pulled By: cipolleschi
fbshipit-source-id: cc08798d08cdbd6883347810c7d2697c358770fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49850
`RCTUIImageViewAnimated` has some bugs around reuse.
1. Recycling will set `image` to null, which will no-op on comparison to `self.image`, but `self.image` is always null when the image is animated, because `RCTUIImageViewAnimated` handles rendering the frames itself. This means we don't properly do things like invalidating the DisplayLink when the image is first recycled.
2. If we ever set superclass image to nil, we make some change to the underlying CALayer, which causes the content to remain black, even though we customize our own `displayLayer`. Diffing layer descriptions, we seem to afterward have a `contentsMultiplyColor` and `contentsSwizzle` on the layer that aren't public.
The solution I have in this diff is to, instead of drawing layers ourselves, update backing UIImage image to the frame. I think this would fix some other bugs as well, like tintColor not applying to animated images. My guess is that this shouldn't add too much extra work, since `UIImageView` should just be propagating the `UIImage` to the layer in a same way that we were before. This same bug may have also been possible before when switching between animated and non-animated image sources I think.
Changelog:
[iOS][Fixed] - Fix Recycling of Animated Images
Reviewed By: cipolleschi, joevilches
Differential Revision: D70668516
fbshipit-source-id: f1127da3e03ebab2b6f7584ba492b3e13448c13b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49863
After the creation of the XCFramework, that needs to be signed. After the XCFramework is signed, no further modification can happen or they would break the signature.
## Changelog:
[Internal] - Add function to sign the XCFramework
Reviewed By: cortinico
Differential Revision: D70697279
fbshipit-source-id: c2411ca7d12d4679ba55f124cbb445367b15945a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49858
`prepareToRecycleView` returns nullable, since we may decide a view is not recyclable. We should respect that and return the view returned by super.
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: fabriziocucci
Differential Revision: D70696246
fbshipit-source-id: a8e12320611a3b6a3d05353e4b7556c4da416aea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49851
Android doesn't allow to mount a view that already has a parent. View recycling removes all children from a view. But if some views don't support recycling, they'll keep a reference to their children. Children being recycled will cause an exception when being mounted.
This diff removes the view from its parent when it is being recycled. This guarantees that whatever the parent, the view can be mounted after being recycled.
bypass-github-export-checks
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D70672120
fbshipit-source-id: 023d8fb48982d6d9ae7f9c537f7f2bb21cf15066
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49837
Bootstraps the `NetworkReporter` API and `jsinspector_network` library. This will form the common C++ logic for Network Inspection in React Native DevTools.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D70554862
fbshipit-source-id: 862e255f61e21871c35b1a848caec3f34e843823
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49816
Previously, we had different versions of "debug" installed in different packages, mostly because of messed up `yarn.lock` entries.
Also, updated the package, receiving some performance improvements (no relevant breaking changes).
Changelog:
[General][Internal] update and dedupe the npm package "debug"
Reviewed By: huntie
Differential Revision: D70402368
fbshipit-source-id: 5e21bc6d92e0cb45ac1d862f100ef6dc0f21dbc1
Summary:
`jscodeshift` is only used in one module (`src/generators/components/GenerateViewConfigJs.js`, but depends on a rather complex dependency chain and has a rather large maintenance burden relative to what it's used for and the value it adds in the codebase.
Since the `GenerateViewConfigJs` module creates simple templates, using `babel/core` (and implicitly `babel/template` and `babel/types`) is a lot simpler and changes little code. The only change this introduces to the output are formatting changes (`singleQuote` and `trailingCommas` options are discarded). The code is otherwise functionally identical.
## Changelog:
[INTERNAL] [CHANGED] - Drop jscodeshift dependency from react-native/codegen
Pull Request resolved: https://github.com/facebook/react-native/pull/49641
Test Plan:
This was tested against a React Native build with the `react-native/babel-plugin-codegen` plugina active and using the snapshots in the repo itself. While the snapshots have changed in formatting, none of the outputs change the code's AST.
<details>
<summary>
Example output from <code>react-native/babel-plugin-codegen</code> to supplement the snapshot tests
</summary>
This is the example bundling output of `AndroidSwipeRefreshLayout`. This demonstrates that both the view config output and the `Commands` export continue to be generated correctly.
```js
var _interopRequireDefault = require(_dependencyMap[0]);
Object.defineProperty(exports, "__esModule", {
value: true
});
exports.default = exports.__INTERNAL_VIEW_CONFIG = exports.Commands = undefined;
var _codegenNativeCommands = _interopRequireDefault(require(_dependencyMap[1]));
var _codegenNativeComponent = _interopRequireDefault(require(_dependencyMap[2]));
var React = _interopRequireWildcard(require(_dependencyMap[3]));
function _getRequireWildcardCache(e) { if ("function" != typeof WeakMap) return null; var r = new WeakMap(), t = new WeakMap(); return (_getRequireWildcardCache = function (e) { return e ? t : r; })(e); }
function _interopRequireWildcard(e, r) { if (!r && e && e.__esModule) return e; if (null === e || "object" != typeof e && "function" != typeof e) return { default: e }; var t = _getRequireWildcardCache(r); if (t && t.has(e)) return t.get(e); var n = { __proto__: null }, a = Object.defineProperty && Object.getOwnPropertyDescriptor; for (var u in e) if ("default" !== u && {}.hasOwnProperty.call(e, u)) { var i = a ? Object.getOwnPropertyDescriptor(e, u) : null; i && (i.get || i.set) ? Object.defineProperty(n, u, i) : n[u] = e[u]; } return n.default = e, t && t.set(e, n), n; }
var NativeComponentRegistry = require(_dependencyMap[4]);
var _require = require(_dependencyMap[5]),
ConditionallyIgnoredEventHandlers = _require.ConditionallyIgnoredEventHandlers;
var _require2 = require(_dependencyMap[6]),
dispatchCommand = _require2.dispatchCommand;
var nativeComponentName = 'AndroidSwipeRefreshLayout';
var __INTERNAL_VIEW_CONFIG = exports.__INTERNAL_VIEW_CONFIG = {
uiViewClassName: "AndroidSwipeRefreshLayout",
directEventTypes: {
topRefresh: {
registrationName: "onRefresh"
}
},
validAttributes: {
enabled: true,
colors: {
process: (req => 'default' in req ? req.default : req)(require(_dependencyMap[7]))
},
progressBackgroundColor: {
process: require(_dependencyMap[8]).default
},
size: true,
progressViewOffset: true,
refreshing: true,
...ConditionallyIgnoredEventHandlers({
onRefresh: true
})
}
};
var _default = exports.default = NativeComponentRegistry.get(nativeComponentName, () => __INTERNAL_VIEW_CONFIG);
var Commands = exports.Commands = {
setNativeRefreshing(ref, value) {
dispatchCommand(ref, "setNativeRefreshing", [value]);
}
};
```
</details>
Reviewed By: yungsters
Differential Revision: D70580474
Pulled By: elicwhite
fbshipit-source-id: 85bc6578b685f19a1565ded8d7e56dc2a1ff1999
Summary:
It seems that if we update the scroll state when the state wrapper is null we can get into an out of sync state.
I've replicated the issue in HelpCenter and confirmed with a video this seems to be the case (i.e. when gazing on some cards, their corresponding frame is incorrect)
https://www.internalfb.com/intern/px/p/6xWgl
NOTE: I have accidentally stumbled upon this fix but I could really use a review from someone who has more context around the `ReactScrollViewHelper` because this change might have bigger implications I'm not aware of!
Changelog:
[Android][Fixed] - Fix occasional syncronization issue in ScrollView when rendering dynamic content with content offset
Commits affecting the React Native open source repository must have a changelog
entry in the commit summary. Every React Native release has almost 1000 commits,
and manually categorizing these commits is very time consuming.
In your diff summary, please add a `Changelog:` entry using the format:
The "Category" field may be one of:
- **Android**, for changes that affect Android.
- **iOS**, for changes that affect iOS.
- **General**, for changes that do not fit any of the other categories.
- **Internal**, for changes that would not be relevant to developers consuming
the release notes.
The "Type" field may be one of:
- **Breaking**, for breaking changes.
- **Added**, for new features.
- **Changed**, for changes in existing functionality.
- **Deprecated**, for soon-to-be removed features.
- **Removed**, for now removed features.
- **Fixed**, for any bug fixes.
- **Security**, in case of vulnerabilities.
If your change does not modify React Native's public interface, you can use:
Changelog: [Internal]
For more details, please read the wiki: https://fburl.com/react-native/changelog
Reviewed By: javache
Differential Revision: D70484547
fbshipit-source-id: c314b958eeed4dd96755539f5bbfb8f03e17a525
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49841
Changelog: [internal]
This effectively reverts D62962341 / https://github.com/facebook/react-native/pull/46563 as the experiments didn't provide the expected wins and we don't have bandwidth to iterate on this.
Reviewed By: rshest
Differential Revision: D70622429
fbshipit-source-id: c53c9437448c0a7be8f5b4f04d6369efbd99105a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49810
Changelog:
[Internal]
Migrated StyleSheet namespace content to StyleSheetExport.js to recreate it by importing * as StyleSheet, which aligns with TS namespace definition. Added .flow files that specify base type declarations and will be digested by the flow tooling.
Reviewed By: huntie
Differential Revision: D70391322
fbshipit-source-id: dd974ef282cb984a1e57d5732e3b5bdab6db4564
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49836
We were passing the path to the `RegularFile` instead of the `PublishingArtifacts` to the gradle script.
cortinico why this is not checked at build time? This should be a typing issue that should be caught at build time, also during the test-all jobs, not just when the nightly run...
## Changelog:
[Internal]
Reviewed By: cortinico
Differential Revision: D70617638
fbshipit-source-id: 67ff1aea2bd827fb110db7a0d2f3651b88a1e8cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49835
The implementation of moduleProviderForName is slightly off.
This method was supposed to replace the previous ternary expression and to enhance with the module provider call.
The ternary expression used to be
```
!RCTTurboModuleInteropEnabled() || [self _isTurboModule:moduleName] ? [self _provideObjCModule:moduleName] : nil
```
However, as you can see from the current implementation, instead of calling `RCTTurboModuleInteropEnabled()` we are calling `RCTTurboModuleEnabled()` which is clearly a mistake.
On top of that, I'm also updating the guard around the `getModuleProvider` selector as it was bypassing the other checks, and that's wrong.
## Changelog:
[Internal] - Fix moduleProviderForName method
Reviewed By: RSNara
Differential Revision: D70569552
fbshipit-source-id: ed4055da9ea385ed10323ed8d7a8772010b3a105
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49823
Introduce LegacyArchitectureLogger class, which provides logging functionality to help track and debug usage of legacy architecture components when an app is running on the new architecture. The data provided by this class will help identify classes and methods that are still being used in the new architecture when they shouldn't.
changelog: [Internal] Internal
Reviewed By: rshest
Differential Revision: D70543605
fbshipit-source-id: 56262170c03bb0fd375b8dc3cb34a7c15a69a810
Summary:
Benchmark to test changes from https://github.com/facebook/react-native/issues/49449
Might be nice to have some version of this in the repo.
## Changelog:
[INTERNAL] [ADDED] - Setup a Macrobenchmark for RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/49486
Test Plan:
### Methodology
Picked various JS file from websites (facebook, instagram) to artificially grow RN tester bundle somewhat realistically. The files are required lazily from a button press callback to simulate the code being included, but not executed, as it would be in a large app that uses lazy requires for the different screens.
I've also made the RN tester screens lazy so all their code is not loaded initially. This is more representative of real apps. Note this is implemented in a hacky way just for the purpose of this test. It would actually be nice to implement this properly.
The tests were made using low end device Samsung Galaxy A03s.
### Compression ON with 10.5 mb bundle
#### Peak allocated memory
60.9 mb
#### ReactInstance.loadJSBundler
148.64 ms
#### Benchmark
timeToFullDisplayMs min 1,825.0, median 1,911.1, max 1,994.8
timeToInitialDisplayMs min 834.9, median 860.9, max 903.9
#### APK
Size: 22.9 mb
Download size: 14.5 mb
### Compression OFF with 10.5 mb bundle
#### Peak allocated memory
51.5 mb
#### ReactInstance.loadJSBundler
946 us
#### Benchmark
timeToFullDisplayMs min 1,752.8, median 1,827.2, max 1,977.5
timeToInitialDisplayMs min 837.7, median 881.3, max 937.2
#### APK
Size: 28 mb
Download size: 14.5 mb
Reviewed By: rshest
Differential Revision: D70002286
Pulled By: cortinico
fbshipit-source-id: 436597f439ba244649373870c1facefdb12297d9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49813
Making use of the recently standardised `REACT_NATIVE_DEBUGGER_ENABLED` preprocessor flag, conditionally swap out `HostAgent` for a stub in production (non dev, non profiling) builds. This uses the same private implementation idiom as `HermesRuntimeTargetDelegate`.
This results in a **42.2kiB** size reduction (uncompressed) in production builds, due to excluding the CDP agent components of `jsinspector-modern`.
- Intentionally, we're gating just this logic, rather than several outer integration points/native bindings for `jsinspector-modern`. This is for predictability and maintenance — the Fusebox subsystem is always loaded/bound, but can fork to an empty implementation.
{F1975625351}
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D70495853
fbshipit-source-id: 00253ac71444819a917a3781efe38365acb91e85
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49786
Most of these call-sites are only used for exceptional scenarios, so we can just rely on std::to_string and do string concatenation. For a few others that may be more perf-sensitive, I switched over to `snprintf`.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D70402439
fbshipit-source-id: 3b90ebb13a7bf1c6cf30722ef636e5e8498a5b26
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49814
`bgWhiteBrigh + t = bgWhiteBright`
seems like no one was using `chalk.bgWhiteBright` before me :)
Changelog:
[General][Internal] fix type on the flow types for "chalk"
Reviewed By: huntie, hoxyq
Differential Revision: D70403987
fbshipit-source-id: 34f65e57fbb2eeadd6030557e0499db0b2603b38
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49815
The pull to refresh component props's casting is imprecise.
This change uses the more precise type for the props.
## Changelog:
[Internal] - cast props to `PullToRefreshViewProps`
Reviewed By: sammy-SC
Differential Revision: D70559080
fbshipit-source-id: c42d3d41a22683a3392813c2af25828781a68401
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49795
# Changelog: [Internal]
I've been able to reliably and consistently record samples with an interval between 2 consecutive ones to be ~0.1-0.2ms, lets bump the sampling frequency to have more frames.
On Windows, Hermes Sampler peaks at ~500Hz, so this won't have much effect.
Reviewed By: huntie
Differential Revision: D70395983
fbshipit-source-id: 9a9e619d75096a3ee75e0e1a2f8b8fff33130268
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49794
# Changelog: [Internal]
Before, we would store all User Timings and Timeline Events in the PerformanceTracer's buffer, and then add Profile event to it as well.
On larger apps, the amount of events buffered could reach ~100k, which inevitably would cause OOM.
With this approach, we will flush out buffered events from PerformanceTracer first, then do JavaScript Profile serialization, then send it over CDP straight away.
Reviewed By: huntie
Differential Revision: D70395982
fbshipit-source-id: 2c17abba421fa9c4afc4d4ca36afd98b1db50905
Summary:
Added a new template `ReactNativeVersion.kt-template.js` to be used to generate the Kotlin template for Android. Updating also the set-rn-artifacts-version script to use this template instead of the Java one.
## Changelog:
[INTERNAL] - Migrate ReactNativeVersion Android template to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/49758
Test Plan:
```bash
yarn test-android
yarn android
node ./scripts/releases/set-version.js 1000.0.0
```
Reviewed By: huntie, rshest
Differential Revision: D70486775
Pulled By: cortinico
fbshipit-source-id: 5dd1e0e2ecf4d848dc24e6c47df243a1259ab559
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49751
fast_float promises significant improvements in float parsing performance and is already what's being used in folly internally. Unifying all percentage parsing on the new css parser logic, which can use fast_float internally.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D70392268
fbshipit-source-id: 56147e5478d008bc2c34579df035ec7acf8744bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49775
Upgrading this dependency to match folly and to enable using this for number parsing across Fabric.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D70482373
fbshipit-source-id: 64429595c1126e6a06436701a7562bdf6dd962d5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49807
This change fixes a copy-and-paste mistake in passing the right parameter for publishing the ReactNativeDependencies dSYMs.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D70552858
fbshipit-source-id: fc103814420d94180d26c89ba9b405693864a64b
Summary:
X-link: https://github.com/facebook/yoga/pull/1791
Disabling RTTI for Yoga is causing std::exception to don't work properly in OSS.
Fixes: https://github.com/facebook/react-native/issues/48027
Not sure why we originally disabled RTTI for Yoga, but we have it enable for the whole
React Native build so it probably makes sense to have it enabled for Yoga as well.
Changelog:
[Internal] [Changed] - Enable RTTI to fix exception pointer issue on React Native
bypass-github-export-checks
Reviewed By: javache, NickGerleman
Differential Revision: D70386744
fbshipit-source-id: 36e3a1ddb38346d31979d5c1b77d6e9796d6a855
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49803
This refactors the whole ReactCommon to use the `target_compile_reactnative_options` macro we just introduced.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D70386740
fbshipit-source-id: 1f15ea7e182d79bbb0bedce653284808e3309e4f
Summary:
Found this issue while releasing 0.79.0-rc.0 (see [job](https://github.com/facebook/react-native/actions/runs/13649159968/job/38156418752)).
bypass-github-export-checks
```
SyntaxError: Invalid destructuring assignment target
at new AsyncFunction (<anonymous>)
at callAsyncFunction (/__w/_actions/actions/github-script/v6/dist/index.js:15143:16)
at main (/__w/_actions/actions/github-script/v6/dist/index.js:15236:26)
at /__w/_actions/actions/github-script/v6/dist/index.js:15217:1
at /__w/_actions/actions/github-script/v6/dist/index.js:15268:3
at Object.<anonymous> (/__w/_actions/actions/github-script/v6/dist/index.js:15271:12)
at Module._compile (node:internal/modules/cjs/loader:1469:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1548:10)
at Module.load (node:internal/modules/cjs/loader:1288:32)
at Module._load (node:internal/modules/cjs/loader:1104:12)
```
## Changelog:
[Internal] -
Reviewed By: cipolleschi
Differential Revision: D70552301
fbshipit-source-id: b50e3d76c7497cc218e379400d5870531669abe1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49761
LayoutAnination classes are not used on the new architecture, this diff marks the as LegacyArchitecture to drive its removal
Changelog: [Internal] internal
Reviewed By: rshest
Differential Revision: D70410096
fbshipit-source-id: cda84958985c4133c926455a5c9611773a0d32ec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49792
This removes the `$` from the `event` and `payload` identifier inside codegen.
This is causing the `-Wdollar-in-identifier-extension` warning to fire.
As I'm looking into enabling `-Wall -Werror` for React Common, this should be addressed as well.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D70500543
fbshipit-source-id: c593680961b1b98561c3985f92ade5d6ba448ac9
Summary:
This is causing the `-Wno-nullability-extension` warning to fire.
As I'm looking into enabling `Wall Werror` for ReactCommon, this should be fixed as it's causing the build to fail.
We don't use nullability extensions at all in the other JNI_OnLoad files, so it's fine (and probably better) we
replace them with a function that also doens't specify a Nullability annotation.
This is impacting only the OSS So Merging toolchain.
Changelog:
[Internal] [Changed] -
bypass-github-export-checks
Reviewed By: cipolleschi
Differential Revision: D70500544
fbshipit-source-id: 2d5b52d8f34ec026a25e8625bd0c6a1812221dea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49797
Backing D70314889 as it was breaking some internal tests.
I verified that before the backout the tests were failing and after the backout they were not.
## Changelog:
[iOS][Changed] - Reverted fix: avoid race condition crash in [RCTDataRequestHandler invalidate].
Reviewed By: Abbondanzo
Differential Revision: D70511155
fbshipit-source-id: 276f6947aa6bb648c9c9eeb5c342f336acc8a26f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49650
- Added a new template to React Native's Feature Flag's script for Canary and Experimental prerelease stages iOS
- Overload initWithDelegate to add optional releaseLevel parameter
- Add Obj-C enum for Release Level
- Use static variables to keep the context on whether a ReactNative Factory has been created and with which flags it has been created.
- Crash in case we try to create multiple factories with different feature flags.
- Creating multiple factories with the same feature flags is allowed
Changelog: [iOS] [Added] - On `RCTReactNativeFactory` add `initWithDelegate` overload with argument to specify release level for an application
Reviewed By: cipolleschi
Differential Revision: D70106210
fbshipit-source-id: 14fe4c8571621a75a7064f1ffd02a07270cea43a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49745
It turns out we want those flags to be available also inside ReactCommon so I'm moving it there.
This will allow us to reference them also inside ReactCommon and will make sure Common does not depend on Android
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D70386742
fbshipit-source-id: 3675c01f5e3f6515af6423d75e3fe145ba3d8936
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49743
Those 3rd party CMake libraries were not using our compiler flags correctly.
This fixes it.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D70386743
fbshipit-source-id: e35688f7eb3fa9bcdda1180023006d267782ceaf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49791
The cache for RNTester is broken because the matrix parameters used to test RNTester are not part of the job_id that is used to create the cache keys to restore the Podfile.lock.
This means that we have a race condition on which job of the matrix manages to save the cache. However, those caches are not always valid for the other jobs that presents different matrix parameters.
This change should fix the issue.
## Changelog:
[Internal] - Fix test-rn-tester cache Cache
Reviewed By: cortinico
Differential Revision: D70493507
fbshipit-source-id: 1db6e00507b3e9abe4400831ee1b048c620b9102
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49780
Now that we're using a minimum Metro version of 0.81.3, Metro will dynamically assert `import` or `require` based on the style of the import at source.
Asserting both is likely to cause issues with `babel/runtime` and potentially other packages - see https://github.com/facebook/metro/pull/1447.
Changelog:
[Internal] metro-config: Assert import/require dynamically when using `unstable_enablePackageExports` with Metro.
Reviewed By: hoxyq
Differential Revision: D70473577
fbshipit-source-id: b3e6fbd78e2b6fc0f9a16ec3db2c19698848e6d1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49788
Release of 0.78 was successful but it failed to verify the package of NPM because of some error in the JS files.
Preparing for 0.79, I discovered some other issues in the NPM checking scripts.
This change should fix them.
## Changelog:
[Internal] - Fix publishing scripts
Reviewed By: fabriziocucci
Differential Revision: D70489717
fbshipit-source-id: 02a37d9a86fe108c7f7d2d634b8c0727dabb153d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49746
This flag is no longer necessary since RN 0.73 so I'm cleaning it up.
Changelog:
[Internal] [Changed] -
Reviewed By: rshest
Differential Revision: D70386741
fbshipit-source-id: c2c8f998fa7b97985396b26345cfcf3474effc7b
Summary:
When setting `USE_THIRD_PARTY_JSC=1`, we don't return anything from createJSRuntimeFactory function:

It's meant to be overwritten, but we must satisfy the compiler.
## Changelog:
[IOS] [FIXED] - return nullptr when USE_THIRD_PARTY_JSC is set to true
Pull Request resolved: https://github.com/facebook/react-native/pull/49781
Test Plan: CI Green
Reviewed By: cortinico
Differential Revision: D70486837
Pulled By: cipolleschi
fbshipit-source-id: c09622f75608dc203d41167fc375a000a2f12e37
Summary:
Upstreaming a fix by ntre that fixes a crash we saw internally related to `[_queue cancelAllOperations]`.
>Calling [_queue cancelAllOperations] will release all references to any active operations.
>If the blocks of those operations have a reference to itself, it will result in dangling pointers, which could conceptually trigger a later crash if there's a race between the operation completing and it being pulled out of the queue.
>
>Add explicit strong reference while block is running.
>For good measure, fix same pattern also in RCTFileRequestHandler.
>
>Note: separately, that this code is passing the op itself as a requestToken to [delegate URLRequest:] methods is suspect. That delegate can retain said token.
## Changelog:
[IOS] [FIXED] - avoid race condition crash in [RCTDataRequestHandler invalidate]
Pull Request resolved: https://github.com/facebook/react-native/pull/49705
Test Plan: Tested internally, we no longer saw the crash after this fix.
Reviewed By: javache
Differential Revision: D70314889
Pulled By: cipolleschi
fbshipit-source-id: ebcecb4675bd1dda3d9ee60d69967feb4e05e11b
Summary:
This PR makes React Native not relying on the `window` property in AppDelegate. When running in SwiftUI lifecycle mode / SceneDelegate mode there is window property on AppDelegate. This PR fixes crashes that happen because RN asserts window property is there.
## Changelog:
[IOS] [FIXED] - make React Native work without AppDelegate window property
Pull Request resolved: https://github.com/facebook/react-native/pull/49748
Test Plan: CI Green
Reviewed By: javache
Differential Revision: D70389691
Pulled By: cipolleschi
fbshipit-source-id: fe39f123b47014ba91a080239ccd298192c92a6a
Summary:
When downloading artifacts using a pattern, GHA, by default, creates a folder for each artifacts and copies the artifacts in that folder.
This breaks the maven publishing which expects the artifacts in the `artifact` folder and not i a subfolder.
The `merge-multiple` option allow for the artifacts to be downloaded in the specified folder, without the extra folder in the path
## Changelog:
[Internal] - Avoid the creation of intermediate folder when downloading the artifacts
Pull Request resolved: https://github.com/facebook/react-native/pull/49760
Test Plan:
GHA
<img width="791" alt="Screenshot 2025-03-02 at 11 08 33" src="https://github.com/user-attachments/assets/cfc85b27-117f-4d21-97ef-67493615a5a1" />
Reviewed By: fabriziocucci
Differential Revision: D70462254
Pulled By: cipolleschi
fbshipit-source-id: ed310a90bcdea55e466d4d71942a25abc6e6986a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49726
The `InspectorProxy` debug logging became incredibly spammy making it almost unuseful unless the output is manipulated so this commit batches all these cdp messages and only desplays how many were received in the span of 5s. If no messages are received, the throttle is not triggered.
To get the actual CDP messages logged, we still log these to `Metro:InspectorProxyCDPMessages`.
Changelog:
[General][Internal] batch debug logging for cdp messages
Reviewed By: robhogan
Differential Revision: D70324724
fbshipit-source-id: a269302f52e18af6c4be651758c042596abdbad8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49755
The artifacts are uploaded without the .tar.gz extension and the gradle script fails to upload them to sonatype.
This change adds the extensions.
## Changelog:
[Internal] -
Reviewed By: sammy-SC
Differential Revision: D70443149
fbshipit-source-id: c16d1842688b82ac216ffb90ecf2b75f562cca64
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49753
Sonatype cannot sign folders. It needs a file to be signed.
To make it happen, we are compressing the xcframeworks and the dSYM with tar, and we are uploading those files instead of the folders
I also observed that the cache keys were not computed correctly, so I'm fixing them.
## Changelog:
[Internal] - use tar.gz instad of folders for dSYM and xcframeworks
Reviewed By: bvanderhoof, mofeiZ
Differential Revision: D70409314
fbshipit-source-id: 20a5ee4f24b644f4f087974ad6b0831d5769b1d9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49749
This change configures gradle and CI to properly publish the RNDependencies artifacts to Maven Central
## Changelog
[Internal] - Configure gradle to publish on Maven Central
Reviewed By: cortinico
Differential Revision: D70390191
fbshipit-source-id: fc1e1070325240584cb07fb17e58118c4c583fa9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49731
This change runs the prebuilds in all the workflows we need:
- test-all
- nightlies
- create-release
## Changelog:
[Internal] - connect the rebuild-ios workflow with the other workflows
Reviewed By: cortinico
Differential Revision: D70331579
fbshipit-source-id: 6505a32672d43d06e29e68d37bd0ceff21bd7386
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49530
This change introduces the workflow to prebuild iOS artifacts.
This will be a reusable workflow, so we can then call it as it is from test-all, nightlies and publish-release
## Changelog:
[Internal] - Create prepare artifacts workflows
Reviewed By: cortinico
Differential Revision: D69854568
fbshipit-source-id: 5dc532fa564fe7e0987ba5d133da42e04237c3cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49711
Changelog: [IOS][CHANGED] - Moved workaround for multiline text measurement with `maximumNumberOfLines` earlier in the pipeline
Reviewed By: huntie
Differential Revision: D70314397
fbshipit-source-id: ef7dbf0c4bb3d5053328d81b7d5b8208e92ee7f5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49680
changelog: [internal]
add an end to end test for AppState module.
Reviewed By: rshest
Differential Revision: D70184850
fbshipit-source-id: ead1388ceb1018e7615e50f846f3c95224be97d0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49643
## Motivation
Modernising the RN codebase to allow for modern Flow tooling to process it.
## This diff
Aligns `useAnimatedValue.js` with its manual .d.ts types.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D70096210
fbshipit-source-id: c3cd517eccf1cb68400772ddde6e5891861c927d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49741
While the test delay `PAGES_POLLING_DELAY` is usually enough to be equal to `PAGES_POLLING_INTERVAL`, in some cases we need extra time to sync that with the polling in `Devices.js`.
Changelog:
[General][Internal] - fix test
Reviewed By: huntie
Differential Revision: D70384823
fbshipit-source-id: ccb18884d32dc27636dbbb3a9786412056f90830
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49730
Changelog: [internal]
This removes all the types from "bom" that are actually not implemented in RN. For now, we're just stripping whole interfaces and not looking into specific methods/properties in interfaces that we do implement but not 100%.
`Performance`, `PerformanceObserver`, `MutationObserver` and `IntersectionObserver` are implemented but not stable yet, so they aren't exposed as globals in the types.
Reviewed By: huntie
Differential Revision: D70329185
fbshipit-source-id: 63bac619e100ca66b41df071df80dfa73d0f9651
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49737
Changelog: [internal]
Just a minor change to align with similar other option bags and TypeScript definitions.
Reviewed By: huntie
Differential Revision: D70355669
fbshipit-source-id: 37c44338c7b358eb2d25e8a14c75a78545b34bf1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49727
Changelog: [internal]
React Native doesn't define or use Service Workers, so this entire section for types is unnecessary.
Reviewed By: cortinico
Differential Revision: D70327703
fbshipit-source-id: b998eade21d19ed124824cb255a37cb9e805d151
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49724
Changelog: [internal]
This moves the type definitions for the globals defined by React Native from the repository root to the `react-native` package, in the same directory as the existing TypeScript definitions. This will make it easier for end users to configure the globals from RN using the right source of truth.
Reviewed By: huntie
Differential Revision: D70322032
fbshipit-source-id: 932df75ded0c254f2acb32e865cbbb9474c94159
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49685
## Motivation
Modernising the RN codebase to allow for modern Flow tooling to process it.
## This diff
Renames `Animated.js` to `AnimatedExports.js`, and introduces an intermediate file that reexports `* as Animated` as a default. This should have equivalent runtime behavior, but allows for a common interface file: `Animated.js.flow` to reinterpret the module as having single exports. TypeScript treats this as a namespace.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D70237239
fbshipit-source-id: f552490cb6bb721c6163272689ec9b6c68386574
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49742
Seems like publishing jobs are not happy with Gradle Config Caching.
I'm disabling it for now till we find out what's the root cause.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D70385662
fbshipit-source-id: 532c46ea1e578bab5f3e5d6814a7f7193e67a7ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49738
**Context**
- D70012142 added TM module provider support
- This was causing RN MacOS to silently fail to load any platform modules since it didn't implement the delegate method
Changelog:
[iOS][Fixed] - Add guard for custom module provider lookup in TMManager
Reviewed By: sbuggay
Differential Revision: D70357542
fbshipit-source-id: 5b338616655ecb84cdb3c60e243fdb99444af657
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49735
I always get confused when I open this file. One of the main reasons is the order of contents is quite random, so I decided to reorder things. I tried to find a style guide on this but the [google ones](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents) really just say do something that is logical so...
In general what I did was
* All instance variables, class variables, class constants, etc. are at the top of the class
* The constructor, `setDelegate`, `resetDelegate` methods are at the top of the class since these all deal with creating or destroying instances of this class
* Nested enums towards the bottom of the class so they are not in the way of people trying to reason about the methods and other contents (they are quite long)
* Delete random extra spaces / unneeded comments
* Move some private methods to be closer to the public methods that call them
Changelog: [Internal]
Reviewed By: mlord93
Differential Revision: D70345882
fbshipit-source-id: a8425c7b90c5d4fbea5ee5daa3c4ff9f7f189ce5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49649
- Added a new template to React Native's Feature Flag's script for Canary and Experimental prerelease stages
- Added a parameter to `DefaultNewArchitectureEntryPoint.kt` to select prerelease stage
Changelog: [Android] [Added] - On `DefaultNewArchitectureEntryPoint` class add property to specify the desired release level for an application
Reviewed By: rubennorte, mdvacca
Differential Revision: D69412971
fbshipit-source-id: 1a76ac723e1e06b40aad5910604e0384b208d3a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49729
# Changelog: [Internal]
The only data source for non-bridgeless setup is JavaScript samples.
Chrome DevTools frontend is built around an assumption that thread should have at least single timeline or user timing event to be represented on a timeline view. They do it for filtering out unnecessary workers threads and other.
We will emit 2 synthetic Trace Events that should cover these requirements and recorded traces that contain only JavaScript samples should now be displayed correctly.
This is where trace bounds are calculated - https://github.com/facebookexperimental/rn-chrome-devtools-frontend/blob/3adf51aa915c2deb26f5d373751a15b4d0c8f259/front_end/models/trace/handlers/MetaHandler.ts#L169-L173
Reviewed By: huntie
Differential Revision: D70328681
fbshipit-source-id: 8eca0017d85de9ecbfb49074b439d5c4fee4aa56
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49624
This change improves the iOS infra so that there is no need to modify the Swift AppDelegate or to create a Bridging Header.
## Problem
As of today, it is not possible to create a pure C++ TM and to register it through a Swift AppDelegate
## Solution
We can create a pod that can be imported in a Swift AppDelegate and that offer some pure Objective-C classes.
These classes contains a provider that can be instantiated in Swift.
The TurboModule manager delegate will ask the AppDelegate about the presence of some provider that can instantiate a pure C++ turbomodule with a given name.
The provider has an empty interface, but the implementation contains a function that can actually instantiate the TM. The function is implemented in an Objective-C++ class that imports the pure C++ turbomodule and creates it.
The TMManager extends the provider through a category to attaach the signature of the function that is implemented by the provider.
The last diff in this stack contains an exaple on how to implement this.
## Changelog:
[iOS][Added] - Wire codegen to the new TM provider to automatically register CXX modules.
Reviewed By: javache
Differential Revision: D70082999
fbshipit-source-id: 11d829450e1d17984d6f22ee5b8907073c59d008
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49611
This Change connects the pod created previously to the `RCTTuboModuleManager` so that it can ask the delegate about the CxxTurboModuleProviders.
We had to introduce a `RCTFullTurboModuleManagerDelegate` that implements both the old `TurboModuleManagerDelegate` and the new Swift compatible one.
## Problem
As of today, it is not possible to create a pure C++ TM and to register it through a Swift AppDelegate
## Solution
We can create a pod that can be imported in a Swift AppDelegate and that offer some pure Objective-C classes.
These classes contains a provider that can be instantiated in Swift.
The TurboModule manager delegate will ask the AppDelegate about the presence of some provider that can instantiate a pure C++ turbomodule with a given name.
The provider has an empty interface, but the implementation contains a function that can actually instantiate the TM. The function is implemented in an Objective-C++ class that imports the pure C++ turbomodule and creates it.
The TMManager extends the provider through a category to attaach the signature of the function that is implemented by the provider.
The last diff in this stack contains an exaple on how to implement this.
## Changelog:
[iOS][Added] - Added the React-SwiftCompatibleNativeModules pod
Reviewed By: javache
Differential Revision: D70012142
fbshipit-source-id: db96c4cd3cdd1062b12f11131b7c6c51ecd74bc7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49712
Just keeping AGP up to date to the latest patch version
Changelog:
[Android] [Changed] - Bump AGP to 8.8.2
Reviewed By: cipolleschi
Differential Revision: D70316244
fbshipit-source-id: 6e447bd04841d09717a1c6153b7e5c977a10787c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48315
# Changelog: [Internal]
> NOTE: Some CI jobs are expected to fail, because changes in Hermes D67353585 should be landed first, and then grafted to Static Hermes.
Use newly added serializer and record Trace Events for profiles.
Reviewed By: huntie
Differential Revision: D67353586
fbshipit-source-id: f3738418ec1d47ef4435f00120823845ea5e2fe5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49191
# Changelog: [Internal]
In this diff we are adding another serializer, that will receive local sampling profile (in tracing domain), and will record corresponding Trace Events with `PerformanceTracer`.
It encapsulates the logic of transforming list of samples to `"Profile"` and `"ProfileChunk"` trace events, which will be parsed by Chrome DevTools later.
Reviewed By: huntie
Differential Revision: D68439735
fbshipit-source-id: 0b3f2b3aff5b79a921e0350759e93f5b05e34d8e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49084
# Changelog: [Internal]
> NOTE: Some CI jobs are expected to fail, because changes in Hermes D67353585 should be landed first, and then grafted to Static Hermes.
Added public methods to `PerformanceTracer` instance for registering `Profile` and `ProfileChunk` Trace Events.
Also created data structs in `TraceEvent.h` to simplify serialization process for objects like call frames / samples / etc.
Reviewed By: huntie
Differential Revision: D68558805
fbshipit-source-id: f5eca0435c56828909f99ec0b47841d24ee907b6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49082
# Changelog: [Internal]
> NOTE: Some CI jobs are expected to fail, because changes in Hermes D67353585 should be landed first, and then grafted to Static Hermes.
In this diff we will:
- Call newly added API in Hermes from `HermesRuntimeTargetDelegate.cpp`
- Define format for local Sampling Profile that will be used in Tracing domain
- Implement formatter for Hermes Profile -> Tracign Profile
Reviewed By: bgirard
Differential Revision: D68414421
fbshipit-source-id: 05d76e9bcff46f88a2338490a9d858cb121f72cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49436
# Changelog: [Internal]
We will record event loop ticks and register corresponding `"RunTask"` Trace Event with our Trace Event engine.
Since this is hot path, I've added some gating under macros that are being used for Fusebox initialization.
There are also plans to add a public method to `PerformanceTracer` to get tracing status, so we could avoid cost of serialization / saving timestamps if trace is not being recorded. I believe rubennorte had plans on this, we will add it on top of that.
> Q: Why not add this to TraceSection?
Long-term, we will have a solution that will be one layer above TraceSection and this `EventLoopTaskReporterRAII`, it is risky now to modify existing `TraceSection` and rely on event names and attempt to map them to Trace Events.
Reviewed By: rubennorte
Differential Revision: D69399955
fbshipit-source-id: b26ac0c376e7dcb5755f36a27bf00dcca6cbff60
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49395
# Changelog: [Internal]
Adding a new method to `RuntimeTarget` that will register it for Tracing.
In our case, it will schedule a callback on JS executor that will register JavaScript thread with `PerformanceTracer`.
Reviewed By: huntie
Differential Revision: D69530984
fbshipit-source-id: 58cffe9e9c4482b494cfcfd3405f7bffa40cdc56
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48836
# Changelog: [Internal]
When `Tracing.start` CDP method is received, here is what happens next:
- `TracingAgent`, which intercepts the event will propagate this status to `Instance` by calling `startTracing()` on `InstanceAgent`.
- `InstanceAgent` will propagate it to `Runtime` entities. The only difference, there is no concept of tracing for Runtime, it will only have an API for starting sampling profiler.
When `Tracing.end` CDP method is received, it is propagated in the same order.
There is also `collect*()` methods for collecting profiles.
This has multiple benefits:
- We can control when `Runtime` or `Instance` are recreated and can ask them to start recording trace profiles right away. This may be required when we would add support for Reload and Profile from Performance panel.
- We might leverage this setup in the future, once we add instrumentation for Network panel. `InstanceAgent` will get notified when tracing started and will correspondingly notify other part of the infrastructure that will be responsible for recording network calls.
- We remain being fully agnostic to the actual `Runtime`, see corresponding `RuntimeTargetDelegate` for `V8`. We don't have the capacity for implementing and maintaining sampling profiler capabilities for it, but this approach unblocks it from technical perspective, if someone would want to invest into this.
`InstanceProfile` is a superset of `RuntimeSamplingProfile`. In the future, `InstanceProfile` may also include things like `NetworkProfile`, or similar stuff.
The definition for `RuntimeSamplingProfile` will be added in D68414421 and relies on the availability of new API for sampling profiler in Hermes.
Reviewed By: huntie
Differential Revision: D68327630
fbshipit-source-id: f8446057f88d87b4394fb692c28b89f1b8ce4eea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49714
Changelog: [internal]
This package was only needed for testing but it's actually not used.
Reviewed By: hoxyq
Differential Revision: D70318040
fbshipit-source-id: b57ec74932029368117520646972bfee83706017
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49693
Allow setting the ReactNativeInternalFeatureFlags from a Fantom test using the `fantom_internal_flags` pragma.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D70242739
fbshipit-source-id: 17a69edbd58b93f8b8060192b9881e62febf9635
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49697
Changelog: [internal]
These classes cannot be instantiated directly, but having access to them allows users to do `instanceof` checks, e.g.:
```
if (ref.current instanceof Element) {
ref.current.getBoundingClientRect();
}
```
Reviewed By: yungsters
Differential Revision: D70244966
fbshipit-source-id: 3c1e3698b8851ef9ce3c2865e7435b000984c8f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49696
Changelog: [internal]
This is just a change for convenience, as Flow is currently typing `textContent` in `Node` as `string` instead of as `string | null` as we were doing.
Our behavior was more correct, as `Document` extends `Node` and it returns `null` in that case, but to ensure a smooth migration we'll adopt the existing definition.
Reviewed By: huntie
Differential Revision: D70244963
fbshipit-source-id: ad8325d6e00c221e858e4e2d45085666ff0a0ce7
Summary:
Solves the iOS part of https://github.com/facebook/react-native/issues/47186.
`onContentSizeChanged` event is sent inside the `updateLayoutMetrics` method every time it's invoked. A change in layout metrics doesn't mean that the content size also changes, like changing the position of the input.
This PR adds a condition that the content size must have changed before sending the event.
|Before this change|After this change|
|-|-|
|<video src="https://github.com/user-attachments/assets/743e1502-e13e-474e-b4a6-ef6873bf9619">|<video src="https://github.com/user-attachments/assets/fe3d3ef5-3951-4ba2-b9a1-c41439ab455c">|
In the reproducer from the issue, `SafeAreaView` is used, which at first renders its content without any insets until its state is updated with the correct insets. Both of these layouts change the layout metrics of the text input, resulting in two events before this change and a single one after.
## Changelog:
[IOS] [FIXED] - Fixed TextInput's `onContentSizeChange` event being dispatched multiple times with the same size
Pull Request resolved: https://github.com/facebook/react-native/pull/49695
Test Plan: Tested on the reproducer from the issue
Reviewed By: NickGerleman
Differential Revision: D70247460
Pulled By: j-piasecki
fbshipit-source-id: 8a1e0d0f55b6b3f8a6d0bb176ed50e47e3b51035
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49699
Changelog: [internal]
Just a minor optimization in `ReactNativeElement`, to stop creating an unnecessary object in the prototype chain for the `super()` removal optimization.
Reviewed By: huntie
Differential Revision: D70250804
fbshipit-source-id: 1f8104f8e17f12264326cd715e07877a371f9dc5
Summary:
This PR implements a C API to switch JS Engines that can be used from Swift.
Here is an example:
```swift
import React
import React_RCTAppDelegate
import ReactAppDependencyProvider
import UIKit
import RCTRuntime
class ReactNativeDelegate: RCTDefaultReactNativeFactoryDelegate {
override func sourceURL(for bridge: RCTBridge) -> URL? {
self.bundleURL()
}
override func bundleURL() -> URL? {
#if DEBUG
RCTBundleURLProvider.sharedSettings().jsBundleURL(forBundleRoot: "index")
#else
Bundle.main.url(forResource: "main", withExtension: "jsbundle")
#endif
}
override func createJSRuntimeFactory() -> JSRuntimeFactory {
jsrt_create_jsc_factory() // Easily switch engines here
}
}
```
## Changelog:
[IOS] [ADDED] - js runtime C API for Swift
Pull Request resolved: https://github.com/facebook/react-native/pull/49489
Test Plan: CI Green
Reviewed By: huntie
Differential Revision: D69976988
Pulled By: cipolleschi
fbshipit-source-id: 9333ec62ca99a28c3121f558bbff1ce0457779e3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49702
In the next version of Flow, we will stop bundling many of the builtin libdefs, and they have been moved to flow-typed. This diff checks in them to prepare for the deployment of the next version of Flow.
Changelog: [Internal]
Reviewed By: alexmckenley
Differential Revision: D70256694
fbshipit-source-id: 44e0772cc982add44723c252ea547a9cea0641e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49666
This change moves the index.js file to the `releases` folder, giving it a meaningful name.
It also rename the prebuild folder to ios-prebuild to be more descriptive.
It finally removes the old scripts that this refactoring supersedes.
bypass-github-export-checks
## Changelog:
[INTERNAL] - Move the infdex.js to the prepare-ios-prebuilds script.
Reviewed By: cortinico
Differential Revision: D70176043
fbshipit-source-id: e0c3f3bd53adf97fa388c37a746d274fd678f690
Summary:
This change refactors the script to prebuild ios dependencies by:
- remove the manually maintained Package.swift
- add script to generate it starting from the configurations that we have
bypass-github-export-checks
## Changelog:
[INTERNAL] - Factor out script to generate Package.swift file
Reviewed By: cortinico
Differential Revision: D70175760
Pulled By: cipolleschi
fbshipit-source-id: a1b0fc6dcdc1860b04ab260697f259c297338f41
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49657
For some use-cases we still want to log using the internal fbsystrace API which allows backdating of events.
This feels a bit weird putting it in `ReactPerfettoLogger`, but maybe we should rename that to something like `TraceLogger` (like we have `TraceSection`).
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D70109680
fbshipit-source-id: 7757b81ec5032e3800446a88198c7da135afdd0e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49691
Changelog: [internal]
This adds a new getter for `document` in the `Root` class in Fantom tests to easily access the document instance for the root.
This isn't very useful at the moment, but will be very useful when we introduce `document.getElementById`, so we can access arbitrary nodes very easily.
Reviewed By: javache
Differential Revision: D69307130
fbshipit-source-id: 2650bc03e143ee9f0b29d0f284a2f9079ab9f765
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49690
Changelog: [internal]
We're shipping this soon and most tests already using DOM APIs to make assertions, so it's easier if we just "ship" in tests.
Reviewed By: javache, sammy-SC
Differential Revision: D69307129
fbshipit-source-id: 75d0be013703cff7bc2bad5cd16c26bc6471e547
Summary:
Migrate com.facebook.react.modules.network.ProgressRequestBody to Kotlin.
Note: To keep the logic the same as in Java, I had to make the params of RequestBodyUtil.createProgressRequest non-nullable again which were made nullable by mistake in https://github.com/facebook/react-native/pull/49584.
## Changelog:
[INTERNAL]- Migrate com.facebook.react.modules.network.ProgressRequestBody to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/49682
Test Plan:
```bash
yarn test-android
yarn android
```
Reviewed By: rshest
Differential Revision: D70239855
Pulled By: cortinico
fbshipit-source-id: 03c5e0bd5c66a4d5df5e4304d4479ec576d350fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49687
Changelog: [internal]
Just a minor type rename to better reflect what this type will become soon.
Reviewed By: cortinico
Differential Revision: D70185597
fbshipit-source-id: d5a67eda44dc88dd32a5290f1d0b292ed7014006
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49633
Changelog: [internal]
This replaces the definition of `HostInstance` to use an interface instead of an object, to better represent the underlying type (an instance of `ReactFabricHostComponent`) and simplify the migration to the new DOM API.
Reviewed By: huntie
Differential Revision: D70023947
fbshipit-source-id: bf312abf02fec48b2b5afb41053593ce542f7324
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49658
This bumps the version of Node that we use to build React Native from 18 to 20.
We'll still be supporting building with 20, but we'll moving our toolchain to Node 20 becuase 18 is at EOL soon.
Changelog:
[General] [Changed] - Bump Node 18 -> 20 to build React Native in OSS
Reviewed By: javache, cipolleschi
Differential Revision: D70168003
fbshipit-source-id: b64ee583b2d2e72d25393119ae9e9029a74d5b13
Summary:
Reland of https://github.com/facebook/react-native/issues/49413 which was reverted due to an internal crash. I've attempted to do a solution to keep backwards compatibility but doesn't seem to work – keeping the original solution for now, perhaps something else can be cleaned up to avoid the breakage.
## Changelog:
[INTERNAL] - Migrate com.facebook.react.uimanager.ReactClippingViewGroup to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/49607
Test Plan:
```bash
yarn test-android
yarn android
```
Verified that the update changes do not cause a crash.
Test flow:
- login to BizApp using Instagram account
- on home screen scroll down to Insights section
- it should show without crashing
Reviewed By: arushikesarwani94
Differential Revision: D70200000
Pulled By: alanleedev
fbshipit-source-id: 89bc948c1b91d9419d4b6e1885d949c4a3c20986
Summary:
## Summary
> [!NOTE]
> This only modifies types, so shouldn't have an impact at runtime.
Some time ago we moved some type definitions from React to React Native
in #26437.
This continues making progress on that so values that are created by
React Native and passed to the React renderer (in this case public
instances) are actually defined in React Native and not in React.
This will allow us to modify the definition of some of these types
without having to make changes in the React repository (in the short
term, we want to refactor PublicInstance from an object to an interface,
and then modify that interface to add all the new DOM methods).
## How did you test this change?
Manually synced `ReactNativeTypes` on top of
https://github.com/facebook/react-native/pull/49602 and verified Flow
passes.
DiffTrain build for [9dd378ff1222335ff133bab2d61001fcc84a1c56](https://github.com/facebook/react/commit/9dd378ff1222335ff133bab2d61001fcc84a1c56)
Reviewed By: poteto
Differential Revision: D70091830
fbshipit-source-id: 2cc49d8ed89e8ee2531dbc4094ef9720fc3040ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49678
In this diff I'm undeprecating SynchronousEventReceiver and marking it as UnstableReactNativeAPI, to properly describe the status of this API.
changelog: [internal] internal
Reviewed By: mlord93
Differential Revision: D70193235
fbshipit-source-id: c4818c89eecef135e9e1f82d35e7f1e2d46b1637
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49683
Use of these types will trigger `[internal-type]` error in the next version of Flow. This diff cleans them up ahead of the time.
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D70202028
fbshipit-source-id: 97b7217040b63514f20888fb20c86596235a82a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49632
changelog: [internal]
Add gating to experiment with removal of `_turboModuleManagerDelegateMutex`.
# Why remove _turboModuleManagerDelegateMutex?
- It is not consistently used in the class. Here is a case where access to _delegate is not protected by the mutex: https://fburl.com/code/9tay04fn
- From inspecting individual implementations of RCTTurboModuleManagerDelegates, it is not needed to synchronise access.
- It may lead to deadlocks under following conditions:
- **A)** JavaScript thread gets hold of the `_turboModuleManagerDelegateMutex` and then tries to dispatch a block on the main thread synchronously (calling `RCTUnsafeExecuteOnMainQueueSync`). For example, when a new native module is created lazily because JavaScript used it and the native module requires main thread setup.-
- **B)** The main thread tries to get hold of `_turboModuleManagerDelegateMutex` when it is creating a native module ([[RCTModuleRegistry moduleForName:lazilyLoadIfNecessary:]](https://fburl.com/code/lioi5zei)) from Obj-C.
Reviewed By: javache, cipolleschi
Differential Revision: D70087779
fbshipit-source-id: 1780b2f48537dd578260a96f8f498dbe11529689
Summary:
The class is still in Java and also lacks of some tests so adding them to make it safer to migrate or for future refactors.
## Changelog:
[INTERNAL] - Add `ProgressResponseBodyTest` test cases
Pull Request resolved: https://github.com/facebook/react-native/pull/48675
Test Plan:
```bash
yarn test-android
```
Reviewed By: alanleedev
Differential Revision: D68205423
Pulled By: rshest
fbshipit-source-id: edb1dcf4da34377b7b1dcfc68a6e08861421964b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49635
Changelog:
[General][Internal] - report proxy idle state in heartbeat events
The proxy is considered Idle if it didn't receive any messages for 10 seconds.
Reviewed By: robhogan
Differential Revision: D70078637
fbshipit-source-id: 5b8d9a3a6e3e2568e40b3ada0a41e76b277fe66d
Summary:
`NSUnderlinePatternDash`/`NSUnderlinePatternDot` are [deprecated](https://developer.apple.com/documentation/uikit/nsunderlinepatterndash). Use their drop-in replacements (`NSUnderlineStylePatternDash` and `NSUnderlineStylePatternDot`) instead.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [DEPRECATED] - Update deprecated enums in RCTTextPrimitivesConversions.h
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/49648
Test Plan: Local build
Reviewed By: cortinico
Differential Revision: D70153675
Pulled By: cipolleschi
fbshipit-source-id: e64c9df1a5282a3f33f742a455c64c002f0c8044
Summary:
After this change: https://github.com/facebook/react-native/pull/49078 UIWindowSceneDelegate is no longer needed.
This wasn't removed in the original PR.
## Changelog:
[iOS] [Removed] - Remove no longer needed UISceneDelegate
Pull Request resolved: https://github.com/facebook/react-native/pull/49628
Test Plan: CI GREEN
Reviewed By: cortinico
Differential Revision: D70102384
Pulled By: cipolleschi
fbshipit-source-id: e33185a4becd949a9f0ec1eabeeb4fe85ef3ee79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49516
Merge global.d.ts and globals.d.ts into one file and align some definitions with implementations.
Changelog:
[General][Changed] - Improve TypeScript types for `global` objects
Reviewed By: huntie
Differential Revision: D69772463
fbshipit-source-id: 4771e27a97e1e9cbc33d8f75ba11cffd4d200124
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49637
The dtslint requires that the minimum typescript version of 4.9 is used.
Changelog:
[General][Changed] - Increase minimum typescript version in index.d.ts
Reviewed By: huntie
Differential Revision: D69749044
fbshipit-source-id: be255d108c2e9e9452808ba3dea981a7fac0bc21
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49655
This tripped me up since this if hits for TextViews in general, not just EditText
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D70139349
fbshipit-source-id: 1993dda4c6472265c5e61fa4cad4f2beaf4a9930
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49654
This is a lint error, so figured I would fix it
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D70138099
fbshipit-source-id: 489bedc28ac15bed8f98cc3eceb9e393cd4598e7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49587
This is a reland diff for D69805065.
The problems with the original diff were:
- wrong header search path in the `React-NativeModuleApple.podspec`
- adding an implementation `RuntimeExecutor.cpp` file to implement a function that is used by an inline function in the `RuntimeExecutor.h`.
I believe that the last point specifically was creating issues to the linker which was not able to resolve the symbols properly in transitive dependencies.
The fix was to move the implementation of `getMainThreadMutex` to be `inline`.
## Changelog:
[Internal]
Reviewed By: cipolleschi
Differential Revision: D69922771
fbshipit-source-id: 285ce1f232e8c94b99d80aafe1ffbc473921d52f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49639
Changelog: [internal]
This refactors some code in the performance API and Perfetto to avoid doing unnecessary work when not tracing (e.g.: string manipulation for tracks).
It also reduces the cost of logging marks/measures to tracing backends if not actively tracing (e.g.: moving the check to outside the lock).
Reviewed By: bgirard
Differential Revision: D69246772
fbshipit-source-id: 141a13f609f12be7ab8ca00f7aa1892b34770bbb
Summary:
Fixes assert crash in https://github.com/facebook/react-native/issues/46568#issuecomment-2653747732.
We can temporarily downgrade _LIBCPP_HARDENING_MODE to _LIBCPP_HARDENING_MODE_EXTENSIVE, it disables strict weak ordering check in debug mode. Actually, when we sort animation mutations, we don't need it to satisfy strict weak ordering.
https://libcxx.llvm.org/Hardening.html#id3
Another solution is we make sort satisfy it, but we don't have any key to compare when two mutation is the same mutation type but not the same parentTag. Maybe we can use pointer of muation to compare?
## Changelog:
[IOS] [FIXED] - Fabric: disable React-Fabric stable_sort strict weak sort check in debug mode
Pull Request resolved: https://github.com/facebook/react-native/pull/49422
Test Plan: Fixes https://github.com/facebook/react-native/issues/46568#issuecomment-2653747732.
Reviewed By: sammy-SC
Differential Revision: D69984937
Pulled By: cipolleschi
fbshipit-source-id: 2a3d17970def513c4ba915068f25338169db82d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49559
## Motivation
Modernising the RN codebase to allow for modern Flow tooling to process it.
## This diff
Renames `Animated.js` to `AnimatedExports.js`, and introduces an intermediate file that reexports `* as Animated` as a default. This should have equivalent runtime behavior, but allows for a common interface file: `Animated.js.flow` to reinterpret the module as having single exports. TypeScript treats this as a namespace.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D69849314
fbshipit-source-id: cdaa605ba5361d3349c6dd0e84fd0fbfee263941
Summary:
## Summary
The `flow-api-translator` from the `hermes` repo does not support flow
type spreads. It is currently not able to digest the ReactNativeTypes
file as it contains unsupported syntax. The simplest solution is to
change the type of the `TouchedViewDataAtPoint` to equivalent, yet
supported by the Flow tooling. In this case the intersection can be used
as
the `TouchedViewDataAtPoint` and `InspectorData` have no common
property.
## How did you test this change?
Run yarn flow native
DiffTrain build for [e670e72fa076449e40172e20d17cc67c1c15419c](https://github.com/facebook/react/commit/e670e72fa076449e40172e20d17cc67c1c15419c)
Reviewed By: rickhanlonii
Differential Revision: D69661050
fbshipit-source-id: 1732bd9ac9c1af1e4c0b95758e92d9ccf3b807e6
Summary:
fix: https://github.com/facebook/react-native/issues/49368
description is provided inside the ticket.
When we use TextInput on ios and manage selection with the selection prop, TextInput is reset when we change selection.
## Changelog:
[IOS] [FIXED] - Fix selection makes TextInput clear its content when using children
Pull Request resolved: https://github.com/facebook/react-native/pull/49450
Test Plan:
Tested with sample provided in ticket.
I also test it with my app on both android and ios, but I cannot share video
Reviewed By: sammy-SC
Differential Revision: D69984616
Pulled By: cipolleschi
fbshipit-source-id: a17169608f9df0ea1cb579e6038345f8e48bbc27
Summary:
The js prop name is `shouldRasterizeIOS` https://reactnative.dev/docs/view#shouldrasterizeios-ios, so we should change the prop name when parsing the props.
## Changelog:
[IOS] [FIXED] - Fabric: Fixes shouldRasterizeIOS prop of View not work on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/49615
Test Plan:
Enable `shouldRasterizeIOS` should work in Fabric:
```
<View shouldRasterizeIOS={true}>
```
Reviewed By: rshest
Differential Revision: D70085480
Pulled By: javache
fbshipit-source-id: 499524b7812f932b0da4a4f239ff6a79043b2f87
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49629
I don't think `RCTSampleTurboCxxModule_v1` does anything useful anymore since we no longer use the `getTurboModuleWithJsInvoker:` API anywhere.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D70088150
fbshipit-source-id: 6391531c412dec18c63948db883aba07ab21499e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49602
Changelog: [internal]
This just prepares for the removal of some types from `ReactNativeTypes`, and defines some types in `ReactNativePrivateInterface` that `ReactNativeTypes` expects to be defined after https://github.com/facebook/react/pull/32446
Reviewed By: huntie
Differential Revision: D69996009
fbshipit-source-id: 3c156b4dede8e217d6a828ab310533a2f8bfd42c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49601
Changelog: [internal]
This creates a new module in React Native to define some of the types related to `HostInstance` that are currently defined in `ReactNativeTypes` (synced from the React repo).
We want to remove the types from `ReactNativeTypes` so this is a necessary initial step.
Reviewed By: huntie
Differential Revision: D69996010
fbshipit-source-id: 21cfed4c222e22332936e56aca895fe578809792
Summary:
`TextInput` component has been missing support for `numberOfLines` prop on iOS, this PR adds it.
## Changelog:
[IOS] [ADDED] - Add support for `numberOfLines` prop on `TextInput`
Pull Request resolved: https://github.com/facebook/react-native/pull/49549
Test Plan: Tested on RNTester and added a new case utilizing the prop
Reviewed By: cipolleschi
Differential Revision: D69915133
Pulled By: j-piasecki
fbshipit-source-id: b6a86bc64bd3c2129a64e99c9bcec9cf5bfde3bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49618
Changelog:
[General][Internal] - create a heartbeat for device, and not only for debugger.
Introducing a heartbeat for the connection between the proxy and the device similarly to the one between the proxy and the debugger. This will allow us to:
* Most importantly I'd like to track the ping-pong roundtrip to the device as well, to see if we have any anomalies there
* Terminate the connection if it is abandoned for 60seconds- this might have a real effect in some case where the device runs remotely
* Also keep that connection alive if the other side disconnects after a period of inactivity. While a no-op in our case, this is an implementation detail. It is a no-op because the WebSocket on the Device is implemented by us and is not supposed to drop connections like the browser does.
Reviewed By: robhogan
Differential Revision: D69990715
fbshipit-source-id: 6bb3a2ed3eaffff9535aa2d0fc8cff0262af022f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49612
`[UIApplication sharedApplication]` is not allowed in Mac Catalyst. This #ifdef's it out which is a common pattern elsewhere.
Changelog: [Internal]
Reviewed By: shwanton
Differential Revision: D69971189
fbshipit-source-id: 89dbc0a02ed2a06936f910fbfc13e1fb91972540
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49605
changelog: [internal]
Calling `RCTUnsafeExecuteOnMainQueueSync` while holding a lock can lead to a deadlock. In this diff, we remove it from RCTKeyWindowValuesProxy.
Reviewed By: javache
Differential Revision: D69997888
fbshipit-source-id: a09fc641c9fb2aec59aef34e4047e1ef11cdaf02
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49381
A much improved version of my previous attempt in D68306316 (https://github.com/facebook/react-native/pull/48773).
Instead of LinkMovementMethod which makes TextViews scrollable if they overflow, this implementation uses `ExploreByTouchHelper`'s `onVirtualViewKeyboardFocusChanged` and `onPerformActionForVirtualView` to handle focus changes and clicks on virtual views (aka spans in our case). This impl will correctly ellipsize text and allow tab to nav through the links.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D69551206
fbshipit-source-id: 6a88ccd507dc5534c1f494e3303c6bfc2bae5e9f
Summary:
Whenever we remove a link in some text we do not properly update the accessibility delegate to respond to this change. As a result we still think that there are nodes to access around the spans
Changelog: [Android][Fixed] - Fix text link accessibility on state update removal
Reviewed By: NickGerleman, mdvacca
Differential Revision: D69551906
fbshipit-source-id: f43fcf72219e76d2d0bbb29d31ab219d73413671
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49377
ReactAccessibilityDelegate exists to handle much of the accessibility tasks in the various Views in RN. There is quite a bit of text specific logic, mostly related to virtual views and nested links within a TextView.
I decided to subclass this into a TextView-specific version because I need this delegate to reference TextView or ReactClickableSpan, which live under `react/views` while ReactAccessibilityDelegate live under `react/uimanager`. The former depends on the latter, so making the latter depend on the former would for a dependency cycle that would break builds. I thought about making a separate package for this but both `react/views` and `react/uimanager` need to include ReactAccessibilityDelegate so we would still have a cycle.
mAccessibilityLinks is only set on ReactTextViewManager, so this is purely a text thing. Subclassing is not the most ideal as it extends the inheritance chain some more but I do not see a better option.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D69499115
fbshipit-source-id: 1720d20bb56ba1e1b5bd114d32bc70e80e3b4558
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49581
I need to be able to find a View with a specific nativeId as part of my implementation of accessibility ordered children. This already exists in Android in `ReactFindViewUtil.kt`.
Not much to this implementation. Recursive tree searching. I do not think perf is a big deal here but if we want to optimize this we could implement some nativeId registry and try and get the UIView * from that at the expense of storing that map somewhere.
Changelog: [Internal]
Reviewed By: vincentriemer
Differential Revision: D69868430
fbshipit-source-id: b3648a8dca351bed50534cac2144d7e8ea0a207f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49590
This feature flag was used to validate a fix for handling of events during
gesture on pressable. It can now be removed as the flag has been set to true for several
internal app (Twilight among others) for several months.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D69983235
fbshipit-source-id: 89b96b3e4c98ae258982341f56ddc13aa2fe51bd
Summary:
Opening this as a separate PR, since I'm not sure if I'm missing something, or if there's any intention behind this.
`react-native/metro-babel-transformer` is used by `react-native/metro-config` and is referenced in code there and as a dependency there. It's also sometimes mentioned as package for community CLI users to install directly. However, there's seemingly no reason `react-native/metro-babel-transformer` needs to depend on it, or any code that relies on it directly.
## Changelog:
[INTERNAL] [CHANGED] - Remove extraneous `react-native/metro-babel-transformer` dependency from community-cli-plugin
Pull Request resolved: https://github.com/facebook/react-native/pull/49558
Test Plan: - n/a
Reviewed By: robhogan
Differential Revision: D69926109
Pulled By: huntie
fbshipit-source-id: b89b54890248de4954e5c0ce4afe3a5cb5bfa2c1
Summary:
Update androidx app compat to the latest version.
This is needed as part of https://github.com/facebook/react-native/pull/49486 to have access to `fullyDrawnReporter`.
## Changelog:
[ANDROID] [CHANGED] - Update androidx app compat to 1.7.0
Pull Request resolved: https://github.com/facebook/react-native/pull/49594
Test Plan: Tested in RN tester that it builds fine and works properly.
Reviewed By: Abbondanzo
Differential Revision: D69988202
Pulled By: cortinico
fbshipit-source-id: 0329aa84a76327db535ddba8acf059ebbf1dbdfc
Summary:
This package does not seem to be referenced by anything but the tests in `packages/dev-middleware`, so seems like a pretty straightforward change to drop it from `dependencies`.
It only seems to be referenced in `packages/dev-middleware/src/__tests__/ServerUtils.js`
## Changelog:
[INTERNAL] [CHANGED] - Remove selfsigned from dev-middleware dependencies
Pull Request resolved: https://github.com/facebook/react-native/pull/49556
Test Plan: - n/a
Reviewed By: cipolleschi
Differential Revision: D69925928
Pulled By: huntie
fbshipit-source-id: bba41f81dba054505ebf196ad37c7a718a6b16da
Summary:
While `readline` is referenced in `packages/community-cli-plugin/src/commands/start/attachKeyHandlers.js`, this references the `node:readline` module by default. The extra package seems to have been installed and included accidentally, as the `attachKeyHandlers` file uses an export from `node:readline` that's never been present in `npm:readline`.
Since the name matches but Node.js will always prefer built-in/code modules, this dependency is dangling and can never be reached, since it's name is shadowed (as also stated in their readme). This can be reproduced by comparing `require('readline')` and `require('../../node_modules/readline')` in `packages/community-cli-plugin`. The flow types also confirm this.
This overall seems highly safe to drop.
## Changelog:
[INTERNAL] [CHANGED] - Remove shadowed and unused readline npm package from community-cli-plugin
Pull Request resolved: https://github.com/facebook/react-native/pull/49557
Test Plan:
Prior to changes applied:
```sh
$ node -e 'console.log(require("readline") === require("node:readline"))'
true
```
Reviewed By: cipolleschi
Differential Revision: D69925999
Pulled By: huntie
fbshipit-source-id: 802fdaa396630b44d5aacefeb9c2473fb53d167e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49589
We should not be attempting to compile anything related to the annotation
processor in either Kotlin or Java.
This excludes those folders from the Kotlin compilation task as the
CI is currently red because of it.
Changelog:
[Internal] [Changed] -
Reviewed By: huntie
Differential Revision: D69981620
fbshipit-source-id: 7e2d534023ab1c00e5aadf8546440a4cc4c01ec0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49572
Changelog: [internal]
This adds a test to verify the behavior of 2 feature flags: synchronous state updates and UI consistency.
Reviewed By: javache
Differential Revision: D69932313
fbshipit-source-id: 341cfff3fa533503a293f6ccd0282442ba63d430
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49586
Reverting https://github.com/facebook/react-native/pull/49413 as it was causing a crash with assertion failure in ReactViewGroup.addViewWithSubviewClippingEnabled()
Changelog:
[INTERNAL] revert Kotlin conversion due to crash
Reviewed By: sbuggay
Differential Revision: D69953848
fbshipit-source-id: b438fb928a4849f3dbad6a9d59d0f48449035fd6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49570
This diff creates a initial version of the annotation processor to output the list of types that are annotated with LegacyArchitecture
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D69929875
fbshipit-source-id: 90a8d299f4667ab8d103c061d287991dbdb291df
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49569
In this diff I'm annotating a subset of bridge classes with LegacyArchitecture
The goal is to test the annotation processor in next diffs
changelog: [internal] internal
Reviewed By: cortinico, Abbondanzo
Differential Revision: D69929878
fbshipit-source-id: 8be4d010f6519617d334da361983dce0fa66e3b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49568
The goal of this annotation processor is to generate a file with all the types that belong to Legacy Architecture of React Native
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D69929876
fbshipit-source-id: c21bf1a868258b20be91721006d7fc8fa85adcd1
Summary:
This upstreams a change from [RNTV](https://github.com/react-native-tvos/react-native-tvos/) to allow the glog prepare script to work on both iOS and tvOS.
## Changelog:
[Internal][Changed] make iOS glog script compatible with tvOS
Pull Request resolved: https://github.com/facebook/react-native/pull/49539
Test Plan:
- This change works well on the TV repo
- CI should pass, and iOS compilation and operation should be unchanged
Reviewed By: cortinico
Differential Revision: D69928586
Pulled By: cipolleschi
fbshipit-source-id: b5fec438151e659e98834a83effbc7e166df6aa5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49552
Changelog:
[General][Internal] - expand debugger events to have DebuggerSessionIDs
Also moved the handling of these to a shared function
Reviewed By: huntie
Differential Revision: D69917817
fbshipit-source-id: 2374ac5b5dc0040b0e15028ab89fbe78026bc296
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49515
changelog: [internal]
_currentSafeAreaInsets should be initialised as part of `startObservingSafeArea` to make sure it is set before accessed.
Even though, right now _currentSafeAreaInsets is always set before it is read because notification RCTUserInterfaceStyleDidChangeNotification fires eagerly, it might change in the future and introduce a bug.
Reviewed By: lenaic
Differential Revision: D69846681
fbshipit-source-id: f8be8a53e82020112abd170b9f20429bf7ba7011
Summary:
When building `react-native-windows` our code analysis tools complained about an implicit `double` to `PointerIdentifier` in NativeDOM.cpp.
This PR adds an explicit cast.
Temporary downstream patch: https://github.com/microsoft/react-native-windows/commit/5957d0af6944d64513cead28186dfbcc74bbfea0
## Changelog:
[GENERAL] [FIXED] - Add explicit casts for pointerIds for PointerEvents in NativeDOM
Pull Request resolved: https://github.com/facebook/react-native/pull/48578
Test Plan: React Native Windows builds with this change and no more warnings.
Reviewed By: rubennorte
Differential Revision: D69920656
Pulled By: cipolleschi
fbshipit-source-id: 1d81f1fbfd91fadfb676d3e65c3c9cb729c1d3dd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49553
The new React-renderercss pod is an header only pod. These are not allowed by Cocoapods, because it will not materialize the framework when building with then turned on.
the solution is to just add an empty source file to frorce cocoapods to materialize the .framework file and solve the dependency graph properly.
## Changelog:
[Internal] - Add dummy file to React-renderercss
Reviewed By: huntie
Differential Revision: D69920318
fbshipit-source-id: e5cc092a480f7c86eeb295ed966f85b6f55fdc54
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49554
For some reason, this diff completely breaks the linker on iOS.
I tried to look for a fix forward, but unsuccessfully.
I'm reverting this diff to get CI green again, but this requires more investigation.
## Changelog:
[Internal] - Revert D69805065
Reviewed By: sammy-SC, huntie
Differential Revision: D69920338
fbshipit-source-id: 8e1d34b5314d8ead51c127208ae2d2250f7d3724
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49522
While testing the script, sometime I obtained undesired results because I was passing the wrong values for the arguments.
This change add a simple validation function to inform the user when the arguments that are passed are not valid.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D69851416
fbshipit-source-id: c378a3ca5db942cca5178274204a0d01d1eefdf7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49523
There was a typo when checking the configuration. The default parameter is `all`, not `All`.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D69851429
fbshipit-source-id: 7f16f5f89c90824ceb57f9980bc38a31be33ccfe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49524
If there is already an XCFramework in the current location. xcodebuild fails to create and override the xcframework.
This change allows us to override an old xcframework and to iterate more quickly.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D69851428
fbshipit-source-id: 723b3035cec008e2bd177da4f960f2bb085ff493
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49514
This attemps to enable Config Caching on CI. I'm curious to see how much time this is going to save.
There might be some problems with nigthlies so I want to make sure this is running for some days before the branch cut.
Changelog:
[Internal] [Changed] -
Reviewed By: NickGerleman
Differential Revision: D69846848
fbshipit-source-id: 0d5c292e65a6107df62f6494a1aae9abd0e8b6cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49535
changelog: [internal]
Add a unit test to cover scenario where ScrollView's parent has a transform
Reviewed By: NickGerleman
Differential Revision: D69860855
fbshipit-source-id: 1b64665c5b15ad2e5e068d4c6d56f9694ac7cf03
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49546
Right now we rely on the ViewConfig processor to fire an invariant if the values are incorrect. We really don't want to redbox in the future on invalid properties, and this won't be around for the native CSS parsing path.
This code has some problems, like... radian parsing allowing potential out-of-bounds reads, firing a native assert for valid 9 digit matrices, or the layers in conjunction treating `0.5r.degoggos00` as a valid way to say 0.5 radians. Wheeee!
This change mostly just ports over the checks from `processTransform` to validate parameters before we use them, treating the whole transform list as invalid if any part of it is broken. I moved radian and percentage parsing the the CSS data type parsers as well.
I avoided changing props structures again here.
Changelog:
[General][Changed] - Add validation to Fabric parsing for transform options
Reviewed By: javache
Differential Revision: D69823064
fbshipit-source-id: 87c6da448a4b55e0507382b98aabd62ce3e4587f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49545
During tokenization we use 32 bit integers to store the digits before and after a decimal place.
Code interpolating strings may produce float strings with the part after digits being greater than max int, in which case we encounter integer overflow caught by UBSAN.
I was curious how libc functions for decoding floats handled this, and musl libc goes really out there, storing each intermediate digit in an array of 128 or more digits, and later using `long double`, in a shockingly complicated function. https://github.com/kraj/musl/blob/1880359b54ff7dd9f5016002bfdae4b136007dde/src/internal/floatscan.c#L63
We... probably don't need to go that far, but storing these intermediate digits as doubles should be precise enough and allow large enough values in the vast majority of cases.
Changelog: [Internal]
Reviewed By: sammy-SC, jorge-cab
Differential Revision: D69881560
fbshipit-source-id: b2158ce2c5d85157426cea9850c7f62c2eee5611
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49509
Currently if we hit a deadlock in sync rendering due to a TurboModule initialization that requires main queue setup we don't get any information about which TurboModule caused the issue.
To help us know which TurboModules we need to fix, this instead will crash with the name of the TurboModule.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D69805065
fbshipit-source-id: f75df44f9a603a5f53a008382d32b2b5285c1162
Summary:
Okay the title is a bit clickbaity, but this is actually true. (on Android)
We (Janic, Szymon, Ruby and Me) discovered something interesting. React Native uses `mmap` for mapping the JS bundle to RAM, to avoid having to load the entire thing instantly at app startup.
Ruby doubted that this was true - so we investigated.
Apparently on Android, resources are **compressed**. And if the JS bundle is stored compressed, it has to be uncompressed before it can be loaded into RAM, hence not allowing it to be mmapp'ed! (see [`_CompressedAsset::getBuffer`](https://cs.android.com/android/platform/superproject/+/master:frameworks/base/libs/androidfw/Asset.cpp;l=903?q=Asset.cpp))
So with this PR, we now add `.bundle` files to `noCompress` in the react-native gradle plugin, which disables compression for the JS bundle.
We discovered while improving the performance of one of our clients: **Discord**.
In our tests, **this improved the TTI of the Discord app by 400ms!! (or 12%)** 🤯🚀
NOTE: Yes, the .apk will now be bigger. But; Google Play compresses it anyways, so the **download size** of your .apk will likely not increase by much. It will be bigger on disk though.
## Changelog:
[ANDROID] [CHANGED] Add option to disable bundle compression to improve startup time
<!-- 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/49449
Test Plan:
### 1. Verify compression is disabled
Build two apps, one with this patch and one without. When I did this using the RN community template, the one without this patch was 47,6 MB, and the one with this patch was 48 MB in size. So the .apk got bigger, which is what we expected
### 2. Verify app startup is faster
Use tools like react-native-performance or custom markers to measure TTI. In our tests, we shaved off 400ms from the startup time, which was about 12% of Discord's total TTI. (on a low-end Android device)
In Expensify, we improved the TTI by 14-20% with this change (source: https://github.com/Expensify/App/pull/56930)
Reviewed By: javache, cipolleschi
Differential Revision: D69742221
Pulled By: cortinico
fbshipit-source-id: bd59d77662bd30a3acdbb2e9f8d8f23db922c3f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49534
Moving the U+200E character ensures that it gets the same font style as other fragments in the LogBox inspector. This solves an issue where the line height differential is causing issues on some out-of-tree platforms (e.g., Windows).
## Changelog
[Internal]
Reviewed By: shwanton
Differential Revision: D69857916
fbshipit-source-id: 5bc70dc0282f3ef9e9b2767ab8094e9923638e99
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49532
I've done a pass with Android Studio and removed automatically all the `public` modifier
that are not really needed.
Changelog:
[Internal] [Changed] -
Reviewed By: mdvacca
Differential Revision: D69857731
fbshipit-source-id: 5098a3454a66e5f1eb58ccf07006558cba360066
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49533
Android Studio is telling us that those modifiers are not sorted according to the 'canonical order'.
This is quite annoying while editing so I'm sorthing them all using the IDE inspection.
We should add a rule inside ktfmt for this, but that's another work.
Changelog:
[Internal] [Changed] -
Reviewed By: mdvacca
Differential Revision: D69857730
fbshipit-source-id: 3aae3d5b114cf4c629c8320a697d17fff686730b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49542
When fusebox loads, we display this static message on apple platforms:
```
Debugger integration: iOS Bridgeless (RCTHost)
```
We are running RN MacOS using the xplat `RCTHost` and want to show the correct platform
[Changelog] [Internal] - Use current apple platform name instead of hardcoding 'iOS'
Reviewed By: robhogan
Differential Revision: D69867335
fbshipit-source-id: 5973882c710447fdb7ef18e82ff304e4cd16a85c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49541
changelog: [internal]
`RCTSurfacePresenter` may be initialised from a background thread. This breaks the requirement of `RCTInitializeUIKitProxies`, which must be always called on the main thread.
Differential Revision: D69874923
fbshipit-source-id: 098f543bd3a849ee9ee1b63b567290f67c0109cd
Summary:
This fixes an issue in Fabric where changing the layout direction and then reloading the JS bundle did not honor the layout direction until the app was restarted on iOS. This now calls `_updateLayoutContext` whenever RCTSurfaceView is recreated which happens on bundle reload. This is not an issue on the old architecture because the layout direction is determined within the [SurfaceViews](https://github.com/facebook/react-native/blob/acdddef48eb60b002c954d7d2447cb9c2883c8b3/packages/react-native/React/Views/RCTRootShadowView.m#L18) which were recreated on bundle reload.
## Related Issues:
- https://github.com/react-native-community/discussions-and-proposals/issues/847
- https://github.com/facebook/react-native/issues/49451
- https://github.com/facebook/react-native/issues/48311
- https://github.com/facebook/react-native/issues/45661
## How can we take this further?
If we want to make it so that it doesn't require an entire bundle reload for RTL to take effect I believe these are the steps that would need to be taken:
- Make it so [RCTI18nManager](https://github.com/facebook/react-native/blob/acdddef48eb60b002c954d7d2447cb9c2883c8b3/packages/react-native/React/CoreModules/RCTI18nManager.mm#L52) exports isRTL as a method instead of consts
- Send Notification Center notif when RTL is forced on or off
- Listen for that notification RCTSurfaceView and call _updateLayoutContext similar to UIContentSizeCategoryDidChangeNotification.
## Changelog:
[iOS] [FIXED] - Layout direction changes are now honored on bundle reload.
<!-- 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/49455
Test Plan:
On the new architecture change force the layout direction and reload the bundle:
```
import React, { useCallback } from "react";
import { Button, I18nManager, StyleSheet, Text, View } from "react-native";
import RNRestart from "react-native-restart";
export default function Explore() {
const onApplyRTL = useCallback(() => {
if (!I18nManager.isRTL) {
I18nManager.forceRTL(true);
RNRestart.restart();
}
}, []);
const onApplyLTR = useCallback(() => {
if (I18nManager.isRTL) {
I18nManager.forceRTL(false);
RNRestart.restart();
}
}, []);
return (
<View style={styles.area}>
<Text>Test Block</Text>
<View style={styles.testBlock}>
<Text>Leading</Text>
<Text>Trailing</Text>
</View>
<Button title={"Apply RTL"} onPress={onApplyRTL} />
<Button title={"Apply LTR"} onPress={onApplyLTR} />
</View>
);
}
const styles = StyleSheet.create({
area: {
marginVertical: 50,
paddingHorizontal: 24,
},
testBlock: {
paddingVertical: 10,
flexDirection: "row",
justifyContent: "space-between",
},
});
```
https://github.com/user-attachments/assets/0eab0d79-de3f-4eeb-abd0-439ba4fe25c0
Reviewed By: cortinico, cipolleschi
Differential Revision: D69797645
Pulled By: NickGerleman
fbshipit-source-id: 97499621f3dd735d466f5119e0f2a0eccf1c3c05
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49540
changelog: [internal]
it is dangerous to call RCTUnsafeExecuteOnMainQueueSync while holding a lock. We can avoid that by keeping only the checks into shared state under a lock and rest is without lock.
This also aligns implementation with other proxy objects.
Reviewed By: javache
Differential Revision: D69856171
fbshipit-source-id: 5f7fd1ebeb642796169d77a437fbc215c3c59795
Summary:
This diff reverts D69836482
D69836482: [react-native][PR] Make `RCTLog` & `ExceptionDataHelper` internal by cortinico causes the following build failure:
Tests affected:
- [automation_twilight_x86_debug](https://www.internalfb.com/intern/test/562950071241129/)
Here's the Multisect link:
https://www.internalfb.com/multisect/21397772
Here are the tasks that are relevant to this breakage:
T215694436: Some CI signals failing for oculus_twilight
The backout may land if someone accepts it.
If this diff has been generated in error, you can Commandeer and Abandon it.
bypass-github-export-checks
Reviewed By: cortinico
Differential Revision: D69860031
fbshipit-source-id: dedaba77f77467eebad279076add13bfcde45ef0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49478
changelog: [internal]
Move all main thread resources that RCTDeviceInfo needs to RCTKeyWindowValuesProxy class. That way, RCTDeviceInfo does not needs to use RCTUnsafeExecuteOnMainQueueSync and doesn't require main thread setup.
Reviewed By: javache
Differential Revision: D69747829
fbshipit-source-id: e8280d2f50258ee59043b5c3865b8a95496be8b6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49518
`react-native/community-cli-plugin` depends on `createDevServerMiddleware` from `react-native-community/cli-server-api`.
`react-native/community-cli-plugin` currently [declares an optional peer dependency](https://github.com/facebook/react-native/blob/bae895500052bda2f55e1832b0c8a63a1b449de3/packages/community-cli-plugin/package.json#L39-L45) on `react-native-community/cli-server-api`, however because the latter isn't a dependency of `react-native` or the community template, the peer dependency is not available to package managers that enforce isolated node_modules - see https://github.com/facebook/react-native/issues/47309.
Rather than add an unnecessary dependency to the template (like [this](https://github.com/react-native-community/template/pull/105)), my proposal is to switch to a peer dependency on only `react-native-community/cli`, because that *is* a dependency of the community template and therefore will be resolvable.
Because `react-native-community/cli` doesn't re-export `createDevServerMiddleware` from its dependency on `cli-server-api`, we need to resolve the latter through the former. This can be cleaned up once a re-export lands - https://github.com/react-native-community/cli/pull/2605.
Changelog:
[GENERAL][FIXED] Fix registering of `start` and `bundle` commands with community CLI and isolated node_modules.
Reviewed By: huntie
Differential Revision: D69848688
fbshipit-source-id: 009b8ffd43b2ab2d84fcc71e9e48382eb8950bb1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49526
Changelog: [Internal]
Introduce a binary tester for Fantom that will be used in runner when ready so OSS can run integration tests.
Here:
- Add BUCK target
- Add CMake target
Reviewed By: cortinico
Differential Revision: D69800975
fbshipit-source-id: 57e135e2a1cbfb88e0141ddc7859b9a29365ee1f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49499
Changelog:
[General][Internal] - warn when user tries to open DevTools, when not in debug mode
Reviewed By: huntie
Differential Revision: D69784836
fbshipit-source-id: aa60762f08f5dea1f91f4fd1ffc86eeb7f94e2fc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49520
changelog: [internal]
Adds a new callback to EventBeat that is triggered in EventBeat::induce (that is when the UI thread is about to go IDLE). This will make state updates applied synchronously before the OS has a chance to paint but they will be batched. If two state updates happen in single UI tick, the will be executed at the end of UI's run loop.
The state updates are still not batched into a single commit. If two state updates happen on the same component, they are coalesced. If two state updates happen on two different components, they will generate two transactions. This is a follow up optimisation.
This feature is hidden behind `ReactNativeFeatureFlags::enableSynchronousStateUpdates` which is a preexisting feature flag. The feature flag was not rolled out yet and is not being used in any QEs at the moment.
Reviewed By: rubennorte
Differential Revision: D69848997
fbshipit-source-id: 870fd21f1d9d73d84861ddeac95b932a7fe1f5fe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49498
This change handles the destinations and the configurations parameter when passed to the script.
## Changelog:
[Internal] - Handle `configuration` and `destination` parameters
Reviewed By: cortinico
Differential Revision: D69787469
fbshipit-source-id: 5c4ae766dad84640fbf5340efc296355c4944e1c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49492
Was looking at more places we could be using `HybridClassBase`, and figured out how to simplify ReadableMapBuffer constructors to remove the need for explicit soloading.
Changelog: [Android][Removed] `RuntimeExecutor` and `RuntimeScheduler` constructors are now private, `MapBufferSoLoader` was removed as no longer required.
Reviewed By: cortinico
Differential Revision: D69776110
fbshipit-source-id: 11eac4c59897a02283e021ac1457ef8299b6f480
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49474
changelog: [internal]
Can move setup to the background setup:
1. Use RCTTraitCollectionProxy to access current trait collection to check if force touch is available.
2. UIDevice.currentDevice is thread safe and can be read safely from a background thread.
Reviewed By: rshest
Differential Revision: D69744257
fbshipit-source-id: 8857a827c3d3e03a9b2ced15e6970d728693a043
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49473
changelog: [internal]
Add RCTTraitCollectionProxy which synchronises access to current trait collection. This way, RCTAppearance does not need main thread setup and RCTUnsafeExecuteOnMainQueueSync
Reviewed By: javache
Differential Revision: D69750211
fbshipit-source-id: 8457904fa1672d4bf811c04ef69969a8f8f4d87f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49469
This PR updates the changelog for 0.78 by combining all the RC into 0.78.0 stable, in preparation of the release in a couple of days.
This also adds categories to the commits and sort them alphabetically.
## Changelog:
[Internal] - Update vchangelog for 0.78
Reviewed By: cortinico, fabriziocucci
Differential Revision: D69745703
fbshipit-source-id: 825190c7a9573939ec7f1e388448142f8a8caf25
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49497
This change honors the task provided as an argument.
If `all` is passed, we execute all the commands.
If a specific task is passed, we only execute that command.
## Changelog:
[Internal] - Honor the task passed to the preopare-ios-script
Reviewed By: cortinico
Differential Revision: D69787470
fbshipit-source-id: 0dec13ad0b5f2cc23cc72b4a899405ac1acf4f86
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49496
This change prepare the argument parsing to the prepare-ios-prebuilds so we can customise the behavior to simplify usage in CI.
It also adds the --help command to provide.
##changelog:
[Internal] - adds the help mfunction and argument parsing
Reviewed By: cortinico
Differential Revision: D69779877
fbshipit-source-id: d66bc19ee556229eb7167f2075b77bacce2ad5c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49495
This change extracts the dependencies array to a separate file. This is helpful because we can use this file as cache-key to determines whether we have to rebuild the artifacts or not.
This file is also bound to grow so it will make the script more manageable.
## Changelog:
[Internal] - Move the dependencies for ios prebuilds on a separate file
Reviewed By: cortinico
Differential Revision: D69779522
fbshipit-source-id: 7ce60e426d428859f6f759d8e7b1ea499c36eff9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49475
changelog: [internal]
RCTNetworking does not need main thread setup, it doesn't access any main thread only resources.
Reviewed By: rshest
Differential Revision: D69744400
fbshipit-source-id: 25652c28d178a9e26fa0ede9b03fb87072094fb0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49500
changelog: [internal]
When crossing ScrollView boundary, cullingContext.transform must be reset to Transform.identity. Views are only culled within scroll view.
Reviewed By: NickGerleman
Differential Revision: D69787820
fbshipit-source-id: 5d502f764a2b1885ee4b49fc0c9ebb9d27de65dd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49418
This adds some missing validation for negative blurs which should be considered parse error. Unit tests added for the forked props parsing code to validate more generally.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D69628917
fbshipit-source-id: 1451b53cfa673443f01d38bd0097c4e85c83db8b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49505
I want to go home 😭.
This is not very pretty, while we are both keeping the old path, and trying to keep the props data types undisturbed for now, and support some of the stranger syntax we ended up supporting as inputs to filters.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D69562718
fbshipit-source-id: db8ff2c240b66e93a52ce2ac98e4a9ff2e7aeb4b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49503
Relanding this change, now checking for the existing of FeatureFlags native module before checking it, with the assumption when the native module is unavailable (legacy arch) we will never do native processing, or even use the SVC.
This aligns with the approach taken in `setupTimers` for the event loop, but is probably not the right long term solution for flags API.
This also inlines a couple fixes originally up the stack, of missing propagation of inline state, and missing the gating in ReactNativeStyleAttributes.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D69804412
fbshipit-source-id: 1f285994132cff75b6845b64cf26fceae37d4c92
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49448
I noticed that when inset shadows have a smaller blur radius than spread its wrong and there is a gap between the edge of the box and the shadow. I think the outer rect is just defined incorrectly and we should be adjusting the paddingBox as opposed to the innerRect. The innerRect is just the padding box insetted by the spread, so that is why we see gaps if blur < spread
Changelog: [Android][Fixed] - Fix inset boxShadow when blur < spread
Reviewed By: jorge-cab
Differential Revision: D69688508
fbshipit-source-id: 911258edd9a8403c70992800c3e1a5ea044e1f3b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49463
We've started accumulating mode-files in many different directories, group them all under xplat/mode/react-native for consistency
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D69658995
fbshipit-source-id: 70c842d24886b9b0ef8432d105ca64cac68078db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49484
This is the last diff to add support for Gradle Configuration caching.
The last missing part here was the execution of the `config` command during Gradle configuration time.
Using Java processes API is not supported as the correct way to do external commands that are CC-friendly
is through the `.providers.exec` API which I'm using here.
Closes https://github.com/facebook/react-native/issues/45154
Changelog:
[Android] [Added] - Add support for Gradle Configuration caching
Reviewed By: cipolleschi
Differential Revision: D69753889
fbshipit-source-id: af1e844b38444659a908abce4029d43ad899c03d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49491
Changelog: [General][Breaking] Deep imports to modules inside `Libraries/DevMenu` using `require` may need to be appended with `.default`
Reviewed By: cortinico
Differential Revision: D69778671
fbshipit-source-id: 19362fbb003e53609881fc19e8d2cb96677b3006
Summary:
Currently we observed many iOS app crashes caused by the `[RCTFileRequestHanlder invalidate]` method, just as the below screenshot.
<img width="1008" alt="image" src="https://github.com/user-attachments/assets/d2d6714f-63d9-40ae-8de5-742cfe718a36" />
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - app crash caused by the `[RCTFileRequestHanlder invalidate]` method
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [FIXED] - app crash caused by the `[RCTFileRequestHanlder invalidate]` method
Pull Request resolved: https://github.com/facebook/react-native/pull/48350
Test Plan: I am not able to reproduce this issue locally either, so the changes in this PR are totally from my inference, I am not sure if it really makes sense, so please help take a deeper look, thanks.
Reviewed By: javache
Differential Revision: D69751695
Pulled By: cipolleschi
fbshipit-source-id: aa4654a30f5dfac99b72ed1bda0dae1e0dc881c9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49479
changelog: [internal]
Notification UIApplicationDidBecomeActiveNotification is always delivered on the main thread, no need for dispatch.
Reviewed By: javache
Differential Revision: D69750103
fbshipit-source-id: 070fa7f95d8ecddff5d56ba317c8ed4f0ad880f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49470
Adds a `packages/react-native/index.js.flow` file.
**Motivation**
This is on the critical path to generating TypeScript types, and a full API snapshot, from `index.js.flow`.
As we iterate, this new file will move to closely matching `types/index.d.ts` by adding type exports (missing today) — giving us an equivalent public API in both languages.
**Motivation for this pattern**
Having a type index file:
- Will become the entry point for `yarn build-types`.
- Enables us to bypass the `module.exports` pattern in `index.js` without a runtime breaking change.
- This pattern is preferable because:
- 1/ Aligns with existing manual TypeScript definitions (i.e. these are **already restricted** to `import` syntax in user code)
- 2/ Allows doc comments on original types to propagate to IDEs/users.
**Implementation notes**
NOTE: This diff has **no effect** on compiled code at runtime, and **no effect** on the current manual TypeScript API of `react-native`. It only has an effect on Flow usage in fbsource — most of which are deep type imports today.
- Exports are grouped and sorted identically to each pre-existing getter in `index.js`.
Changelog: [Internal] - Redefine root `react-native` type exports, affecting Flow usages only
Reviewed By: rubennorte
Differential Revision: D69659837
fbshipit-source-id: c65e30d1ac5c4f322cfde9335dbee80a8c9efda8
Summary:
ref: https://github.com/facebook/react-native/pull/28266
Currently, SVG is not recognized as an image in the CLI bundle command, as defined in [assetPathUtils.js](https://github.com/facebook/react-native/blob/main/packages/community-cli-plugin/src/commands/bundle/assetPathUtils.js#L43-L50) . This is the correct behavior, as it ensures that SVG files are copied to the raw folder for Android resources.
However, there is an inconsistency with Image.resolveAssetSource, which does not follow the same classification. Instead, it resolves SVG assets to the drawable folder, leading to blank svg rendering errors in some scenario (codepush).
## Changelog
[Android][Fixed] - getAndroidResourceFolderName() should return raw folder for svg file
Pull Request resolved: https://github.com/facebook/react-native/pull/49452
Test Plan:
1. Use svg file this way `<LocalSvg asset={require('./react-logo.svg')} />`
2. Use `react-native bundle` command to make a bundle and sideload that bundle from sdcard. The svg file should render correctly.
Reviewed By: cortinico
Differential Revision: D69750779
Pulled By: Abbondanzo
fbshipit-source-id: 3af8d4a5da07213cdbb968b070d2507ed897d194
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49370
# Changelog: [Internal]
When we start tracing, we will record metadata event for current process.
We will base it off the assumption that the thread where we handle `Tracing.start` event is the main one.
We can't register the main thread yet:
1. We can't assume that CDP messages are handled on it - this is not the case for Windows and in a long term Inspector will be moved to its own thread
2. We don't have any similar mechanism as Runtime Executor, but for Main thread. This will require Host providing an executor for it.
I've validated at the top of the stack that not registering the main thread should not affect how trace is displayed in CDT.
Reviewed By: rozele
Differential Revision: D69465926
fbshipit-source-id: 103de1da9d00564bf201456ad04a465387c1d542
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49083
# Changelog: [Internal]
> NOTE: Some CI jobs are expected to fail, because changes in Hermes D67353585 should be landed first, and then grafted to Static Hermes.
Added 2 new public methods to `PerformanceTracer` instance for registering metadata Trace Events for processes and threads.
Reviewed By: huntie
Differential Revision: D68439733
fbshipit-source-id: dd9f0e72e2414b8c665c57a542cbbfe7df34a516
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49309
# Changelog: [Internal]
Use newly added module to get real OS-level process and thread ids.
We will keep process id on an instance, because I don't think it could change over time? For thread id, we will get it at the time of event registration.
Reviewed By: rozele
Differential Revision: D69316094
fbshipit-source-id: e12f2ea147ee8bf5a0a13ef293b8d85a0b64fc02
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49302
# Changelog: [Internal]
Added OS-agnostic module that will implement 2 basic capabilities:
- Getting current process id
- Getting current thread id
Reviewed By: javache
Differential Revision: D69316093
fbshipit-source-id: 114d235f1137eaf9c41d95df76f15532766d1bc8
Summary:
Recently, I've introduced `RCTReactNativeFactory` in this PR: https://github.com/facebook/react-native/issues/46298, which is a good successor for `RCTAppDelegate`.
### Why?
`RCTAppDelegate` introduced strong coupling between React Native and AppDelegate pattern. From iOS 13+ there is a newer equivalent (Scene Delegate) which is not possible to achieve with current architecture. The proposed solution involves migration to a `RCTReactNativeFactory` a class that encapsulates initialization logic of React Native.
This migration will make brownfield initialization easier by making it more flexible and simpler to integrate into already established apps.
### Deprecation plan
The plan I've discussed with cipolleschi involves:
- Deprecation of `RCTAppDelegate` in 0.79 (current main)
- Migration off `RCTAppDelegate` to SceneDelegate + `RCTReactNativeFactory` in 0.80
## Changelog:
[IOS] [DEPRECATED] - deprecate RCTAppDelegate
Pull Request resolved: https://github.com/facebook/react-native/pull/49078
Test Plan: Not needed
Reviewed By: cortinico
Differential Revision: D69061022
Pulled By: cipolleschi
fbshipit-source-id: b02a0ff3f26be9320da749f38c9cf083804f9f30
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49426
This is a nit, but I'm following up on a review comment that was left behind.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D69656370
fbshipit-source-id: 76de4d77d9993bd9a35d7df019a6cebcce13d632
Summary:
an effort of lean core for jsc: https://github.com/Kudo/discussions-and-proposals/blob/%40kudo/lean-core-jsc/proposals/0836-lean-core-jsc.md. this pr tries to decouple all jsc code when `USE_THIRD_PARTY_JSC=1` on ios
this pr includes these changes:
- exclude `React-jsc` pod and pod dependency when `USE_THIRD_PARTY_JSC=1`
- in objcpp code, remove `JSCExecutorFactory` / `RCTJscInstance` references when `USE_THIRD_PARTY_JSC=1`. it throws c++ errors like `No JSRuntimeFactory specified.` when no engine is specified (USE_HERMES=0 && USE_THIRD_PARTY_JSC=1). people need to override delegate methods to specify a JSRuntimeFactory.
## Changelog:
[IOS] [CHANGED] - Decouple JSC when `USE_THIRD_PARTY_JSC=1`
Pull Request resolved: https://github.com/facebook/react-native/pull/49371
Test Plan:
- ci passed
- rn-tester build success for `RCT_NEW_ARCH_ENABLED=1 USE_THIRD_PARTY_JSC=1 USE_HERMES=0 USE_FRAMEWORKS=dynamic bundle exec pod install`
- rn-tester build success for `RCT_NEW_ARCH_ENABLED=0 USE_THIRD_PARTY_JSC=1 USE_HERMES=0 USE_FRAMEWORKS=dynamic bundle exec pod install`
- rn-tester build success for `RCT_NEW_ARCH_ENABLED=0 USE_THIRD_PARTY_JSC=1 USE_HERMES=0 bundle exec pod install`
Reviewed By: cortinico
Differential Revision: D69662457
Pulled By: cipolleschi
fbshipit-source-id: b272f46dde896d0981cfca75c9bfcf6775507307
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49461
Flow now supports Package Exports 🎉. This means we can delete the compatiblity pattern in each of our build-enabled Node.js packages.
This simplifies the internal package structure needed to support Flow while developing from source in the monorepo — no prod impact.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D69741143
fbshipit-source-id: 070715cb6beb00eb393186dbf95856ceb87fabef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49441
Changelog:
[General][Internal] - keep heartbeat between inspector proxy and debugger going even if not idle
When heartbeat was only used to keep the connection alive and to detect debugger timeouts, it was enough to send a ping every time the connection was idle for 10 seconds.
Now, when we use the heartbeat as a way to track how good is the round trip time between the inspector proxy and the debugger, we would like to make this tracking more reliable by sending a ping 10 seconds after each pong, even if the connection is not idle.
It also simplifies the code and makes it more clear by removing the confusing `shouldSetTerminateTimeout` variable.
Reviewed By: hoxyq
Differential Revision: D69665738
fbshipit-source-id: c8175b54d2b3df32ee60b316ec7bcf7bc0f0a1ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49439
This is the next part of a series of diff needed to enable G. Configuration Cache:
https://docs.gradle.org/current/userguide/configuration_cache.html
as it will make our CI faster (and will be the default in the future Gradle version).
Here I'm removing the `onlyIf` lambdas to make some tasks CC friendly.
The problem is that some `onlyIf` lambdas can't easily be serialized. Here I'm cleaning up
the problematic one to move the condition checks at execution time
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D69664732
fbshipit-source-id: a457b2fae8114568ec4e04d772c9944022b1e1a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49438
This is the second part of a series of diff needed to enable G. Configuration Cache:
https://docs.gradle.org/current/userguide/configuration_cache.html
as it will make our CI faster (and will be the default in the future Gradle version).
Here I'm making the exec tasks CC friendly.
The problem is that previously we were using explicit streams which are not CC friendly
for stderr/stdout. The solution is to create a custom task and handle files as input
properties.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D69662246
fbshipit-source-id: ad7e82e52b12d508ee15b68408882fdc3516d287
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49421
This is a first part of a series of diff needed to enable G. Configuration Cache:
https://docs.gradle.org/current/userguide/configuration_cache.html
as it will make our CI faster (and will be the default in the future Gradle version).
Here I'm making all those tasks `prepare*` CC friendly.
Those tasks were not CC friendly as they were referencing an external variable inside their body.
We don't need to know the library version, we can just substring after the first folder
and the tasks will behave as before.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D69655168
fbshipit-source-id: 801d7817c7e2d7380342f175565cc9b1ff30c5d0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49458
Changelog: [Internal]
Sorts the entry points in the TS generator script and adds `Clipboard` and `AccessibilityInfo` which, as far as I can see, require no changes for their types to align with OSS.
Reviewed By: huntie
Differential Revision: D69663092
fbshipit-source-id: cfdb9ab5c07105497a1cdf4ebdc8de1e34b510bd
Summary:
Problem: Duplicate issues were notified on discord channel in issue triaging section.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[GENERAL] [FIXED] - Changed cron timings to run at fix schedule and upgraded action for better debugging
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [FIXED] - Changed cron timings to run at fix schedule and upgraded action for better debugging
Root cause:
- The cron job (cron: "0 /6 * *") is expected to run every 6 hours.
- Expected runs: 5:54 AM → 11:54 AM → 5:54 PM.
- However, the second run happened earlier at 11:37 AM instead of 11:54 AM.
- This caused duplicate pings for issues created around 5:42:24 AM.
Pull Request resolved: https://github.com/facebook/react-native/pull/49407
Test Plan: Tested action locally
Reviewed By: cortinico, NickGerleman
Differential Revision: D69667174
Pulled By: cipolleschi
fbshipit-source-id: 3dcadc25783335c32cba8acdda26e1c755294629
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48585
[Changelog] [Internal] - Align logic in BaseTextInputShadowNode to determine updateStateIfNeeded with AndroidTextInputShadowNode
As a preparation for https://github.com/facebook/react-native/pull/48165 this aligns the implementation of those 2 methods
Reviewed By: javache
Differential Revision: D68004755
fbshipit-source-id: 519247de0d081f37b5ef8ad6093b43d2c735a50e
Summary:
An internal crash report notified us that we were getting an `IllegalArgumentException` in Android's `BlurMaskFilter` used in Box Shadows. The only requirement for the arguments there are that the blur radius is positive. We ensure that, but pass to `sigmaToRadius` afterwards, which does NOT ensure that. This updates that conversion so that
* We will never return negative numbers, regardless of what `PixelUtil.toDIPFromPixel` is doing
* Small enough numbers ( < 0.5) will just go through as 0.0, which is what Android does in https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/libs/hwui/utils/Blur.cpp;l=34
* Ensure shadows check that we have a POSITIVE blur radius AFTER conversion. sigmaToRadius can still return 0 which with also throw, so gotta make sure we change our checks. Filter blurs and dropShadow should be ok, renderEffect does not mention anything about being > 0 in the docs.
Changelog: [Android] [Fixed] - Fix issue where boxShadow crashes with small blur radius
Facebook
Post alerting us of this: https://fb.workplace.com/groups/rn.panelapps/permalink/1136446121310146/
Reviewed By: NickGerleman
Differential Revision: D69683031
fbshipit-source-id: 92f0938fea65e1af280bdb12b6c3d2b9014e89c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49445
This diff marks a subset of LayoutAnimations classes with LegacyArchitecture, since these classes should not be called, loaded nor included in apk that are running in new archtictecture by default
changelog: [internal] internal
Reviewed By: shwanton
Differential Revision: D69674674
fbshipit-source-id: 84c71c7491064abf8d70f52b14ddb81bd0515227
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49443
This diff introduces an internal annotation called LegacyArchitecture that will be used to document what classes are part of Legacy or new architecture
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D69538444
fbshipit-source-id: 5037ba03cd3b1675544f432c3981503c28606f19
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49435
This change adds a Package.swift file that allows to consume the binary from a local path.
As soon as we publish this on Maven, we will update the path to the url.
## Changelog:
[Internal] - Add the Package.swift file to consume the binary
Reviewed By: cortinico
Differential Revision: D69660943
fbshipit-source-id: c76ff3272d106236b6cf713b7e054070a3d45176
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49434
This change adds a function to create the xcframework sarting from the various .framework's slice built before.
## Changelog:
[Internal] - Add function to create the xcframework
Reviewed By: cortinico
Differential Revision: D69660662
fbshipit-source-id: f58034c75cce3d242910d0ec1512be28059771ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49433
This change adds the logic to copy the Headers files from the dependency folder to the generated frameworks folder.
There is a slight possibility that this function will be implemented by the Swift PM build system, as I open [this question](https://forums.swift.org/t/xcodebuild-does-not-generate-headers-if-the-source-is-swift-pm/77856) on the Swift forums.
In that case, we would be able to drop this.
## Changelog:
[Internal] - Add function to copy headers over to the .frameworks
Reviewed By: cortinico
Differential Revision: D69656046
fbshipit-source-id: e9d4f0f53ea57bc0df86fc9194cdf9fc1f372730
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48724
changelog: [internal]
A change in D68154908 caused issues where AnimatedValue would oversubscribe to native module, bring apps to halt.
This is unit test to prevent that.
Reviewed By: yungsters
Differential Revision: D68265033
fbshipit-source-id: 60cc93a619a5c654dc1bf77b00b2d9be2c482894
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49402
## Motivation
Modernising the RN codebase to allow for modern Flow tooling to process it.
## This diff
- Migrates `Utilities/dismissKeyboard.js`, `Utilities/GlobalPerformanceLogger.js` and `Utilities/SceneTracker.js` to use the export syntax.
- Updates deep-imports of these files to use `.default`
- Updates jest mocks
- Updates the current iteration of API snapshots (intended).
Changelog:
[General][Breaking] - Deep imports to `Utilities/dismissKeyboard.js`, `Utilities/GlobalPerformanceLogger.js` or `Utilities/SceneTracker.js` with `require` syntax need to be appended with '.default'.
Reviewed By: huntie
Differential Revision: D69599636
fbshipit-source-id: 0c450996f908d8139dd0c48677f58e07243d6150
Summary:
Fix `react-native-community/cli` not being found in pnpm setups
## Changelog:
[GENERAL] [FIXED] - Fix `react-native-community/cli` not being found in pnpm setups
Pull Request resolved: https://github.com/facebook/react-native/pull/47304
Test Plan:
1. Clone/check out this branch: https://github.com/microsoft/rnx-kit/pull/3409
2. Run `yarn react-native config`
Reviewed By: cortinico
Differential Revision: D65209065
Pulled By: robhogan
fbshipit-source-id: 2ceb73ad140b4afe193e879779c2d8a4b9adf3fc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49400
We should not invoke anything on the `project` property inside thet task.
That will break Gradle Configuration Caching which is becoming the default in the next version of Gradle.
This fixes it for the `GenerateCodegenArtifactsTask` task.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D69592464
fbshipit-source-id: 72bab3f29299313875f2e7abd1b701c9d74bd2a1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49399
We should not invoke anything on the `project` property inside thet task.
That will break Gradle Configuration Caching which is becoming the default in the next version of Gradle.
This fixes it for the `GenerateCodegenSchemaTask` task.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D69592463
fbshipit-source-id: 56e78b1bdc113ae402cc90960faa05cd73d5b97d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49398
We should not invoke anything on the `project` property inside thet task.
That will break Gradle Configuration Caching which is becoming the default in the next version of Gradle.
This fixes it for the `BuildCodegenCLITask` task.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D69592465
fbshipit-source-id: fc69896b61968ace7b7762f873cfa7eaa50c8b17
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49417
In this diff I'm introducing a fantom benchmarking test to verify impact of props parsing in Fabric (testing for 100, 1000 and 1500 nested views)
changelog: [internal] internal
Reviewed By: lenaic
Differential Revision: D69624243
fbshipit-source-id: fe71668fe97558d2b6072fe49c9910cb978f7f78
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49415
Refactoring NAME -> TAG for consistency with other classes
changelog: [internal] internal
Reviewed By: Abbondanzo
Differential Revision: D69622546
fbshipit-source-id: 314db29ddfdbbd7fc614b355b9b18c0a8afe31df
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49414
In this we are enforcing that that ViewManagers using codegen override getDelegate() method.
For now we are logging a softException to get signal from production without crashing the app
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D69621301
fbshipit-source-id: 1434fb3f3c7e5ebebee172ec1d7ad6c21eb453ae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49363
This change adds the `build()` function that calls xcodebuild to prepare the ReactNativeDependencies.framework
This functio creates the frameworks in the /react-native/third-party/.build folder
## Changelog:
[Internal] - Add build folder to the `prepare-ios-script`
Reviewed By: cortinico
Differential Revision: D69533218
fbshipit-source-id: edc9281e9270970084aa0f56b52ced4579df3473
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49361
This change adds the Package.swift file that we will use to build the dependencies for React Native
## Changelog:
[Internal] - Swift PM file to build ReactNativeDependencies
Reviewed By: cortinico
Differential Revision: D69518776
fbshipit-source-id: 85006c3c5933cc6a5fd772f7b014a823d7bb99b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49360
We don't need the whole dependencies archiveto build the dependencies. But usually we only need a subset of them.
This change add a functionality to the script to remove the unnecessary files.
## Changelog:
[Internal] - Add feature to remove unnecessary files from 3p dependencies.
Reviewed By: cortinico
Differential Revision: D69518656
fbshipit-source-id: b071626a1894261b75023023b7f7eeb2730282a2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49336
This change adds the step to download the glog dependency and run the prepare_glog script that we have in the codebase
## Changelog:
[Internal] - Download Glog and patch it.
Reviewed By: cortinico
Differential Revision: D69466238
fbshipit-source-id: df0b4e29d4ff7d0d61f92a52141935472fa964fe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49335
This change adds a function in the prebuild script to download a 3p dependency in the react native monorepo.
## Changelog:
[Internal] - Add function to download 3rd party dependencies
Reviewed By: cortinico
Differential Revision: D69464429
fbshipit-source-id: 2d035168c2390eb9fa9e2338976fce15d86fb68c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49334
This diff adds a script in the `react-native/script/releases` folder that we will use as base to prepare prebuilds for iOS
The script can be invoked from the repository root with
```
node scripts/releases/prepare-ios-prebuilds.js
```
## Changelog:
[Internal] - Add scripts to prepare ios prebuilds
Reviewed By: cortinico
Differential Revision: D69461691
fbshipit-source-id: 8d33955dd799f95c43de565e48360558d7d946d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49408
## Motivation
Modernising the RN codebase to allow for modern Flow tooling to process it.
## This diff
- Migrates Utilities/deepFreezeAndThrowOnMutationInDev.js, Utilities/defineLazyObjectProperty.js, Utilities/DeviceInfo.js & Utilities/FeatureDetection.js to use the export syntax.
- Updates deep-imports of files that were migrated to a single export default to use `.default`
- Updates the current iteration of API snapshots (intended).
Changelog:
[General][Breaking] - Deep imports to `Utilities/deepFreezeAndThrowOnMutationInDev`, `Utilities/defineLazyObjectProperty`, `Utilities/DeviceInfo` or `Utilities/FeatureDetection` with `require` syntax may need to be appended with '.default'.
Reviewed By: huntie
Differential Revision: D69602536
fbshipit-source-id: 7ec06995a1d244b95d4f970551955d9e6013de13
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49306
## Motivation
Modernising the RN codebase to allow for modern Flow tooling to process it.
## This diff
- Migrates `Libraries/Utilities/Platform.*.js` to use the export syntax.
- Updates deep-imports of these files to use `.default`
- Updates jest mocks
- Updates the current iteration of API snapshots (intended).
Changelog:
[General][Breaking] - Deep imports to `Libraries/Utilities/Platform` with `require` syntax needs to be appended with '.default'.
Reviewed By: huntie
Differential Revision: D69404025
fbshipit-source-id: f21501ca5b7e8e6a9e3e501781ed36e7d2bfd4a4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49406
## Motivation
Modernising the RN codebase to allow for modern Flow tooling to process it.
## This diff
- Migrates Utilities/infoLog, Utilities/logError, Utilities/mapWithSeparator & Utilities/warnOnce to use the export syntax.
- Updates deep-imports of these files to use `.default`
- Updates the current iteration of API snapshots (intended).
Changelog:
[General][Breaking] - Deep imports to `Utilities/infoLog`, `Utilities/logError`, `Utilities/mapWithSeparator` or `Utilities/warnOnce` with `require` syntax need to be appended with '.default'.
Reviewed By: huntie
Differential Revision: D69601174
fbshipit-source-id: 821f9ae59d4f898c95631eb7a9aeed138ace3567
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49403
## Motivation
Modernising the RN codebase to allow for modern Flow tooling to process it.
## This diff
- Migrates `Utilities/binaryToBase64`, `Utilities/DevSettings`, `Utilities/PolyfillFunctions` & `Utilities/RCTLog` to use the export syntax.
- Updates deep-imports of these files to use `.default`
- Updates the current iteration of API snapshots (intended).
Changelog:
[General][Breaking] - Deep imports to `Utilities/binaryToBase64`, `Utilities/DevSettings`, `Utilities/PolyfillFunctions` or `Utilities/RCTLog` with `require` syntax need to be appended with '.default'.
Reviewed By: huntie
Differential Revision: D69600476
fbshipit-source-id: 3f8ac3a35031e8b20446abc8f52a2817cb31b6d2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49369
## Motivation
Modernising the RN codebase to allow for modern Flow tooling to process it.
## This diff
- Migrates `Libraries/Utilities/BackHandler.*.js`, `Utilities/DevLoadingView.js` and `Utilities/HMRClient*.js` to use the export syntax.
- Updates deep-imports of these files to use `.default`
- Updates jest mocks
- Updates the current iteration of API snapshots (intended).
Changelog:
[General][Breaking] - Deep imports to `Libraries/Utilities/BackHandler`, `Utilities/DevLoadingView.js` or `Utilities/HMRClient*.js` with `require` syntax needs to be appended with '.default'.
Reviewed By: huntie
Differential Revision: D69539527
fbshipit-source-id: c10b3523bbcc52bba5b6c27721c33b1e0d9d5104
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49405
This diff removes legacy codegen of $PropSetter classes for ShadowNode classes when the app has UNSTABLE_ENABLE_MINIFY_LEGACY_ARCHITECTURE enabled
These classes are not used in the new architecture, let's just remove them from the apk.
This change won't affect OSS
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D69569205
fbshipit-source-id: 178051b9f10576226fd746f9eab1b56b2934ea0b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49404
This diff disables codegen of legacy $PropSetter for viewManagers that implement the interface com.facebook.react.uimanager.ViewManagerWithGeneratedInterface.
This logic will only be enabled for apps that are configured with BuildConfig.UNSTABLE_ENABLE_MINIFY_LEGACY_ARCHITECTURE = true
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D67412734
fbshipit-source-id: 682725714dc41f5f34d95d4d9a13ab09726b28f7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49386
It appears that `currentActivity.decorView` sometime is not attached to a window during the process of creating a Dialog for currently unknown reasons causing a crash.
Add check to skip call to `syncSystemBarsVisibility()` in such case as current code cannot function without valid RootWindowInsets.
Changelog:
[Android][Fixed] - fixed crash with Modal when trying to call syncSystemBarsVisibility()
Reviewed By: cortinico
Differential Revision: D69578581
fbshipit-source-id: de23e2ba9f485e38b7014dd7151253e56976ad43
Summary:
On the new architecture the `RCTParagraphTextView` is used to draw text on iOS but React doesn't know about it. The hit test stops propagation on the first encountered UIView of this type. The suggested solution is to add a dummy hit test for `RCTParagraphTextView` that returns always `null`, allowing further search of the touch target.
## 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] - Fixed onPress for Text with nested View.
Pull Request resolved: https://github.com/facebook/react-native/pull/49393
Test Plan:
| Before | After |
|--------------|--------------|
|<video src="https://github.com/user-attachments/assets/745f555a-d4b6-4285-91a7-0e9ea9f43d84"> | <video src="https://github.com/user-attachments/assets/9896848f-13ca-4b57-bcc9-bead478ab078"> |
<details>
<summary>code</summary>
```ts
import {SafeAreaView, StyleSheet, Text, View, findNodeHandle} from 'react-native';
function App() {
return (
<SafeAreaView style={styles.container}>
<Text
ref={e => console.log(`Outer Text: ${findNodeHandle(e)}`)}
>
With Nested View
<View ref={e => console.log(`View: ${findNodeHandle(e)}`)}>
<Text
ref={e => console.log(`Inner Text: ${findNodeHandle(e)}`)}
onPress={() => {
console.log('1. text pressed');
}}
style={styles.pressableText}
>
Pressable Text
</Text>
</View>
</Text>
<Text>
Without Nested View
<Text
onPress={() => {
console.log('2. text pressed');
}}
style={styles.pressableText}
>
Pressable Text
</Text>
</Text>
</SafeAreaView>
);
}
const styles = StyleSheet.create({
container: {
flex: 1,
justifyContent: 'center',
alignItems: 'center',
gap: 10,
},
pressableText: {
fontSize: 18,
color: 'blue',
backgroundColor: 'transparent',
},
nestedView: {
backgroundColor: 'red',
height: 100,
},
pressable: {
backgroundColor: 'blue',
height: 100,
width: 100,
},
});
export default App;
```
</details>
Reviewed By: cipolleschi
Differential Revision: D69591520
Pulled By: coado
fbshipit-source-id: eb75c2d8a01a82d4493a1a982e98ca74efc9d94f
Summary:
> [!NOTE]
> This PR is part of JavaScriptCore Extraction to this repository: https://github.com/react-native-community/javascriptcore
This PR adds `jsitooling` package that third party JS engines can use (in that case javascriptcore). It's required because React-Runtime needs to depend on third-party engine on iOS, and the third-party engine needed to depend on React-Runtime to get access to the `JSRuntimeFactory` and Cocoapods doesn't support circular dependencies...
Now third-party engine can depenend on jsitooling package and provide JSRuntimeFactory
## Changelog:
[INTERNAL] [ADDED] - jsitooling package
Pull Request resolved: https://github.com/facebook/react-native/pull/49348
Test Plan: CI Green
Reviewed By: cortinico
Differential Revision: D69535475
Pulled By: cipolleschi
fbshipit-source-id: f8d68b7957b7d69c13246ce3040a08256f2ebcd6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49364
We're not actively using/maintaining this package. Let's clean it up.
We can still restore if necessary.
Changelog:
[Internal] [Changed] -
bypass-github-export-checks
Reviewed By: cipolleschi
Differential Revision: D69533629
fbshipit-source-id: 940057df9a5fffa738435c92136e95a764ec98ff
Summary:
This PR encapsulates device info listeners removing additional logic from RCTAppDelegate which is a prerequisite for https://github.com/facebook/react-native/pull/49078
Now we use KVO (Key Value Observation) to listen to window size changes making this module's logic encapsulated + allows to use it in brownfield scenarios.
To keep backward compatibility RCTDeviceInfo still emits `RCTWindowFrameDidChangeNotification`
## Changelog:
[IOS] [ADDED] - encapsulate device info listeners
Pull Request resolved: https://github.com/facebook/react-native/pull/49162
Test Plan: Check if window size change listener is fired
Reviewed By: sammy-SC
Differential Revision: D69116660
Pulled By: cipolleschi
fbshipit-source-id: b9a57c70826b10cd27d102337eb1e35da1b365c9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49303
Changelog: [General][Breaking] Deep imports to modules inside `Libraries/StyleSheet` using `require` may need to be appended with `.default`
Reviewed By: huntie
Differential Revision: D69400980
fbshipit-source-id: 053f40a8677ac877b93c27e87422ea0ef540c272
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49358
When the network is under strain, the code responsible for detecting if the inspector proxy's connection to the client has been lost may incorrectly assume the connection is dead. This false positive occurs because the system assumes that if a pong is not received within 5 seconds of a ping, the other side has disconnected. However, I was able to consistently reproduce scenarios where a delay of more than 5 seconds (even more than 20 seconds) was followed by a return to normal ping-pong communication without any issues.
Since I can't think of any issues with increasing this number, I'm increasing it to 60s.
Changelog:
[General][Fixed] - Disconnections of DevTools when the network is under significant strain.
Reviewed By: robhogan, huntie
Differential Revision: D69523906
fbshipit-source-id: 50db1e7bbe690b42421bc226aa30fd6571ba2257
Summary:
When generating documentation using dokka, I found out that some references to classes in the comments were not linking correctly anymore after the files were migrated to Kotlin. In this PR I'm migrating the JavaDoc `link` references to Kotlin KDoc `[]` syntax.
## Changelog:
[INTERNAL] - Fix up KDoc annotations post Kotlin migrations
Pull Request resolved: https://github.com/facebook/react-native/pull/49375
Test Plan: Manually review that the references link correctly in the Kotlin files
Reviewed By: arushikesarwani94
Differential Revision: D69549229
Pulled By: mdvacca
fbshipit-source-id: 6b7727f00a28ecfe2fca86948245d1f4e88e935c
Summary:
Migrate com.facebook.react.modules.network.OkHttpClientProvider to Kotlin. Also, as follow up from https://github.com/facebook/react-native/pull/48958 I'm cleaning up the reflection on `OkHttpClientProviderTest` as we can make `sClient` and `sFactory` internal.
## Changelog:
[INTERNAL] - Migrate com.facebook.react.modules.network.OkHttpClientProvider to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/49108
Test Plan:
```bash
yarn test-android
yarn android
```
Reviewed By: cortinico
Differential Revision: D69050956
Pulled By: javache
fbshipit-source-id: 62dcf8e8f999f3b687c57ed02e9ac1f2db8183ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49340
This tool enables checking the boundary between JavaScript and Native for
backwards incompatible changes to protect against crashes.
This is useful for:
- Local Development
- Over the Air updates on platforms that support it
- Theoretically: Server Components with React Native
Check out the Readme for more information
Changelog: [General][Added] Open Sourcing React Native's Compatibility Check
Reviewed By: panagosg7
Differential Revision: D69476742
fbshipit-source-id: 8af6039839c5475c1258fa82d9750a9320cf0751
Summary:
This updates the Issue Triaging bot to ping the oncall
## Changelog:
[INTERNAL] -
Pull Request resolved: https://github.com/facebook/react-native/pull/49359
Test Plan: Nothing to test
Reviewed By: cipolleschi
Differential Revision: D69527137
Pulled By: cortinico
fbshipit-source-id: 7291054a734bf9f7240002773b716b2057aa8eca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49353
This change adds an opt-in to restore JavaScript log streaming via the Metro dev server, [removed from React Native core in 0.77](https://reactnative.dev/blog/2025/01/21/version-0.77#removal-of-consolelog-streaming-in-metro).
Users can opt into this legacy behaviour by adding the `--client-logs` flag to `npx react-native-community/cli start`.
- The default experience remains without streamed JS logs.
- The existing "JavaScript logs have moved! ..." notice is printed in all cases, and we do not advertise the new flag for new users.
- Under non-Community CLI dev servers (i.e. Expo), log streaming is restored implicitly.
We will clean up this functionality again when we eventually remove JS log streaming over `HMRClient`, tasked in T214991636.
**Implementation notes**
- Logs are always sent over `HMRClient` (previous status quo), even with log streaming off in the dev server. This is a necessary evil to be able to flag this functionality in a user-accessible place, and to move fast for 0.78.
- Necessarily, emitting `fusebox_console_notice` moves to the dev server itself, on first device (Fusebox) connection.
Changelog:
[General][Added] - Add opt in for legacy Metro log streaming via `--client-logs` flag
Reviewed By: robhogan
Differential Revision: D69469039
fbshipit-source-id: be99d02a3b1c977a59bf7d2726f0e6cf2e60b28a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49275
This is a copied guava class and is only used in one spot. Remove it and just count directly in ProgressRequestBody.
Changelog: [Internal]
Reviewed By: Abbondanzo
Differential Revision: D69323277
fbshipit-source-id: 5260004a4431f03733882b6ee83a341d8bf29bb0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49332
## Motivation
Modernising the RN codebase to allow for modern Flow tooling to process it.
## This diff
- Migrates `Libraries/Utilities/differ/*.js` to use the export syntax.
- Updates deep-imports of these files to use `.default`
- Updates codegen with a compat layer
- Updates the current iteration of API snapshots (intended).
Changelog:
[General][Breaking] - Deep imports to `Libraries/Utilities/differ/...` with `require` syntax need to be appended with '.default'.
Reviewed By: yungsters
Differential Revision: D69467423
fbshipit-source-id: 2e58a0b9711e9bdf5ca907a5b2252584f6fec9bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49349
Follow-up on D69454101 to add more test coverage for `$ReadOnlyArray<UnsafeMixed>` as a component prop. The new type was missing from the CodegenSchema, which revealed some gaps in tests.
Changelog: [Internal]
Reviewed By: fabriziocucci
Differential Revision: D69488035
fbshipit-source-id: 19895e55e5ec4d89a790f1c388de9eea025a316c
Summary:
Fix `react-native-community/cli-platform-*` packages not being found in monorepos.
Note that we are making the assumption that `process.cwd()` returns the project root. This is the same assumption that `react-native-community/cli` makes. Specifically, `findProjectRoot()` has an optional argument that defaults to `process.cwd()`:
- [`findProjectRoot()`](https://github.com/react-native-community/cli/blob/14.x/packages/cli-tools/src/findProjectRoot.ts)
- Which gets called without arguments in [`loadConfig()`](https://github.com/react-native-community/cli/blob/14.x/packages/cli-config/src/loadConfig.ts#L89)
- `loadConfig()` gets called from [`setupAndRun()`](https://github.com/react-native-community/cli/blob/14.x/packages/cli/src/index.ts#L196), also without project root set
As far as I can see, the project root argument is only ever used in tests.
## Changelog:
[GENERAL] [FIXED] - Fix `react-native-community/cli-platform-*` packages not being found in monorepos
Pull Request resolved: https://github.com/facebook/react-native/pull/47308
Test Plan:
1. Clone/check out this branch: https://github.com/microsoft/rnx-kit/pull/3409
2. Cherry-pick https://github.com/facebook/react-native/pull/47304
3. Cherry-pick https://github.com/facebook/react-native/pull/47308
4. Run `react-native config` inside `packages/test-app`
5. Verify that `projects` is populated
**Before:**
```js
"healthChecks": [],
"platforms": {},
"assets": [],
"project": {}
}
```
**After:**
```js
"healthChecks": [],
"platforms": {
"ios": {},
"android": {}
},
"assets": [],
"project": {
"ios": {
"sourceDir": "/~/packages/test-app/ios",
"xcodeProject": {
"name": "SampleCrossApp.xcworkspace",
"path": ".",
"isWorkspace": true
},
"automaticPodsInstallation": false,
"assets": []
},
"android": {
"sourceDir": "/~/packages/test-app/android",
"appName": "app",
"packageName": "com.msft.identity.client.sample.local",
"applicationId": "com.msft.identity.client.sample.local",
"mainActivity": "com.microsoft.reacttestapp.MainActivity",
"assets": []
}
}
}
```
Reviewed By: cortinico
Differential Revision: D69465533
Pulled By: robhogan
fbshipit-source-id: 3d6cf32752a7a41d9c7e84f35b0f26ae7d7a971f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49345
This diff is causing an error to be logged for every user. Even if it's noise, its more trouble than its worth. Let's revert until feature flags check fixed.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D69504966
fbshipit-source-id: 13caf715cef9a4cc6c9b7c68d3003fbced870d34
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49338
This doesn't cover all cases, but is a good start.
Where relevant, I call out inline places where there are KPs with LogBox that will be fixed separately.
## Changelog
Changelog: [internal]
Reviewed By: rubennorte
Differential Revision: D69443040
fbshipit-source-id: 7281f30aa705ae812d5b5f5f9ad03b37358de059
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49337
*Note: This diff adds helpers and updates the one test we have. The next diff adds a bunch of tests, see that diff for how these helpers are used to scale to a large number of tests.*
-----
## Overview
Adds helpers for the LogBox e2e test to make it easier to write simple, readable, tests with a healthy level of abstraction over the e2e APIs.
## API
The helpers expose an ability to render a component, and return methods to get the UI state:
```
// Returns the LogBox inspector UI as an object.
getInspectorUI: () => ?InspectorUI,
// Returns the LogBox notification UI as an object.
getNotificationUI: () => ?NotificationUI,
```
These return objects that represent the main text elements in the UI like `title` and `message`.
The helpers also provide methods for interacting with the LogBox UI:
```
// True if the LogBox inspector is open.
isOpen: () => boolean,
// Tap the notification to open the LogBox inspector.
openNotification: () => void,
// Tap to close the notification.
dimissNotification: () => void,
// Tap the minimize button to collapse the LogBox inspector.
mimimizeInspector: () => void,
// Tap the dismiss button to close the LogBox inspector.
dismissInspector: () => void,
// Tap the next button to go to the next log.
nextLog: () => void,
// Tap the previous button to go to the previous log.
previousLog: () => void,
```
## Example test
This allows writing tests like:
```
test('should log error', () => {
const logBox = renderLogBox(<ComponentThatErrors />);
// Should show notification
expect(logBox.isOpen()).toBe(false);
expect(logBox.getNotifciationUI()).toEqual({
count: '!',
message: 'error message',
});
// Tap the notification
logBox.openNotification();
// Should show log
expect(logBox.isOpen()).toBe(true);
expect(logBox.getInspectorUI()).toEqual({
header: 'Log 1 of 1',
title: 'Console Error',
message: 'error message',
stackFrames: [
'ComponentThatErrors'
],
componentStackFrames: [
'<ComponentThatErrors />',
],
isDismissable: true,
});
})
```
## Changelog
Changelog: [internal]
Reviewed By: rubennorte
Differential Revision: D69443041
fbshipit-source-id: c81ccd56a39d01d61814d29515b587096c0509c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49343
Raise source and target version of annotation processor from 7 to 11
This is unused in OSS
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D69478025
fbshipit-source-id: 28c6ed5889db423c43a36ccee396083ae7e78e5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49317
This hooks into `enableNativeCSSParsing()` to optionally bypass viewconfig processor, and lets us parse the raw strings (or objects composed of string) in native.
Right now, to not disturb too much while this is in experimentation, this is just a facade over existing types and props storage, and we ignore any non-px lengths.
Also need to prepend
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D69337482
fbshipit-source-id: 6093e312e0d1dc1855713da20b72bf75b98af3ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49316
This hooks up some build logic for `react/renderer/css`. A bit funky right now since header only, and might need to change later (it isn't neccesarily guaranteed to be header only in the future).
Changelog: [Internal]
Reviewed By: cortinico, cipolleschi
Differential Revision: D69426450
fbshipit-source-id: 77e0ef409f34daf003d28a5cd70de935bd180440
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49333
The rollout of "new architecture everywhere" should be enabled in OSS canary releases. This diff updates the ReactNativeFeatureFlags.config.js to reflect that all of the feature flags used by the new architecture are enabled by default in experimental and canary releases. Note that these feature flags were already enabled in OSS when new architecture was enabled.
changelog: [internal] internal
Reviewed By: rubennorte, NickGerleman
Differential Revision: D69419662
fbshipit-source-id: 6ecf9e38bb2fd0d3c0f7129ae16fcef8755b5da2
Summary:
> [!NOTE]
> This PR is part of JavaScriptCore Extraction to this repository: https://github.com/react-native-community/javascriptcore
This PR centralizes the setup of js engine dependencies which need to be defined when building with dynamic frameworks. This will allow us to change linked framework if using a third party one in the future
## Changelog:
[INTERNAL] [CHANGED] - centralize JS engine dependency configuration
Pull Request resolved: https://github.com/facebook/react-native/pull/49297
Test Plan: CI Green (Build needs to go properly)
Reviewed By: javache
Differential Revision: D69396641
Pulled By: cipolleschi
fbshipit-source-id: deedd12084f563f73f12f8617fdca0a6d680bf5a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49262
Changelog: [General][Breaking] Deep imports into `react-native/virtualized-lists` with require syntax may need to be appended with `.default`
Reviewed By: huntie
Differential Revision: D69308532
fbshipit-source-id: 6de15d46e0931616bc9849edbccb7cf745e15dd5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49204
Changelog: [internal]
We don't copy the options object and just access the individual properties, so using an interface is enough, and has the benefit of not having to create object copies to pass down to subclasses.
Reviewed By: yungsters
Differential Revision: D69182824
fbshipit-source-id: 9819e5627d72761c78d0f39a1861a3239066dbb2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49311
This tool enables checking the boundary between JavaScript and Native for
backwards incompatible changes to protect against crashes.
This is useful for:
- Local Development
- Over the Air updates on platforms that support it
- Theoretically: Server Components with React Native
Check out the Readme for more information
Changelog: [General][Added] Open Sourcing React Native's Compatibility Check
Reviewed By: yungsters
Differential Revision: D69277991
fbshipit-source-id: 886a983d4b17609ce771cdd93b75f34bbd8417dc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49035
## Motivation
Modernising the RN codebase to allow for modern Flow tooling to process it.
## This diff
- Migrates files in `Libraries/Modal/*.js` and `Libraries/Network/*.js` to use the `export` syntax.
- Updates deep-imports of these files to use `.default`
- Updates jest mocks
- Updates the current iteration of API snapshots (intended).
Changelog:
[General][Breaking] - Deep imports to modules inside `Libraries/Modal` and `Libraries/Network` with `require` syntax may need to be appended with '.default'.
Reviewed By: huntie
Differential Revision: D68827032
fbshipit-source-id: 98149055f82edad96e74371a79f05f88a8ab3b66
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49324
Provide Android component codegen a bit more flexibility by allowing `$ReadOnlyArray<UnsafeMixed>` and avoid casting in the view manager.
Changelog: [General][Added]
Reviewed By: fabriziocucci
Differential Revision: D69454101
fbshipit-source-id: c210647deffeb01b7db8aa07266e58c42acf14ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49301
The hermesc logging is extremely noisy and not relevant for the users. I'm disabling it for the task that runs metro+hermesc (only for the hermesc) part.
Changelog:
[Internal] [Changed] - Disable console logging for hermesc
Reviewed By: robhogan
Differential Revision: D69399156
fbshipit-source-id: e5f8722b33d30675aba5a8aa82c456be21254b0c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49300
With the refactor of the AppDelegate in favor ReactNativeFactory, the users can now instantiate multiple instances of react native.
However, currently, if you try to run multiple instances, the app will crash with the message:
```
libc++abi: terminating due to uncaught exception of type std::runtime_error: Feature flags cannot be overridden more than once
```
This happens also when the feature flags we would like to set are the same that we already applied. This should be an allowed scenario because reapplying the excatly same features flags should have no effect on React native and that's not the use case we want to forbid.
With this change, we are creating a static variable that checks whether we already apply that set of feature flags and it allows you to create multiple instances by keeping the same flags
## Changelog:
[iOS][Fixed] - Allow multiple RN instances to run at the same time
Reviewed By: rubennorte
Differential Revision: D69398441
fbshipit-source-id: a377c6a1402d38d66d348fa8c6a65e645973aadc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49308
changelog: [internal]
move TinyMap class to its own file in internal folder.
Reviewed By: NickGerleman
Differential Revision: D69402458
fbshipit-source-id: e16d5f33ef0e704e3336cf6f13f510206d7f5e5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49307
changelog: [internal]
There were parts of Differentiator that were leaking outside of "mounting" module. This diff moves them to "internal" folder and changes buck so they can't be imported from outside the module.
Reviewed By: NickGerleman
Differential Revision: D69401878
fbshipit-source-id: 8aa8c96e91b088dab4f9c8b9a5e6937e09be7eb4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49304
changelog: [internal]
View culling must take transform into account when calculating whether a frame is visible or not. This diff adds that.
Reviewed By: NickGerleman
Differential Revision: D69394909
fbshipit-source-id: 4c588a64f2c8e2d35fb7d606d26adc09d3502780
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49278
The previous diff (https://github.com/facebook/react-native/pull/49272) fixed an issue where we used frame to get the size of a sublayer. This is problematic in that it scales things twice if a scaling transform is applied. I looked to see where else we do this and we have this problem (sometimes) with background color and filter.
To fix this in the general case I created a helper to size a layer to the same shape as the View's layer - so using bounds for the size, (0,0) for position on the frame, and cornerRadius/mask for border radius considerations. The only 3 layers that should be the exact same size are backgroundColorLayer, backgroundImageLayer, and filterLayer
Changelog: [iOS] [Fixed] - Fix cases where background color, filter, and background image were sized incorrectly if there was a scaling transform
Reviewed By: jorge-cab
Differential Revision: D69321790
fbshipit-source-id: 70b5d18fa01967896b1bfffdb5684c2c907f3549
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49272
Turns out bounds does not account for the proper size if a scaling transform is applied while frame does. Using the example listed in https://github.com/facebook/react-native/issues/49134, the size of the frame is the expected 240, but the size of the bounds is 200.
We had a mismatch where we use bounds everywhere in shadow image creation, but use the frame when asking for the size of the box shadow layer. What ends up happening is we have a 240x240 layer that is getting scaled again.
I refactored the shadow creation to just take a CGSize instead of a whole CALayer (which we had only used for its size anyway) so that we can be consistent with frame and bounds, and use bounds everywhere so that we only scale once.
Changelog: [iOS] [Fixed] - Fix cases where background color, filter, and background image were sized incorrectly if there was a scaling transform
Reviewed By: jorge-cab
Differential Revision: D69320213
fbshipit-source-id: a913e0df91d78ec9665752acefcae755ab607ac8
Summary:
Changelog: [Internal]
This is an automatically generated fixup patch to bring fbsource back into sync with
facebook/react on GitHub. Please land this patch as soon as possible, as the difference
reflected on here is already on GitHub and future changes may depend on these
changes!
<< DO NOT EDIT BELOW THIS LINE >>
diff-train-skip-merge
diff-train-source-id: 7e59b47d91fda2c6ef8946499d9e4457522a90d5
Generated by: https://www.internalfb.com/intern/sandcastle/job/4503601290447444/
GitHub Repo: facebook/react
Reviewed By: mofeiZ
Differential Revision: D69418289
fbshipit-source-id: 48636ba5bedfef7a09e0802f2a640be0417cdb7c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49284
All of the CMake library names in the "renderer" directory use "render" for the name, missing the last two letters of the directory name.
eye_twitch
I don't think fixing that should be breaking, since 3p libraries need to rely on the merged library anyway, so let's fix that and find/replace all these.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D69338892
fbshipit-source-id: d3b306ad0ea191728dfbacf9e2aaa12b00caa619
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49313
When the flag is enabled, we expect legacy native viewconfigs to add processor, where SVCs do not, and instead parse in native. Don't emit warnings in this case.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D69337802
fbshipit-source-id: f4c354c3b7b6ecbe4a8a72a37ea6d60dcc336b67
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49314
Add a flag which we will use to prefer Fabric CSS parser to ViewConfig processors. We will use this to experiment on iOS, where we are using Fabric props (until Props 2.0 for Android).
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D69337803
fbshipit-source-id: e3d4faeecbadb138c0a58f3fca6dba79eb7b13fa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49250
The TurboModule System decided to ignore the Null values when they are coming to JS. However, in iOS, null value can be mapped to `[NSNull null];` and this value is a valid value that can be used on the native side.
In the old architecture, when the user were sending a null value from JS to a native module, the Native side was receiving the value.
In the New Architecture, the value was stripped away.
This change allow us to handle the `null` value properly in the interop layer, to restore the usage of legacy modules in the New Arch.
I also tried with a more radical approach, but several tests were crashing because some modules do not know how to handle `NSNull`.
See discussion happening here: https://github.com/invertase/react-native-firebase/issues/8144#issuecomment-2548067344
## Changelog:
[iOS][Changed] - Properly handle `null` values coming from NativeModules.
Reviewed By: sammy-SC
Differential Revision: D69301396
fbshipit-source-id: be275185e2643092f6c3dc2481fe9381bbcf69e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49046
## Motivation
Modernising the RN codebase to allow for modern Flow tooling to process it.
## This diff
- Migrates files in `Libraries/PermissionsAndroid/*.js` and `Libraries/PushNotificationIOS/*.js` to use the `export` syntax.
- Updates deep-imports of these files to use `.default`
- Updates jest mocks
- Updates the current iteration of API snapshots (intended).
Changelog:
[General][Breaking] - Deep imports to modules inside `Libraries/PermissionsAndroid` and `Libraries/PushNotificationIOS` with `require` syntax has to be appended with '.default'.
Reviewed By: huntie
Differential Revision: D68832494
fbshipit-source-id: 4c44667856f5ad76b32a27a603a6538704c3192c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49292
changelog: [internal]
remove feature flag enableGranularShadowTreeStateReconciliation which was introduced in August 2023 and isn't rolled out.
Reviewed By: rshest
Differential Revision: D69393016
fbshipit-source-id: a1730f9811b1d8476d845e0303647b4d85f6b4a0
Summary:
Reland https://github.com/facebook/react-native/issues/48496 .
## Changelog:
[IOS] [FIXED] - Fabric: Fixes crash of dynamic color when light/dark mode changed
Pull Request resolved: https://github.com/facebook/react-native/pull/49265
Test Plan: RNTester -> PlatformColor example -> changed the dark/light mode in the system settings -> go back to App and pop and push the PlatformColor example, it would crash:
Reviewed By: javache
Differential Revision: D69309825
Pulled By: cipolleschi
fbshipit-source-id: 7a533a73ef343b071000388b653b2d1d0c54ae88
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49295
Motivated by https://github.com/facebook/react-native/issues/49287.
This improves on the less useful output of "fetch failed" currently. We expect failing to make a request to the dev server (made from the dev server!) to be a rare edge case, in which case we want to log as much info as possible.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D69395983
fbshipit-source-id: ee96d72ade5a887d190397c3b798a5b545152587
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49268
changelog: [internal]
ShadowView has three shared_ptr and copying those can be avoided here. Let's use std::move.
Reviewed By: NickGerleman
Differential Revision: D69303346
fbshipit-source-id: b13103369f6423610dd8f8ccb293e59f04acc5dc
Summary:
The performance of `_getFreeIndex` is quite terrible since the `timersID` array can get quite large when you spawn a lot of promises or timers. We profiled our application for 28 seconds on RN 0.71.11 and noticed that the `indexOf` into this array was consuming almost a second.
The hermes version that we are using has a pretty slow `indexOf` compared to other engines, and the static hermes will improve it by 12x but for the time being, this is a perf issue. https://github.com/facebook/hermes/pull/1447
We avoid having to use `indexOf` by maintaining a list of the free ids.
**Before - Samsung Galaxy A52 for 28 seconds of profiling**

**After - Samsung Galaxy A52 for 28 seconds of profiling**

## Changelog:
[INTERNAL] [FIXED] - Improve performance of _getFreeIndex
Pull Request resolved: https://github.com/facebook/react-native/pull/48925
Test Plan: - Tests pass, promises resolve and reject correctly, setTimeout works as expected
Reviewed By: javache
Differential Revision: D69059102
Pulled By: cipolleschi
fbshipit-source-id: d7de2c4adcf4dfc1d15e597e2a801e23c8d652aa
Summary:
Was going through some tests and I notice several files that use `RobolectricTestRunner` unnecessarily. This PR cleans that up.
## Changelog:
[INTERNAL] - Remove unnecessary RobolectricTestRunner usage
Pull Request resolved: https://github.com/facebook/react-native/pull/49290
Test Plan:
```
yarn test-android
```
Reviewed By: cipolleschi
Differential Revision: D69383948
Pulled By: cortinico
fbshipit-source-id: 6102319115240267ba83a086d03a850d1b7cdae5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49283
In this diff I'm introducing a new BuildConfig called UNSTABLE_ENABLE_MINIFY_LEGACY_ARCHITECTURE to determine if the new architecture is fully enabled into an Android app at build time, fully enabled means:
- no interop
- all view managers migrated to new API
- all native modules migrated to new API
- legacy architecture can be stripped
This BuildConfig is different from ReactNativeFeatureFlags.enableBridgelessArchitecture() because the latter is controlled at runtime, BuildConfig.UNSTABLE_ENABLE_MINIFY_LEGACY_ARCHITECTURE is used at the build system level and it can be accessed from proguard to optimize code that's unused when the app is fully running in the new architecture. Additionally we will use the BuildConfig to assert that some classes and methods are not loaded or executed.
changelog: [Android][Changed] Introduces BuildConfig.UNSTABLE_ENABLE_MINIFY_LEGACY_ARCHITECTURE to determine if the new architecture is fully enabled into an Android app
Reviewed By: cortinico
Differential Revision: D69206248
fbshipit-source-id: f60a059be8333d3051eb7d2efac79939a479f6f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49280
We were incorrectly consuming an `E` at the end of number tokens, even if not followed by a digit, which breaks dimension tokens where the unit starts with "E", like `em`. Follow the spec the right way:
https://www.w3.org/TR/css-syntax-3/#consume-number
> If the next 2 or 3 input code points are U+0045 LATIN CAPITAL LETTER E (E) or U+0065 LATIN SMALL LETTER E (e), optionally followed by U+002D HYPHEN-MINUS (-) or U+002B PLUS SIGN (+), followed by a digit, then...
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D69330975
fbshipit-source-id: a9bd5bceac9efbf02c1b7fb60659093774bb7228
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49279
I ended up using this same pattern for filter parsing where the logic betweeen functions is very similar. Let's deduplicate the logic for transform parsing a bit. This also separates `rotate()` and `rotateZ()` types, to be handled the same at a different layer.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D69326443
fbshipit-source-id: 9bf910c6d4e07748ff032433167576f9d58cd8d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49276
This diff replaces the remaining `React$` global types in the codebase, in preparation for their removal in Flow.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D69322418
fbshipit-source-id: 058a2489ce8e6bf59df2ec4e61e9708f63561671
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49271
This error is somewhat expected, so causing the red box error popup is a bit too disruptive. Flip it to a no-crash exception.
Changelog: [Internal]
Reviewed By: Abbondanzo
Differential Revision: D69125274
fbshipit-source-id: 0dc7ac59ac8637bdabde25bd8886b1aebf175395
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49277
Replaces the `-1` magic number representing unset children with a named constant
Changelog: [Internal]
Reviewed By: zeyap
Differential Revision: D69324509
fbshipit-source-id: 64fb6c920a7715f5d15d3955564a8bf2b6ce404a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49274
In this diff I'm updating all the non-codegen ViewManagerInterfaces to extend ViewManagerWithGeneratedInterface to make it consistent with codenerated ViewManagerInterfaces
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D69206247
fbshipit-source-id: 6a577d9ee7410be990a03e78847333b61b429e88
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49261
Update the version of Jest used in React Native and Metro's own tests from `^29.6.3` to `^29.7.0`
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D69307514
fbshipit-source-id: 686935ed4ba1334d445217fd2f8a303b774b6c4a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49198
changelog: [internal]
The work done on the main thread should scale with what is on the screen. React Native shouldn’t block the main thread for off screen elements that do not affect what is shown to the end user. When React schedules a commit, only views needed to achieve a screen full of content should be materialised and added to the host platform’s view hierarchy.
With Fabric View Culling, views that do not contribute pixels to the screen will not materialize and updates to them will be skipped. React Native will focus system resources on what is visible to the end user.
Fabric View Culling maximises benefits from view recycling. Each UI element such as text, image, or video is recycled individually. As soon as an item goes off screen, it can be reused anywhere in the UI and pieced together with other items to create new UI elements. Such recycling reduces the need of having multiple view types and improves memory usage and scroll performance.
In the example bellow, view B will not be mounted because the user can't see it.
{F1974949953}
The difference in number of allocated views:
Please note, the screenshots below are from Xcode View Hierarchy debugger. To show how many views are allocated in memory, I disabled [removeClippedSubviews](https://reactnative.dev/docs/scrollview#removeclippedsubviews) flag globally.
|Before|After:
| {F1974949979}| {F1974949981}
# Disclaimer, this is not a complete implementation
This implementation is not complete and it is missing to handle edge cases.
Things that are missing:
- Transform style is not taken into account.
- removeClippedSubviews is not respected. Fabric View Culling happens unconditionally for every scroll view.
- Fabric View Culling does not respect when ScrollView has overflow set to visible.
- Fabric View Culling is only performant enough on iOS.
- [enableSynchronousStateUpdates](https://github.com/facebook/react-native/blob/main/packages/react-native/scripts/featureflags/ReactNativeFeatureFlags.config.js#L248) must be enabled for Fabric View Culling to work correctly.
Reviewed By: javache
Differential Revision: D63458372
fbshipit-source-id: c93ec434081f2be8a446212e2c0681f8ae4e90f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49197
changelog: [internal]
Adds new method to LayoutMetrics that calculates frame adjusted for overflow inset.
For example, for the following view hierarchy. it would produce a frame that would fully contain view A and view B.
```
┌─────────────┐
│<View A /> │
│ ┌───────┴─────┐
└─────┤<View B /> │
│ │
└─────────────┘
```
See tests for more details
Reviewed By: javache, lenaic
Differential Revision: D68775683
fbshipit-source-id: b8f7c42cfca7dba8dcae75cae5e6944bd1082957
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49258
Updates dependency resolution in `yarn build-types` to happen after the `translateFlowToFlowDef` step. This means that we prune all non-type imports, massively reducing the input files of the program when building types only.
Changelog: [Internal]
Reviewed By: j-piasecki
Differential Revision: D69302812
fbshipit-source-id: aa80bea17cb584b747cb31c003e87fe00afd1e16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49257
Adds minimal dependency resolution to `yarn build-types`.
- This enables us to opt in React Native APIs by entry point, with the build script resolving all necessary dependencies. Improves correctness and removes concern of globbing paths manually.
Other notes:
- The `ActionSheetIOS.js` entry point is temporarily disabled as input; needs further work.
Changelog: [Internal]
Reviewed By: j-piasecki
Differential Revision: D69255015
fbshipit-source-id: 2d99c014b50e41e4695549f46ca874a2b546f545
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49241
In auditing differences between `InteractionManager` and `InteractionManagerStub` (used to evaluate to entirely remove the former all together), I noticed a behavioral disparity with how errors are handled.
In `InteractionManager`, the promise that's returned is never rejected, whereas `InteractionManagerStub` propagates errors by rejecting the promise that's returned. This changes `InteractionManagerStub` to behave like `InteractionManager` for the purpose of comparing apples-to-apples.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D69275495
fbshipit-source-id: 05439a0cadc1f76b34a3f1457f7db31d6bda2a90
Summary:
Fantom was disabling Metro hierarchical lookup in all cases when `JS_DIR` is set. The intention is that `node_modules` folders other than the configured `JS_DIR/public/node_modules` are not used.
However, this leads to incorrect resolution where a transitive dependency is not hoisted. If the origin of the resolution is already inside `node_modules`, we must perform a hierarchical lookup to avoid picking up just whichever version happens to be hoisted to `node_modules` root.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D69303559
fbshipit-source-id: 12068fb0bebb8c2f81b64c23b952a623cb6fd792
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49252
Changelog: [internal]
This adds a Fantom test placeholder for LogBox, which shows what type of tests we could be writing for this.
It also adds a few ids in LogBox components so we can inspect them in tests and make assertions on them.
Reviewed By: javache
Differential Revision: D69301572
fbshipit-source-id: 89a332a47c300c1dc18937cd91206ce6d820b6aa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49251
Changelog: [internal]
Components like `AppContainer` require passing the rootTag as a prop, but we don't have access to it from Fantom unless we render something in the root and access it via the RootTagContext. This exposes the rootTag of the Root as a method so we can use it in initial render too.
Reviewed By: javache
Differential Revision: D69301571
fbshipit-source-id: 429fb56d937d3dffeb3c17a70d136ba4925ece8e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49254
Changelog: [internal]
This is just a convenience method to do:
```
Fantom.dispatchNativeEvent(node, 'click');
```
Instead of:
```
runOnUIThread(() => {
enqueueNativeEvent(node, 'click');
});
runWorkLoop();
```
Which is too verbose and people rarely need this level of granularity in tests.
Note that, in Fabric, we have methods called `dispatchEvent` that don't match 1:1 with this API. In that case, `dispatchEvent` is more aligned with Fantom's `enqueueNativeEvent`.
Reviewed By: javache
Differential Revision: D69302382
fbshipit-source-id: 6f71a5ace11c81f551df2c2837881dbc6f48e7ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49253
Changelog: [internal]
Renaming this low level method as `enqueue` is more accurate in this case than `dispatch`, which is misleading because it actually doesn't dispatch it to JS.
We should also rename this in Fabric, but that's a larger and breaking change, so just making the change in Fantom for now. This is a trade-off between convenience/ergonomics of the testing API vs. alignment with the internal nomenclature. In this case we favor the first.
Reviewed By: javache
Differential Revision: D69302383
fbshipit-source-id: 7e163920ace709503367bf68baab5e9f2bf8ae3f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49231
Those public modifier have no meaning as the class is internal. I'm removing them.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D69252048
fbshipit-source-id: b51e5ac20338a01291d6cd04ee4c990cc8a6a755
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49229
This interface was converted to Kotlin, but the single method should have been converted to a `val`.
People kotlin consumers could call ReactOverflowView.overflow; now they need to call getOverflow().
Changelog:
[Internal] [Changed] - Undo a breaking change on ReactOverflowView
Reviewed By: NickGerleman
Differential Revision: D69250226
fbshipit-source-id: 5c7cca8c83f5c76a9cc1d254f8aa51409150c356
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49233
I'm converting the function inside ReactPointerEventsView from `fun` to `val`.
This Kotlin conversion resulted in a breakign change for Kotlin consumer which I believe can be prevented
if we do this change instead.
Changelog:
[Internal] [Changed] -
Reviewed By: alanleedev
Differential Revision: D69252562
fbshipit-source-id: b277c6720f3156ed532bf5f2253d54cd72e38050
Summary:
I wanted to test exclusion of .d.ts files in https://github.com/facebook/react-native/pull/49227, but it also has node_modules so it will not test that condition correctly.
## Changelog:
[INTERNAL] [FIXED] - Fix exclude .d.ts test in GenerateCodegenSchemaTaskTest
Pull Request resolved: https://github.com/facebook/react-native/pull/49238
Test Plan: Run tests
Reviewed By: cipolleschi
Differential Revision: D69291695
Pulled By: cortinico
fbshipit-source-id: 46b9367f3466b9cd49232a0565e5778a06b43990
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49216
Should be able to replace `processTransformOrigin`.
As part of this, I discovered `processTransformOrigin` has a bug where it does not correctly support `center left` or `center right` syntax since it assumes first occurrence of `center` is for the horizontal
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D69204030
fbshipit-source-id: 8001ef4f0b54fcbe93855920260e077b89669f6d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49189
Allow parsing the set of currently supported transform functions, and lists of them, using `CSSTranformFunction` (which may decompose to e.g. `CSSScaleX`), and `CSSTransformList`.
A bit more duplication than I would like here, but a lot of these have subtle differences.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D69153280
fbshipit-source-id: ef8e93c8a49a7f1b98bd7c57614aa1c84417120d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49230
Those public modifier have no meaning as the class is internal. I'm removing them.
Changelog:
[Internal] [Changed] -
Reviewed By: tdn120
Differential Revision: D69251378
fbshipit-source-id: 4c3747510d18330dcdb8a0798e92736c4ab65a03
Summary:
While triaging issues in the React Native repository, we face two major challenges:
- Missing Issues: The large volume of issues makes it difficult to ensure that none are overlooked.
- Ownership: There is no structured process to determine who should handle which issue.
To address these challenges, we are setting up this action.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[GENERAL] [ADDED] - Added a new workflow to monitor new issue in repo.
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Here we are using this github action: https://github.com/react-native-community/repo-monitor to monitor new issues and then notify it on specific discord server to notify someone.
Currently this action runs every 6 hours.
Requirements:
- We need following inputs to make this workflow run:
- `DISCORD_WEBHOOK_URL` to be added in secrets [Needed for posting message in specific channels]
- `role_id`: To notify a group.
Pull Request resolved: https://github.com/facebook/react-native/pull/49225
Test Plan: NA
Reviewed By: cipolleschi
Differential Revision: D69254130
Pulled By: cortinico
fbshipit-source-id: 43a57f8f3bf161042a9432d02f292896ea8f7622
Summary:
In some projects we have conventions of using .tsx extension even for files without react components, we had issues where codegen wasn't updated properly.
I debugged the files included in a large project and made some improvements:
- Include tsx and jsx files
- exclude nested node_modules
- exclude ts type def files
## Changelog:
[ANDROID] [FIXED] - Improve input files for codegen gradle task
Pull Request resolved: https://github.com/facebook/react-native/pull/49227
Test Plan: Tested in a large app using codegen. I inspected the files that are included in the task inputs and made sure it works with first party and 3rd party modules.
Reviewed By: cipolleschi
Differential Revision: D69254204
Pulled By: cortinico
fbshipit-source-id: 368408e9719e9b5c9839dd873430b86ae4a062c7
Summary:
Just a minor typo in the changelog for 0.78
## Changelog:
[Internal] [Changed] -
Pull Request resolved: https://github.com/facebook/react-native/pull/49232
Test Plan: ¯\\_(ツ)_/¯
Reviewed By: cipolleschi
Differential Revision: D69252846
Pulled By: cortinico
fbshipit-source-id: 97010601482199c87d7a9da06e5e32a4bfa8a552
Summary:
`loadSourceForBridge` is broken after we refactor the appdelegate. So let's add it back.
## Changelog:
[IOS] [FIXED] - Added custom load js block in bridge mode
Pull Request resolved: https://github.com/facebook/react-native/pull/48845
Test Plan: Custom Appdelegate's `loadSourceForBridge` can be called in bridge mode.
Reviewed By: robhogan
Differential Revision: D68832046
Pulled By: cipolleschi
fbshipit-source-id: dcea791e6d8243fdb2f45a33af175aee1a4e1223
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49224
Refactor / quality pass.
- Remove `micromatch`, replace with glob ignores.
- Move and simplify platfom-specific file logic: mutate `files` as a single `Set`, reduce iterations.
- This is reconfigured so that the input file path globs need only match `*.js` sources.
- Introduce `debug` logs and expose convenience `--debug` script flag.
- Move output error detection into inner function implementation.
Changelog: [Internal]
Metro changelog: Internal
Reviewed By: j-piasecki
Differential Revision: D69240543
fbshipit-source-id: c2faef8212a2995936362b3d33d189c405bd879d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49222
Changelog: [internal]
This implements `test.only` in Fantom benchmarks, so we can focus on a specific case to speed up iteration.
Reviewed By: sammy-SC
Differential Revision: D69241220
fbshipit-source-id: 42b02fcb4d693988da4fa15a0c6bd7e90e473b9f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49223
Changelog: [internal]
Renames `suite.add()` as `suite.test()` for symmetry with Jest.
We'll also allow `test.only` in a following change for quick iteration.
Reviewed By: rshest
Differential Revision: D69241221
fbshipit-source-id: d141f80dc0c8e51b419ce233bca68bf0755fd356
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49212
Currently, developers can't use `popup-menu-android` at all because the Gradle file we publish is referencing
internal machinery.
I'm adding a pre-publish script that manipulates the Gradle. This is the easiest solution without having to do
crazy setup inside RNGP or having duplicated version codes around in the monorepo.
Fixes https://github.com/facebook/react-native/issues/49112
Changelog:
[Android] [Fixed] - Fix react-native/popup-menu-android not building for 3rd party developers
Reviewed By: cipolleschi
Differential Revision: D69192874
fbshipit-source-id: 9f9e8a0a6e76308e598a09f4c70dbc659c238b00
Summary:
Hey!
Since new architecture introduced View Flattening on iOS, props responsible for disabling this feature on specific views should be defined in cross platform interface.
Reference: https://github.com/reactwg/react-native-new-architecture/discussions/110
## Changelog:
[GENERAL] [CHANGED] - move view flattening props to cross platform type interface
Pull Request resolved: https://github.com/facebook/react-native/pull/49220
Test Plan: N/A
Reviewed By: fabriziocucci
Differential Revision: D69239454
Pulled By: javache
fbshipit-source-id: a89cb9fbaec63bbcb7691df067d5d3a375a8a66e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49213
Update the version of Jest used in React Native and Metro's own tests from `^29.6.3` to `^29.7.0`
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D69188217
fbshipit-source-id: 0748db5428e422c048454b7d129cbdd4dab6d687
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49146
Runtime Reference ShadowNode Update is enabled by default and no longer referenced in the RN holdout. This diff:
- removes the feature flag
- removes all references to the feature flag, enabling it
- updates the unit test for RSNRU
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D69061234
fbshipit-source-id: 0dab0b5cae99e83297f34645dee58ae9b3c0dc5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49211
Add more control over view recycling behavior by splitting out each component that currently supports it.
Changelog:[Android][Added] Feature flags for recycling View, Text components separately
Reviewed By: sammy-SC, mdvacca
Differential Revision: D69190841
fbshipit-source-id: 6d85fee7103bf928e4f5bf6946bab3ff4cae4053
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49184
D65645985 shipped a refactor to `Animated`, so that it would use a custom `useAnimatedPropsMemo` instead of `useMemo`. This significantly improved update performance by no longer invalidating the `AnimatedProps` on effectively every update to `Animated` components.
However, this was measured to increase memory usage. After a few experiments, we identified that use of the in-band state update was responsible for the memory regression. While this requires further root cause investigation, this diff attempts to mitigate the memory regression.
This diff introduces a feature flag that enables an implementation that minimizes duplicated work, such as unnecessarily computing `compositeKey` or creating new instances of `AnimatedProps`. In addition, this implementation strives to do so without significantly degrading when an update is interrupted by a concurrent update.
Changelog:
[General][Changed] - Introduced a feature flag to test an optimization in `Animated` to reduce memory usage.
Reviewed By: rickhanlonii
Differential Revision: D69135223
fbshipit-source-id: a2699a314625e7570698bc41455b139711cfd7e3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49141
This diff extends ReactNativeFeatureFlags to support prereleaseChannels, the goal is to be able to configure what release channel each feature flag will be enabled / disabled
changelog: [internal] internal
Reviewed By: rubennorte
Differential Revision: D68583324
fbshipit-source-id: 09fde8511dcf5dff63821f15afe0a2530a0845fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49183
The feature has been released to all for quite some time now and the holdout group has finally been unlinked. This removes all references to the feature flag and a few indicators that the feature is enabled/disabled from RNTester
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D69146787
fbshipit-source-id: 8a7f01016a715e61541910630d8c3ceb84ec5c82
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49203
There are some leftover references to CircleCI in some comments. Let's remove it.
## Changelog:
[Internal] - Remove remaining CircleCI references from comments
Reviewed By: huntie
Differential Revision: D69182573
fbshipit-source-id: ea6cfe98422527d094ad4410cdd2a1a87dd61ddb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49202
There are some leftover references to CircleCI in these scripts. Let's remove it.
## Changelog:
[Internal] - Remove remaining CircleCI references from npm-utils scripts
Reviewed By: huntie
Differential Revision: D69182550
fbshipit-source-id: d8707abba3e01c26c8d7170522333dcbc039c19d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49201
There are some leftover references to CircleCI in these scripts. Let's remove it.
## Changelog:
[Internal] - Remove remaining CircleCI references from CI scripts
Reviewed By: huntie
Differential Revision: D69182535
fbshipit-source-id: 4e825b65b5f5ca6ce16f5c7ac2f79088cf2d1ace
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49200
Changelog: [Internal]
Update to `toBeCalled` and `toBeCalledTimes` aliases - forward them using prototype so number of frames matches when thrown.
Reviewed By: rubennorte
Differential Revision: D69182276
fbshipit-source-id: c20469959dc2e0f5c3686c90e27cd80117ad5fb7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49205
Changelog: [Internal]
Updates how name shadowing works for the TS type generation prototype to align more with how Flow does it - `.js.flow` files shadow every other file with the same name, then `.js` file (if exists) is treated as the common interface.
The script still uses `.flow.js` for common interface, which will be changed in another diff.
Reviewed By: huntie
Differential Revision: D68958772
fbshipit-source-id: caa390711f2bcd7666d875703fc316d874500a0d
Summary:
`yarn install` is failing sporadically with a 500. This should mitigate this flakyness.
## Changelog:
[INTERNAL] -
Pull Request resolved: https://github.com/facebook/react-native/pull/49199
Test Plan: CI
Reviewed By: rubennorte
Differential Revision: D69180877
Pulled By: cortinico
fbshipit-source-id: 5276e2744c73df896b4bcadfecf3db61d57d198c
Summary:
One of the steps we perform when doing a release is to run `npm view react-native` to verify that the release has been published and it is available with the right tag.
As of today, we check this manually.
This change aims at automating this check so that we don't have to do it manually ourselves.
## Changelog:
[Internal] - Releases: automate the npm view check
Pull Request resolved: https://github.com/facebook/react-native/pull/49164
Test Plan:
Created a veriftyReleaseOnNPM-tests.js jest test to verify that the script works fine.
<img width="667" alt="Screenshot 2025-02-04 at 15 18 24" src="https://github.com/user-attachments/assets/cf08155f-80da-4e15-a922-5c16f3fd806e" />
Reviewed By: cortinico
Differential Revision: D69118622
Pulled By: cipolleschi
fbshipit-source-id: a8d40cd2fcb164d8f7174de680b340510f3e8551
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49192
Changelog: [internal]
We refactored the public API of Fantom benchmarks in https://github.com/facebook/react-native/pull/49014 but that refactor broke test only mode, as we started overriding the options after setting them. This fixes that.
Reviewed By: javache
Differential Revision: D69176983
fbshipit-source-id: 9afc2d2f27fb2ee0aa452d4b02c28531acf40b8e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49188
This allows creating lists of a compound data type, storing each element as a variant of the possible types, instead of as the specified type.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D69142157
fbshipit-source-id: d742d81a6517b24f24827727cd777550f2ad274f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49187
`tolower` is not `constexpr`. Share some quick utilities for char to lowercase, and case insensitive comparision that does not create new string.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D69134770
fbshipit-source-id: 57a84f2d1a441e5a4c07c0db96cb6c133770fb51
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49186
Next up for transforms, and for some future cases, it is convenient to be able to export a single marker type like `CSSTransform`, that can expand to a variant of multiple possible types of different shape (e.g. `CSSMatrix3D` vs `CSSScale`).
It is also best (for code size) to only have a single representation of compound types (e.g. `<CSSLength, CSSPercentage>` generates a separate copy of code compared to `<CSSPercentage, CSSLength>`).
This diff introduces `CSSCompoundDataTypes` which allows composing types, which are then flattened out to discrete types during parsing. For simplicity, `CSSCompoundDataType` cannot currently be nested inside of other `CSSCompoundDataType`, though this could be added in the future.
```
/**
* Marker for the <length-percentage> data type
* https://drafts.csswg.org/css-values/#mixed-percentages
*/
using CSSLengthPercentage = CSSCompoundDataType<CSSLength, CSSPercentage>;
```
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D69089416
fbshipit-source-id: 8645009f06eb14b1ac4437a4fc4dd6b9ad3f88a2
Summary:
This centralizes the invocation of yarn install to be via the `actions/yarn-install`.
It will make it easier to add a retry if we want for all the `yarn install` steps in all the workflows.
## Changelog:
[INTERNAL] -
Pull Request resolved: https://github.com/facebook/react-native/pull/49174
Test Plan: CI
Reviewed By: NickGerleman
Differential Revision: D69121525
Pulled By: cortinico
fbshipit-source-id: 135da2e172cdf95b2a0ef8fd3d25996ab9317167
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49155
This does some code cleanup for CSS keywords to reduce boilerplate, duplication, better isolate namespace, fix a typo, and ensure we get a warning (unused variable) if we miss handling a defined keyword.
We technically don't need `CSSKeyword` at all anymore, and don't need to overlay each keywords values to be the same, though having a pattern where each keyword set uses ordinal values from CSSKeyword forces folks to look and add the enum to the list, and include the header defining the data types for keyword sets, instead of each set looking a little magic.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D69083181
fbshipit-source-id: b2764e87c2a127d73f816327c4edd45151ea8d82
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49151
This diff is... maybe an argument against a global list of interned keywords (it works better in some other contexts though), and this structure is likely to change later when we reintroduce what was previously `CSSPropertyDescriptor` (a list of allowed keywords per property).
But... we're going to roll with this for now to replace the ViewConfig processor (which string splits) in the most over-engineered way possible.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D68851566
fbshipit-source-id: 71022f051b112adc03bd182d433e3d890e6023f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49152
For parsing a variable number of whitespace separated data types.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D68849561
fbshipit-source-id: be3314990d9e7c202c02deba463d79e50985c0b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48991
This adds support for parsing the `<shadow>` data type. In combination with `CSSCommaSeparatedList`, we can now parse box shadow expressions.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D68744811
fbshipit-source-id: bac7be0faf8cd8eee04f21651180151edeef7294
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48987
Adds a data type parser for a variable number of values of a given single data type (at least 1).
E.g. `CSSCommaSeparatedList<CSSShadow>` will represent the syntax of `<shadow>#` (ie the value produced by box-shadow).
Changelog: [internal]
Reviewed By: lenaic
Differential Revision: D68738165
fbshipit-source-id: 6dd17b3da24b1c24808e49834a29a237c0115fab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48986
This adds a new `consume()` function to data type parsers which passes a raw parser. This can be used for types which are compounds of other data types, where we may want to accept more than the first token.
This will be used for shadow parsing, but also fixes a hypothetical future bug with ratios. E.g. `calc(foo) / calc(bar)` may be a valid ratio, not starting with a token. We instead just want to try to parse a number data type from the stream.
The form of parsing a preserved token + rest is removed, with the assumption that anything parsing more than a single token should use compound parsing.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D68735370
fbshipit-source-id: 660e0b4a496136c8a559f4ba47bc1bd8d17aa116
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48985
This reverts some of the behavior I added in D68357624, since peeking a component value is non-obviously more expensive than manually copying the parser, and needing to peek will be a pain for flat lists of values (like for box-shadow).
Changelog: [internal]
Reviewed By: lenaic
Differential Revision: D68733518
fbshipit-source-id: 7b4a061d1649019274441ae0e82609f771dd2916
Summary:
Support distributing Expo Dev Clients to TestFlight. Expo Dev Clients are like custom versions of Expo Go that you can use to connect to a dev server or test remote updates with. Currently they can only be distributed through AdHoc provisioning because Apple rejects the use of private symbols. The symbols in question are used for simulator builds to support reloading when the "R" key is pressed (amongst other features). This is not imperative since there are a number of systems for reloading the app such as pressing R in the CLI window, but it's also not relevant to a physical phone where there is no keyboard.
## Changelog:
[IOS] [FIXED] - Remove private symbols for non-simulator and non-catalyst builds.
<!-- 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/49154
Test Plan:
- I built an deployed an app with this patch enabled to TestFlight to ensure the submission wouldn't fail. This can be reproduced locally with:
- `npx create-expo`
- Add the patch (ensure it's set with a `prepare` script).
- Following `eas.json`:
```json
{
"cli": {
"version": ">= 14.7.0",
"appVersionSource": "remote"
},
"build": {
"development": {
"developmentClient": true,
"resourceClass": "large",
"autoIncrement": true
},
"production": {
"autoIncrement": true
}
},
"submit": {
"production": {},
"development": {}
}
}
```
- Then building and deploying to TestFlight: `npx eas-cli@latest build -p ios -s --profile development`
Reviewed By: huntie
Differential Revision: D69106388
Pulled By: cipolleschi
fbshipit-source-id: 773a897ff5061929367b72188f06a08213c7dd46
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49161
Avoid special strings, and default to null to mean undefined or unknown. This save us from bridging an unnecessary string but also makes the fallback name for logging network requests clearer.
Changelog: [Internal]
Reviewed By: bgirard
Differential Revision: D69058211
fbshipit-source-id: d83f424e0c2c23842554a8e4e616cad39719f311
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49125
Changelog: [internal]
This adds support for taking JS memory heap snapshots from Fantom tests via `Fantom.saveJSMemoryHeapSnapshot`. This can be used in one-off tests to do memory analysis and determine the existence of leaks:
```
// Warm up
Fantom.saveJSMemoryHeapSnapshot('/path/to/my/1.heapsnapshot');
// Do work
Fantom.saveJSMemoryHeapSnapshot('/path/to/my/2.heapsnapshot');
// Clean up
Fantom.saveJSMemoryHeapSnapshot('/path/to/my/3.heapsnapshot');
```
Load these snapshots in Chrome and select "Objects allocated between 1 and 2" in the dropdown to see the potentially leaked objects.
In the future we could introduce additional utilities to analyze the snapshots and do the detection automatically, e.g.:
```
// Warm up
const baseline = Fantom.takeJSMemoryHeapSnapshot();
// Do work
const before = Fantom.takeJSMemoryHeapSnapshot();
// Clean up
const after = Fantom.takeJSMemoryHeapSnapshot();
const leaks = findMemoryLeaks(baseline, before, after);
expect(leaks.sizeKB()).toBeLessThan(THRESHOLD);
```
Reviewed By: rshest
Differential Revision: D68953788
fbshipit-source-id: 6b3899297837c582a7b7235909d59b3e1631913d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49140
Similar to the change made in `useAnimatedProps`, except for `useAnimatedPropsMemo`. (This is just split out to make the changes easier to review.)
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D69058338
fbshipit-source-id: 033853673d8fe1442b37bb0c0adc7cb22557c334
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49143
Within the implementation of Animated, the `allowlist` value passed into `unstable_createAnimatedComponent` and `useAnimatedProps` is stable, meaning that it cannot change from commit to commit. However, this semantic is not codified because `allowlist` is a prop.
This refactors `useAnimatedProps` to be created by a new `createAnimatedPropsHook` function which accepts an `allowlist` argument, codifying that its value is stable for the lifetime of the hook returned.
This permits React to avoid checking whether `allowlist` has changed from commit to commit.
For now, I've left `useAnimatedProps` as a deprecated module that returns a hook with an empty `allowlist`.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D69058336
fbshipit-source-id: dbcf4ca4e389f3682864a9794eacbe0af23659db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49121
This change removes the scripts/circleci folder and the last poll-maven script which was not used.
## Changelog:
[Internal] - Remove the circleci folder script
Reviewed By: cortinico, huntie
Differential Revision: D69047603
fbshipit-source-id: a4f1f100d71d792edf42c8d4cb6a0b8d8e7e5260
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49123
Previously, we used to have CI workflows scripts in a `react-native/scripts/circleci` folder.
Now that we are not using CircleCI anymore, we move those scripts to the `.github/workflow-scripts` folder.
## Changelog:
[Internal] - Move ci scripts to the `.github/workflow-scripts` folder
Reviewed By: cortinico, huntie
Differential Revision: D69047581
fbshipit-source-id: 6a5d8525e526cc7521d42e2be9530deb09914fdc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49122
This change updates the Release testing and the release scripts by removing any reference to CircleCI
## Changelog:
[Internal] - Remove CircleCI references from Release and Release testing scripts
Reviewed By: cortinico, huntie
Differential Revision: D69047479
fbshipit-source-id: 14a394b879c03cd81a8d043036c43839a38602c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49119
This change removes the .circleci folder and the workflow that we run on CircleCI
## Changelog:
[Internal] - Remove CircleCI config
Reviewed By: cortinico, huntie
Differential Revision: D69047483
fbshipit-source-id: 0020a4ff69d035e939e01079059ba2743aee55fe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49118
We finished the migration away from CircleCI, so we are cleaning up the codebase.
This change updates references to CircleCI from gradle.
## Changelog:
[Internal] - Remove references from CircleCI in RNGP
Reviewed By: cortinico
Differential Revision: D69047484
fbshipit-source-id: 4ab40be62e6769eb3a8f65136464eed6628d47a4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49101
Changelog: [internal]
We can move this out of the deprecated directory. Also added a `.npmignore` entry so this won't be published to npm with the package.
Reviewed By: lenaic
Differential Revision: D68896208
fbshipit-source-id: ec85236aeeabdc9abcd870f0f4c1322eeb3cc659
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49100
Changelog: [internal]
This API isn't part of the DOM standard so can be moved out.
Reviewed By: huntie
Differential Revision: D68896484
fbshipit-source-id: 5d275beb909ce5c5ce0eddb6c6e04cf7491aa1cb
Summary:
Fixes a `ConcurrentModificationException` when iterating over `TextWatcher` `mListeners` array.
If you open Android open source code (`TextView` class), then we can see that Android iterates with `for/n` loop (not `for/:`):
```java
void sendAfterTextChanged(Editable text) {
if (mListeners != null) {
final ArrayList<TextWatcher> list = mListeners;
final int count = list.size();
for (int i = 0; i < count; i++) {
list.get(i).afterTextChanged(text);
}
}
notifyListeningManagersAfterTextChanged();
hideErrorIfUnchanged();
}
```
<hr>
We can catch the `ConcurrentModificationException` with old code, when for example we have 3 listeners:
- 0 is `EmojiTextWatcher` (seems like it's added by OS);
- 1 is `OnlyChangeIfRequiredMaskedTextChangedListener` (added by `react-native-text-input-mask`);
- 2 is a listener that attached by `react-native-keyboard-controller`.
On every afterTextChanged [input-mask-android](https://github.com/RedMadRobot/input-mask-android/tree/df452edc0c52a37e5082adcfc3d05d77b5aa34e8) [removes](https://github.com/RedMadRobot/input-mask-android/blob/df452edc0c52a37e5082adcfc3d05d77b5aa34e8/inputmask/src/main/kotlin/com/redmadrobot/inputmask/MaskedTextChangedListener.kt#L212) the listener and [adds](https://github.com/RedMadRobot/input-mask-android/blob/df452edc0c52a37e5082adcfc3d05d77b5aa34e8/inputmask/src/main/kotlin/com/redmadrobot/inputmask/MaskedTextChangedListener.kt#L231) it back.
The oversimplified version of the code can be next:
```java
public class MyClass {
public static void main(String args[]) {
ArrayList<Integer> mListeners = new ArrayList<>();
mListeners.add(0);
mListeners.add(1);
mListeners.add(2);
Iterator<Integer> iterator = mListeners.iterator();
while (iterator.hasNext()) {
Integer listener = iterator.next();
// Check if the listener is equal to 1
// 1 is OnlyChangeIfRequiredMaskedTextChangedListener and we simulate the behavior of this class
if (listener == 1) {
int i = mListeners.indexOf(listener);
if (i >= 0) {
mListeners.remove(i);
}
// Add the removed element at the end
mListeners.add(listener);
}
}
// Print the modified list
System.out.println(mListeners);
}
}
```
Key points are:
- if we have only [0, 1] listener, then it works well and `ConcurrentModificationException` will not be thrown, because we modify last element;
- if we have `[0, 1, 2]` then exception will be thrown.
So in this PR I decided to re-work code to match what Android has. With `for/n` approach `ConcurrentModificationException` will not be thrown, because we don't check array immutability in this case.
More information also can be found here: https://github.com/kirillzyusko/react-native-keyboard-controller/issues/324
## Changelog:
[ANDROID] [CHANGED] - avoid `ConcurrentModificationException` when iterating over `mListeners` `TextWatcher` array
Pull Request resolved: https://github.com/facebook/react-native/pull/49109
Reviewed By: cortinico
Differential Revision: D69050984
Pulled By: javache
fbshipit-source-id: 9c6a7a428467fa5e546d70549dfcc91d6b2e58d2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49132
Follows D68780147 and D68953084. We're able to safely remove this API by relocating the implementation into the one dependent internal test call site.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D69049203
fbshipit-source-id: 82c4b15d7f6736aed21171eeec1c197d2f34b33e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49072
We have instance of apps crashing when enabling the New Architecture because of the TurboModule interop layer.
What's happening is that when the module is loaded, the TM Interop Layer tries to parse the method definition to expose them in JS. However, for some libraries in the Legacy Architecture, it is possible to define a method in Objective-C and to define a different signature in Swift.
For example, the [`RNBluetoothClassic` library](https://github.com/kenjdavidson/react-native-bluetooth-classic) defines a selector in objective-c which [has the signature](https://github.com/kenjdavidson/react-native-bluetooth-classic/blob/main/ios/RNBluetoothClassic.m#L134-L136)
```
RCT_EXTERN_METHOD(available: (NSString *)deviceId
resolver: (RCTPromiseResolveBlock)resolve
rejecter: (RCTPromiseRejectBlock)reject)
```
And the method is inmplemented in Swift with [the signature](https://github.com/kenjdavidson/react-native-bluetooth-classic/blob/main/ios/RNBluetoothClassic.swift#L502-L505):
```
func availableFromDevice(
_ deviceId: String,
resolver resolve: RCTPromiseResolveBlock,
rejecter reject: RCTPromiseRejectBlock
)
```
When the TurboModule interop layer tries to parse the method, it receives the `accept:resolver:rejecter:` signature, but that signature is not actually defined in as a method in the module instance, and it crashes.
This crash was not happening in the Old Architecture, which was handling this case gracefully. Notice that the specific method from the example is not working in the Old Architecture either. However, the app is not crashing in the old architecture.
This change adds the same graceful behaviors plus it adds a warning in development to notify the developer about which methods couldn't be found in the interface.
Fixes:
- https://github.com/facebook/react-native/issues/47587
- https://github.com/facebook/react-native/issues/48065
## Changelog:
[iOS][Fixed] - Avoid crashing the app when the InteropLayer can't find some methods in the native implementation.
Reviewed By: javache
Differential Revision: D68901734
fbshipit-source-id: 844d1bf29423d5c601b583540e86d57dfffd1428
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49041
Prevent the class of issues seen in D68797482 by making `#if FOO` where `FOO` is not defined an error.
Changelog: [Internal]
Reviewed By: NickGerleman, sammy-SC
Differential Revision: D68824244
fbshipit-source-id: 1291c5f2f84ecb023ba76a015716cc7c9ae0f89e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49127
These tests are marked as noexcept, but they can indeed throw exceptions: they trigger synchronous commits, which may cause exceptions in the mounting layer.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D69049587
fbshipit-source-id: 02c6187c8d0e043c9840aad9c9e4d27866898b4a
Summary:
As pointed out by RyanCommits the ReactNativeFactory PR removed `enableFixForViewCommandRace` feature flag by mistake. Reference: https://github.com/facebook/react-native/pull/46298/files
This PR re-adds the feature flag.
## Changelog:
[IOS] [FIXED] - Re-enable enableFixForViewCommandRace feature flag
Pull Request resolved: https://github.com/facebook/react-native/pull/49126
Test Plan: Not needed, the feature flag was there before refactor.
Reviewed By: huntie
Differential Revision: D69049668
Pulled By: cipolleschi
fbshipit-source-id: b7bf382c76878e72619145283fa8cc2c1046b486
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49081
Follows D68780147. We are depending on this API in one internal E2E test. Rename as `__setInterceptor_DO_NOT_USE`.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D68953084
fbshipit-source-id: 66b685a90b6e7f18646752dc90892963d16f9a83
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49102
Moves this script one level up. In the next diff, will be used to support execution of scripts themselves, as well as `packages/`.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D68960279
fbshipit-source-id: 7b62420c269dc1c1366ac9a827db078d34cb86c5
Summary:
Working on migrating some of the com.facebook.react.modules.network classes to Kotlin, I'm creating some test cases here for `CountingOutputStream` before migrating that class.
## Changelog:
[INTERNAL] - Add CountingOutputStream tests
Pull Request resolved: https://github.com/facebook/react-native/pull/49058
Test Plan:
```bash
yarn test-android
```
Reviewed By: cortinico
Differential Revision: D68903427
Pulled By: rshest
fbshipit-source-id: f71926cf526a65b2434aaa762007e0b4ca5dd1a4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49087
I'm moving the whole module to be in Kotlin and updating the BUCK file.
Those files also have 0 usages in OSS so not a breaking change.
Changelog:
[Internal] [Changed] -
Reviewed By: robhogan
Differential Revision: D68953731
fbshipit-source-id: d8238bf805661cbdd6fb070a60f3e32b44ec9832
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49079
The rule disallows using CommonJS exports in react-native and assets/registry package.
## Changelog:
[Internal] - Created a lint rule that prevents using CommonJS exports
Reviewed By: huntie
Differential Revision: D68951212
fbshipit-source-id: 1c9a1581af951d2a876b348981f0e5a81c99109a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49064
Update `public-api-test` to disregard all object/type members prefixed with an underscore (`_`). These are considered existing internal APIs.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D68895376
fbshipit-source-id: db581df7cc37802fa5f7d3aa4d7c07514223209a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49060
We want to hide private properties from JS public API interface. The stripPrivateProperties transform removes all private nodes of type ObjectTypeProperty, Property, PropertyDefinition and MethodDefinition. There is also a change in transforms reducer that incorporates `print` function from hermes-transform which modifies the code base on the transformed ast (transformed.mutatedCode seems to be a code before the transform operation).
## Changelog:
[Internal] - Added transform that strips private properties in build-types script
Reviewed By: huntie
Differential Revision: D68892853
fbshipit-source-id: 5035fd4339aa6294d972e7aff0eb563f48d4c3d2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49062
Another round of cleanup for the `public` keyword that I found around.
Those are unnecessary here as those classes are `internal` and we should remove them.
Changelog:
[Internal] [Changed] -
Reviewed By: mdvacca
Differential Revision: D68894182
fbshipit-source-id: 6f7bac6051e17785a1bfb0d544950250429c71cb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49019
Removes the `JSInspector` class and its dependencies.
- This was related to the legacy `ReactCommon/inspector/` subsystem (D4021490) — which added a compat layer from JavaScriptCore to CDP for an earlier version of Chrome debugging.
- The JS components of this system (`JSInspector.js`, `NetworkAgent.js`) were added in D4021516.
`ReactCommon/inspector/` has since been deleted and these components are no longer load bearing.
- We intend to replace this logic (at least, the archaic `XHRInterceptor` behaviour, which worked at one point) with native debugger `Network` domain support in our C++ layer.
**Changes**
- Remove all modules under `Libraries/JSInspector/`.
- Remove all `XHRInterceptor` call sites.
- Remove the `JSInspector.registerAgent()` mount point in `setUpDeveloperTools.js`.
- Exclude `Libraries/Core/setUp*` from `public-api-test` (these are side-effect setup files with no exported API).
Changelog:
[General][Breaking] - Remove legacy Libraries/JSInspector modules
Reviewed By: christophpurrer
Differential Revision: D68780147
fbshipit-source-id: 3d11cc89886a91055e6b69ac6f0609c288965801
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49074
This used to not be noticeable when we were clipping the background even without a border, after fixing that, we got line when the width/height was 0
This is again not an issue with new Background and Border since they take a slightly different approach
Diff that caused the issue D68279400
ie.
{F1974794589}
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D68843649
fbshipit-source-id: a25ace46b604690e3385c49d6f4bb3a4163bc594
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49020
## Motivation
Modernising the RN codebase to allow for modern Flow tooling to process it.
## This diff
- Migrates the `Libraries/EventEmitter/*.js` and `Libraries/Image/*.js` files to use the `export` syntax.
- Updates deep-imports of these files to use `.default`
- Updates the current iteration of API snapshots (intended).
Changelog:
[General][Breaking] - Deep imports to modules inside `Libraries/EventEmitter` and `Libraries/Image/*.js` with `require` syntax need to be appended with '.default'.
Reviewed By: huntie
Differential Revision: D68780876
fbshipit-source-id: bd8e702aba33878e38df6d9c89bec27e7c8df0ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49065
Changelog: [internal]
Cleaning up the flag because it's no longer necessary.
Reviewed By: sammy-SC
Differential Revision: D68892995
fbshipit-source-id: 4e0290bfb11181dc388e6590af1b82581588b9ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49063
## Motivation
Modernising the RN codebase to allow for modern Flow tooling to process it.
## This diff
- Updates react-native-codegen to generate ViewConfigs that are compatible with react-native both before and after the export syntax migration.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D68894819
fbshipit-source-id: fca46c1b91c15e22f1e1128ce8621c05341e2fe6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49012
Changelog: [internal]
(This is internal for now, until we rollout the DOM APIs in stable).
This refines the concept of root elements from the merged proposal for [DOM Traversal & Layout APIs](https://github.com/react-native-community/discussions-and-proposals/blob/main/proposals/0607-dom-traversal-and-layout-apis.md).
The original proposal included a reference to have the root node in the tree as `getRootNode()` and no other methods/accessors to access it.
This makes the following changes:
* The root node is a new abstraction in React Native implementing the concept of `Document` from Web. `node.getRootNode()`, as well as `node.ownerDocument` now return instances to this node (except when the node is detached, in which case `getRootNode` returns the node itself, aligning with the spec).
* The existing root node in the shadow tree is exposed as the `documentElement` of the new document instance. It would be the first and only child of the document instance, and the topmost parent of all the host nodes rendered in the tree.
In terms of APIs:
* Implements `getRootNode` correctly, according to the specified semantics.
* Adds `ownerDocument` to the `ReadOnlyNode` interface.
* Adds the `ReactNativeDocument` interface, which extends `ReadOnlyNode` (with no new methods on its own, which will be added in a following PR).
NOTE: This is currently gated under `ReactNativeFeatureFlags.enableDOMDocumentAPI` feature flag, which is disabled by default.
Reviewed By: yungsters
Differential Revision: D67526381
fbshipit-source-id: dff3645469e7ea2b2026dbbaa94d9fd0e00291be
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49011
Changelog: [internal]
This exposes the new `getPublicInstanceFromRoot` method from the React renderer in our RN façades, preparing for the new change to implement the document interface in RN.
Reviewed By: javache
Differential Revision: D68767143
fbshipit-source-id: 9a3403f9bc1612b402305695d084497a46ee4480
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49021
## Motivation
Modernising the RN codebase to allow for modern Flow tooling to process it.
## This diff
- Migrates files in `Libraries/LayoutAnimation/*.js` and `Libraries/Linking/*.js` to use the `export` syntax.
- Updates deep-imports of these files to use `.default`
- Updates jest mocks
- Updates the current iteration of API snapshots (intended).
Changelog:
[General][Breaking] - Deep imports to modules inside `Libraries/LayoutAnimation` and `Libraries/Linking` with `require` syntax need to be appended with '.default'.
Reviewed By: huntie
Differential Revision: D68782429
fbshipit-source-id: c9ea4fadbc44587a165d311b054fcd03444842c8
Summary:
`dev-middleware` uses `invariant` but does not declare it as a dependency. Under certain hoisting scenarios, or when using pnpm, this will cause `dev-middleware` to fail while being loaded.
## Changelog:
[GENERAL] [FIXED] - add missing `invariant` dependency
Pull Request resolved: https://github.com/facebook/react-native/pull/49047
Test Plan: n/a
Reviewed By: cortinico
Differential Revision: D68835789
Pulled By: huntie
fbshipit-source-id: 13718f4970ed55e6e062b7c2bd719be977abdd0c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49049
ReactBridge can be internalize, there are no usages in OSS
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D68540710
fbshipit-source-id: ce7fe6ca52186414650dcc529c5891dc59cab51a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49050
Changelog: [internal]
We added support for feature flags that don't have a native module definition so we could handle cases where the JS changes progressed faster than native ones, but we recently saw that when native catches up, the API starts logging an error through `console.error` about the native module method not being available.
That's an expected result of this feature and it's when we can clean up the code in JS, so we shouldn't be logging errors in that case.
This removes the error for them specifically.
Reviewed By: elicwhite
Differential Revision: D68843247
fbshipit-source-id: 730f3eba8c26959825cd9c3897f055a02a5f9591
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49018
Changelog: [internal]
Migrates the mounting layer logs from C++ (640 lines of code) to Fantom (248 lines!!!).
This is 1:1 translation of the test.
Reviewed By: javache
Differential Revision: D67549200
fbshipit-source-id: 735fa3203cd04dd5b3b4b5174e0c96fdc2354993
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49017
Changelog: [internal]
The debug string for props doesn't log `nativeID` so we can't access it in Fantom. This fixes that to simply future tests.
Reviewed By: javache
Differential Revision: D68779903
fbshipit-source-id: 9800ef2b6d173e2fc8e21d3d910139a30ae91342
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49016
Changelog: [internal]
This replaces the existing string-based logs with something more structured, and increases the coverage to properly log all operations.
As part of this work I had to refactor how we record mutations so they would be done while applying the mutations, and not before/after where necessary metadata might not be available yet/anymore.
Reviewed By: sammy-SC
Differential Revision: D67549201
fbshipit-source-id: 0bcb1642a6b3d7e704f4ee24a550d4189c406aed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49015
Changelog: [internal]
This name better reflects the fact that we're emptying the buffer when calling it.
Reviewed By: javache
Differential Revision: D67549202
fbshipit-source-id: 7523a130f26bced122acd4f50b45c2b61a39bba9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48930
Changelog: [internal]
This creates new versions of `XMLHttpRequest`, `FileReader` and `WebSocket` that extend the new built-in `EventTarget` implementation, instead of the implementation from the `event-target-shim` package.
It also sets up a test to choose between the 2 implementations at runtime to verify correctness and performance. This doesn't use the RN feature flags infra because we use this flag very early on startup, before we have a chance to set overrides. We could use a native feature flag instead but it'd slow down the rollout of the test.
Reviewed By: yungsters
Differential Revision: D68625226
fbshipit-source-id: bff715c43a237b65d5a02a3fdb56f3275689ea46
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49045
Changelog: [internal]
Making some objects read-only to reflect usage and allow callers to pass both read-only and writable objects.
Reviewed By: yungsters
Differential Revision: D68831136
fbshipit-source-id: e9a2d96ec0abd13f609d26d376e6da946f802011
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48928
Changelog: [internal]
Just a minor change to reduce the number of Flow errors we will get when we refactor XHR soon.
Reviewed By: javache
Differential Revision: D68625224
fbshipit-source-id: e952f3f52de8081a0773ef3a01e1259c3be67a92
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49022
These modules support the in-app Inspector Overlay.
Breaking change that's unlikely to hit any users. Unreferenced by Expo.
Changelog:
[General][Breaking] Move `Libraries/Inspector/` modules to `src/private/`
Reviewed By: cortinico
Differential Revision: D68781896
fbshipit-source-id: 8fcd72d56684319019f64a375c2e2ef317a47c13
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49010
Changelog: [internal]
This adds a stub method for `ReactNativePrivateInterface.createPublicRootInstance`, which just returns `null` for now, so we can synchronize the React renderer that will try to use it to create root instances.
Initially, this will not do anything and React will just pass the `null` value around. When we implement the document API, we will return a proper instance and React will pass it to `createPublicInstance` so we can link things at runtime.
Reviewed By: javache
Differential Revision: D68561173
fbshipit-source-id: 632a7c3523910059a1f63f35b5f0f52f5660a961
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49009
Changelog: [internal]
Native APIs so far have returned instance handles from React to reference nodes in the rendered UI tree, but now that we're adding support for the document API, this isn't sufficient to represent all types of nodes. Both for the document and for its `documentElement`, we don't have an instance handle from React that links to the node, but we're going to represent that differently.
This is a refactor so the existing methods use a mostly opaque `NativeNodeReference` type so we can implement it as a union of React instance handles and the future types we're going to introduce to support document.
Reviewed By: javache
Differential Revision: D67704855
fbshipit-source-id: 0568143d9ce39be65986e1a4b92fdaebd79e4f66
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49008
Changelog: [internal]
We're modifying some core APIs in the RN render in following diffs, so this adds a simple benchmark as a safety mechanism to verify those don't regress performance significantly.
Reviewed By: yungsters
Differential Revision: D68772175
fbshipit-source-id: 3bc446e68495dc04590b613297baa00589fb5f8d
Summary:
The `maxFontSizeMultiplier` prop for `Text` and `TextInput` was not handled in Fabric / New Architecture as documented in https://github.com/facebook/react-native/issues/47499.
bypass-github-export-checks
## Changelog:
[GENERAL] [FIXED] - Fix `maxFontSizeMultiplier` prop on `Text` and `TextInput` components in Fabric / New Architecture
Pull Request resolved: https://github.com/facebook/react-native/pull/47614
Test Plan:
I have not added any automated tests for this change but try to do so if requested. I have however added examples to RN Tester for both the Text and TextInput components, as well as compared the behaviour with Paper / Old Architecture. Both on version 0.76.
Noticed now I didn't do exactly the same steps in both videos, oops! Be aware that reapplying changes made in the Settings are currently half-broken on the new architecture, thus I'm restarting the app on Android and iOS. But this issue is unrelated to my changes. I've tested on main branch and it has the same issue.
Here are comparison videos between Paper and Fabric on iOS *after* I've made my fix.
### Text
| Paper | Fabric |
| ------------- | ------------- |
| <video src="https://github.com/user-attachments/assets/f4fd009f-aa6d-41ab-92fa-8dcf1e351ba1" /> | <video src="https://github.com/user-attachments/assets/fda42cc6-34c2-42a7-a6e2-028e7c866075" /> |
### TextInput
| Paper | Fabric |
| ------------- | ------------- |
| <video src="https://github.com/user-attachments/assets/59b59f7b-25d2-4b5b-a8e2-d2054cc6390b" /> | <video src="https://github.com/user-attachments/assets/72068566-8f2a-4463-874c-45a6f5b63b0d" /> |
Reviewed By: Abbondanzo
Differential Revision: D65953019
Pulled By: cipolleschi
fbshipit-source-id: 90c3c7e236229e9ad9bd346941fafe4af8a9d9fc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49032
Add a native API to validate the RuntimeScheduler has no pending tasks, and automatically validate after every test that there's no pending tasks left to execute.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D68797481
fbshipit-source-id: dbbef894a57bd29eb5a033ac8aaeedef770dcba2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49030
Overwriting another RawProps object via `operator=` is rarely what we want, and these objects should be considered immutable once constructed.
This will catch issues such as D68633985
Changelog: [General][Changed] Removed `RawProps::operator=`
Reviewed By: sammy-SC
Differential Revision: D68797484
fbshipit-source-id: 766a65db1dbf4485c78007f8f69cc9426d27a943
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49029
This was never being compiled, because we didn't import the header that set `RN_DEBUG_STRING_CONVERTIBLE`
Will look at enabling `-Wundef` to catch these.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D68797482
fbshipit-source-id: 6a01192c799903b6f956f9b0acea94bd93183f3b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49033
Those methods are not used at all in the codebase, let's clean them up.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D68826893
fbshipit-source-id: 36e2f0ae247ed72305c1d9d346c6cf32cef6f8f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49034
This class was still in Java. I'm converting it to Kotlin + I'm making it internal.
As this class was inside the `com.facebook.react.internal.turbomodule.core` package,
we don't consider this a breaking change.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D68826892
fbshipit-source-id: b1f7aea984ab333faea66a9e8ccbb1492767333e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49024
## Motivation
Modernising the RN codebase to allow for modern Flow tooling to process it.
## This diff
- Migrates files in `Libraries/Lists/*.js` to use the `export` syntax.
- Updates deep-imports of these files to use `.default`
- Updates the current iteration of API snapshots (intended).
Changelog:
[General][Breaking] - Deep imports to modules inside `Libraries/Lists` with `require` syntax may need to be appended with '.default'.
Reviewed By: huntie
Differential Revision: D68783945
fbshipit-source-id: 7563155254fed40b6fe7d280d9e040ea24a5c870
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49007
# Changelog: [Internal]
Before sending `Tracing.start`, CDT will also send `Debugger.disable`.
You don't want to hit your breakpoints when you are profiling an appplication, this is by design.
We won't just delegate this to Hermes to handle. We will explicitly check that this condition is satisfied on React Native side. This is done to avoid regression in case the implementation details will change on CDT side.
Later in D68414421, we will also check that samples JavaScript stack don't contain debugger frames. This is necessary to distinguish garbage collector frames from debugger frames, which share the same type in Hermes VM - "Suspend".
We need garbage collector frames. If debugger frame was found we would throw an error, because this is unexpected after Debugger domain was disabled.
Right now Hermes is not disabling local VM Debugger on `Debugger.disable` method - this is a known bug, which I am addressing in a stack from D68772900.
Reviewed By: huntie
Differential Revision: D68776863
fbshipit-source-id: 4346ac5eb850578265a179b5fd687539ae7d15bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48988
The only unitless `<length>` value allowed is `0`, so most of the examples in the `processBoxShadow` unit tests are parse errors on web 🫠. Lets update the tests, and disallow these invalid values.
Changelog:
[General][Breaking] - Disallow invalid unitless lengths in box shadows
Reviewed By: jorge-cab
Differential Revision: D68740553
fbshipit-source-id: ea935819f773c5d516dd9b3367e5d2c808941c28
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48984
Noticed this in conjunction with another change, that I misinterpreted the ratio spec a bit. Ratios with a part less than zero are parse errors, while degenerate ratios are not (Chrome and Firefox both treat like this).
Removing usage of visitorless `consumeComponentValue()` here in preparation for next diff.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D68733519
fbshipit-source-id: 9afc7b7295b067a3e1469e2f80f5c9a6bea41fae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49027
Make constants more specific to `METAHash` (avoid potential conflicts) and unify the APIs with a shared attribute definition (will be used to mark these APIs as unavailable from Swift).
## Changelog:
[iOS] [Changed] - Change prime constants to have prefix in order to avoid any potential conflicts
Reviewed By: adamjernst
Differential Revision: D68790450
fbshipit-source-id: 69c8b73063cf57d6a4ec25f6cd52a906c77694f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49000
Just found those nits around while looking at the codebase.
This clears things out and should have no runtime impact.
Changelog:
[Internal] [Changed] -
Reviewed By: mdvacca
Differential Revision: D68768384
fbshipit-source-id: bd3a30f1792a6f662d1f5b25855c89b6d43e72bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48650
## Motivation
Modernising the RN codebase to allow for modern Flow tooling to process it.
## This diff
- Migrates the `Libraries/ReactNative/*.js` files to use the `export` syntax.
- Updates deep-imports of these files to use `.default`
- Updates the current iteration of API snapshots (intended).
Changelog:
[General][Breaking] - Deep imports to modules inside `Libraries/ReactNative` with `require` syntax need to be appended with '.default'.
Reviewed By: huntie
Differential Revision: D68109193
fbshipit-source-id: 3444bf6b2152f7ed72d2923149a10041d718aaf0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49001
In {D42973408}, `Debugger.scriptParsed` was tweaked to be intercepted in `inspector-proxy`, which:
1. Rewrote the `sourceMapURL` to be relative to debugger.
2. Attempted to fetch the contents of the source map from `sourceMapURL` after re-writing again to a server-relative URL, and if successful replaced `sourceMapURL` with a base64 data URL.
1 is still needed until we have `Network.loadNetworkResource`, but 2 was only needed for frontends that did not support http fetch, and is not needed with Fusebox.
Changelog: [General][Changed] `Debugger.scriptParsed` now includes the field `sourceMapURL` as a (rewritten) remote url as opposed to base64 data url
Reviewed By: robhogan
Differential Revision: D68708899
fbshipit-source-id: 95242582c79ce4e9a573d4a3e639b0dc3290869e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49004
This just converts yet another class to Kotlin.
Changelog:
[Internal] [Changed] -
Reviewed By: tdn120
Differential Revision: D68772336
fbshipit-source-id: 428cb3a0d54bf7a22f0e4eb07268cdc27ef6f2c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48905
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates `Libraries/StyleSheet/processColorArray.js` to use `export` syntax.
- Appends `.default` to requires of the changed files.
- Updates test files.
- Updated View Config codegen (requires an MSDK bump).
- Updates the public API snapshot *(intented breaking change)*
Changelog:
[General][Breaking] - Files inside `Libraries/Text`, `Libraries/Share` and `Libraries/Settings` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: robhogan
Differential Revision: D68564304
fbshipit-source-id: 2fbd058be1a715cccfce4f2a68146118d8ac66ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48807
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates a handful of components in `Libraries/Components` to use `export` syntax
- `export default` for qualified objects, many `export` statements for collections (determined by how it's imported)
- Appends `.default` to requires of the changed files.
- Updates test files.
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/Components` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: huntie
Differential Revision: D68436127
fbshipit-source-id: e3496fe69d66932dd4ed82f41d810f3ef1f850f5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49003
Changelog: [internal]
I was adding a benchmark for rendering thousands of views and it was surprisingly fast, until I realized I wasn't wrapping the call to `root.render` in `runTask`, which means the benchmark wasn't really doing the rendering, only scheduling a microtask that was never executed.
This is a safety mechanism to prevent those mistakes.
Reviewed By: sammy-SC
Differential Revision: D68771170
fbshipit-source-id: 5bd8e6ba9e1168db2320572c99b3a01ebd6aeeed
Summary:
This is another attempt at fixing the Android HMR client for HTTPS proxied Metro instances. The previous one unintentionally [caused the following error](https://github.com/facebook/react-native/pull/48970#issuecomment-2617047184):
```
java.lang.AssertionError: Method overloading is unsupported: com.facebook.react.devsupport.HMRClient#setup
```
This PR removes the overloading, and only adds the `scheme` property as a parameter to the existing `.setup` method. Aligning with the exact behavior we have on iOS.
The alternative fix, which should NOT be backward breaking (if this is) - is to move this "infer the protocol from the bundle URL" to the JS side of the HMR client. Where we don't just always default to `http`, but instead default to `https IF port === 443, otherwise http`. It's a bit more hacky, but shouldn't cause any other issues. _**Ideally**_, we have the same working behavior on both Android and iOS without workarounds.
<details><summary>Alternative workaround</summary>
See [this change](https://github.com/facebook/react-native/compare/main...byCedric:react-native:patch-2).
<img width="1179" alt="image" src="https://github.com/user-attachments/assets/47c365bc-6df8-43e6-ad7d-5a667e350cd4" />
</details>
See full explanation on https://github.com/facebook/react-native/issues/48970
> We've noticed that the HMR on Android doesn't seem to be connecting when using a HTTPS-proxied Metro instance, where the proxy is hosted through Cloudflare. This is only an issue on Android - not iOS - and likely caused by the HMR Client not being set up properly on Android.
>
>- On Android, we run `.setup('android', <bundleEntryPath>, <proxiedMetroHost>, <proxiedMetroPort>, <hmrEnabled>)` in the [**react/devsupport/DevSupportManagerBase.java**](https://github.com/facebook/react-native/blob/53d94c3abe3fcd2168b512652bc0169956bffa39/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/devsupport/DevSupportManagerBase.java#L689-L691) file.
>- On iOS, we run `[self.callableJSModules invokeModule:@"HMRClient" method:@"setup" withArgs:@[ RCTPlatformName, path, host, RCTNullIfNil(port), @(isHotLoadingEnabled), scheme ]];` in the [**React/CoreModules
/RCTDevSettings.mm**](https://github.com/facebook/react-native/blob/53d94c3abe3fcd2168b512652bc0169956bffa39/packages/react-native/React/CoreModules/RCTDevSettings.mm#L488-L491) file.
>
>Notice how Android does not pass in the scheme/protocol of the bundle URL, while iOS actually does? Unfortunately, because the default protocol (`http`) mismatches on Android when using HTTPS proxies, we actually try to connect the HMR client over `http` instead of `https` - while still using port 443 - which is rejected by Cloudflare's infrastructure even before we can redirect or mitigate this issue. And the rejection is valid, as we basically try to connect on `http://<host>:443` (the source URL is `https`, so the port is infered as `443`).
>
>This change adds scheme propagation to Android, exactly like we do on iOS for the HMR Client.
## Changelog:
[ANDROID] [FIXED] Pass the bundle URL protocol when setting up HMR client on 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/48998
Test Plan:
See full explanation on https://github.com/facebook/react-native/issues/48970
> It's a little bit hard to test this out yourself, since you'd need a HTTPS-based proxy and reject HTTP connections for HTTPS/WSS Websocket requests.
>
>You can set this up through:
>- `bun create expo@latest ./test-app`
>- `cd ./test-app`
>- `touch .env`
>- Set `EXPO_PACKAGER_PROXY_URL=https://<proxied-metro-hostname>` in **.env**
>- Set `REACT_NATIVE_PACKAGER_HOSTNAME=<proxied-metro-hostname>` in **.env**
>- `bun run start`
>
>Setting both these envvars, the bundle URL in the manifest is set to `https://...` - which triggers this HMR issue on Android. You can validate the **.env** setup through:
>
>```bash
>curl "http://localhost:8081" -H "expo-platform: android" | jq .launchAsset.url
>```
>
>This should point the entry bundle URL towards the `EXPO_PACKAGER_PROXY_URL`.
Reviewed By: cortinico
Differential Revision: D68768351
Pulled By: javache
fbshipit-source-id: 49bf1dc60f11b2af6e57177141270632d62ab564
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48940
The PerformanceObserver (marks and measures) example clears it's output each time a new PerformanceObserver event fires, which makes it not particularly useful.
This change makes it so the output is only updated if a non-empty list of performance events is observed.
## Changelog
[Internal]
Reviewed By: rubennorte
Differential Revision: D68634361
fbshipit-source-id: 71b97e1c66aabd090cae63d55c8fa0a425d0c2f4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48931
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling
## This diff
- Updates files in Libraries/Inspector to use `export` syntax
- Appends `.default` to requires of the changed files.
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/Inspector` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: robhogan
Differential Revision: D68629285
fbshipit-source-id: ee0904ea5e8f9389aecfb197d05225c88137fb08
Summary:
Currently, the class OkHttpClientProvider is still in Java. Adding some tests before migrating it to Kotlin
## Changelog:
[INTERNAL] - Add OkHttpClientProvider tests
Pull Request resolved: https://github.com/facebook/react-native/pull/48958
Test Plan:
```bash
./gradlew :packages:react-native:ReactAndroid:test -Dtest.single=com.facebook.react.modules.network
```
Reviewed By: javache
Differential Revision: D68706173
Pulled By: cortinico
fbshipit-source-id: 7b4b1cbe17ff39d3775075682dcb8d253892e062
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48995
This change adds an extra parameter to the codegen script that allow our users to trigger codegen for Apps or for Libraries.
When running codegen for Apps, we have to generate some extra files that are not needed by the Libraries. This is causing issues to our library maintainers and this change will provide more flexibility in the DevX of libraries.
The default value is App, so if the new parameter is not passed, nothing will change in the current behavior.
## Changelog:
[iOS][Added] - Add the `source` parameter to generate-codegen-artifacts to avoid generating files not needed by libraries.
Reviewed By: cortinico
Differential Revision: D68765478
fbshipit-source-id: 8030b4472ad4f5058e58b1c91089de5122a4f60a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48934
This class is publicly exposed but effectively unused at all (neither internally, nor externally).
I'm removing it as this should not affect anyone.
Changelog:
[Android] [Breaking] - Removed `RuntimeConfig` class for Hermes which was unused.
Reviewed By: tdn120
Differential Revision: D68631945
fbshipit-source-id: 6a62ccda9e62f4bae650c11bc17a95efc8c88baf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48980
Changelog: [internal]
This will be properly removed soon, but disabling for now to avoid showing up in all PRs.
Reviewed By: cortinico
Differential Revision: D68719573
fbshipit-source-id: 6a631ba2556f1399d0ade52f19b79f5a3212e007
Summary:
Fixes https://github.com/facebook/react-native/issues/37801
This PR fixes the system bars visibility not being in sync as with the activity it is displayed on.
Here I am also taking into account the feedback given in [this PR](https://github.com/facebook/react-native/pull/36854) which was also aiming to address this issue. Unfortunately, I tried in multiple ways to get this to work by simply extending the whole system bars behaviour in the dialog with the activity system bars behaviour but found out that that solution won't work as we [currently clear the flag "FLAG_NOT_FOCUSABLE"](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/modal/ReactModalHostView.kt#L314) and unless we remove that line, extending the behaviour won't work. Removing that line is not an option as it would cause other side effects in the dialog itself.
With the above said, I ended up doing this in a more explicit way, by checking whether the status or navigation bars are hidden in the activity and then hiding then as well in the dialog or otherwise, similar as we are currently doing with the status bars appearance.
## Changelog:
[ANDROID] [FIXED] - Sync Modal system bars visibility with current activity
Pull Request resolved: https://github.com/facebook/react-native/pull/48516
Test Plan:
In order to test this, you need to trigger any method that hides or shows the system bars using `window.insetsController`. Here a very small example of it:
```kt
fun toggleSystemBarsVisibility(shouldHide: Boolean) {
val window = currentActivity?.window
val controller = window?.insetsController
if (shouldHide) {
controller?.hide(WindowInsets.Type.systemBars())
} else {
controller?.show(WindowInsets.Type.systemBars())
}
}
```
You can do this optionally from JS to make testing different cases easier. Below is a screen recording of how the solutions looks like:
<details>
<summary>Screen recording showcasing the solution in the test plan</summary>
https://github.com/user-attachments/assets/c497c1cb-5e65-4f31-98cc-aefd2d7b0339
</details>
Reviewed By: mdvacca, Abbondanzo
Differential Revision: D67906071
Pulled By: alanleedev
fbshipit-source-id: cbb2d15520d7729a9e9eafb5f5efb8d20d796c60
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48982
We were missing a conversion to px on the `getOutline()` function of `CompositeBackgroundDrawable` which led to incorrect elevation prop rendering
Changelog: [Android][Fixed] - Elevation prop on android has incorrect border-radius
Reviewed By: NickGerleman
Differential Revision: D68724947
fbshipit-source-id: b3a7a4919bfd7c60fac7c3d6e3ba760e3f74d190
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48054
Web debugging should be fully removed as of recent, so lets remove some of the gunk that was powering it, and checks for that environment.
I did some string searches for the following:
* isAsyncDebugging
* debugRemotely
* isDebuggingRemotely
* isRemoteDebuggingAvailable
* WebSocketExecutor
* JavaJSExecutor
* ProxyJavaScriptExecutor
* RELOAD_APP_EXTRA_JS_PROXY
* getJSBundleURLForRemoteDebugging
* onReloadWithJSDebugger
* setRemoteJSDebugEnabled
* WebsocketJavaScriptExecutor
* createRemoteDebuggerBundleLoader
1. `expo-modules-core` exposes its own `isAsyncDebugging` by checking for `nativeCallSyncHook`, but does not depend on `DebugEnvironment`.
2. `expo-dev-menu` does read `isDebuggingRemotely` from `DevSettings`.
3. Realm does a check in Native using `objc_lookUpClass("RCTWebSocketExecutor")` but will gracefully handle `nil` if it does not exist
4. Some more usages (e.g. `onReloadWithJSDebugger`) in vendored packages of `expo-dev-launcher` for RN 0.74
I created an issue for Expo mentioning both here: https://github.com/expo/expo/issues/33371
Changelog:
[General][Breaking] - Remove some web debugging remnants
Reviewed By: huntie
Differential Revision: D66553934
fbshipit-source-id: deec382b1c8bda393fddb8682aa91b26afd9fbe3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48913
This brings us to parity with normalize-color, and is mostly similar to hsl, with the notable exception there is not a separate alpha variant, and only modern function syntax is supported. Again, I took the math from normalize-color, and sanity tested it against reference function provided by Color Spec.
I'm going to let that cap off color function support for now, and leave the rest as TODO.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D68594471
fbshipit-source-id: 95702d576e068655d34e52a714d38e4fd718bbc9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48912
The implementation of `hwb()` color functions added in https://github.com/facebook/react-native/pull/34600 is pretty flawed.
`hwb()` color functions do not allow comma delimited values. So most of the examples in the unit test here will fail to parse on web. Like `hsl()`, these should also allow numeric non-hue components (instead of just %), and angle values for hue (instead of just numbers), and this is also missing support for alpha values, though these are less dangerous compared to allowing and encouraging incorrect delimiters.
https://www.w3.org/TR/css-color-4/#the-hwb-notation
These were added for web compat, and the examples fail to parse on web, so I'm opting to just remove this incorrect support before implementing this more correctly in the Fabric CSS parser in next diff. I did not attempt to fix the other issues I discovered with the PR implementation in the last couple diffs, around mixing and matching syntax allowed in legacy/modern, along with allowing inconsistent delimiters.
Changelog:
[General][Breaking] - Remove incorrect hwb() syntax support from normalize-color
Reviewed By: lenaic
Differential Revision: D68591172
fbshipit-source-id: 36d670b096ae9fac4bc24938877ad083d4dd336a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48878
Creates a new `scheduleAnimatedCleanupInMicrotask` feature flag to experiment with deferring the `AnimatedProps` cleanup using the microtask queue.
This is different from the previous approach of deferring invocation of the completion callback, which impacted the timing of composite animations such as `Animated.parallel` and `Animated.sequence`, because we are deferring detaching the `AnimatedNode` graph instead. This will only impact the timing of completion callbacks as a result of invalidating `AnimatedProps` (either by passing in new `AnimatedValue` instances or unmounting the component).
This should minimally impact scheduling and have lower risk of user-visible behavior change because React already provides minimal guarantees around when updates are committed (and effects attached/detached).
This also enables us to significantly simplify the current convoluted dance we do to optimized around reference counting in the AnimatedNode graph.
Changelog:
[General][Changed] - When an Animated component is updated or unmounted, `AnimatedNode` instances will now detach in a microtask instead of synchronously in the commit phase of React. This will cause the completion callback of finished animations to execute after the commit phase instead of during it.
Reviewed By: rickhanlonii
Differential Revision: D68527096
fbshipit-source-id: 99346b8ddbf6a01725376c692b0351be679b9e89
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48975
After cutting 0.78-stable, we need to bump the monorepo packages to `0.79.0-main`
## Changelog:
[Internal] - Bump monorepo packages to `0.79.0-main`
Reviewed By: cortinico, huntie
Differential Revision: D68715005
fbshipit-source-id: cb5abbf05e8638683687be8d61d66b3037111572
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48973
changelog: [internal]
This test is broken, let's disable it until it is fixed.
Reviewed By: javache
Differential Revision: D68709385
fbshipit-source-id: f61b287ad7ef921dd26fa290cc7a484d0b550091
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48968
I've noticed we have a lot of `public` and `protected` modifiers for classes that are actually `internal`.
Those are unnecessary as the class itself is `internal` and there is no way to extend the visibility of single fields.
Changelog:
[Internal] [Changed] -
Reviewed By: mdvacca
Differential Revision: D68707255
fbshipit-source-id: 5b93d01dceba1b5031ac608e58ec898c1a1eaf51
Summary:
We've noticed that the HMR on Android doesn't seem to be connecting when using a HTTPS-proxied Metro instance, where the proxy is hosted through Cloudflare. This is only an issue on Android - not iOS - and likely caused by the HMR Client not being set up properly on Android.
- On Android, we run `.setup('android', <bundleEntryPath>, <proxiedMetroHost>, <proxiedMetroPort>, <hmrEnabled>)` in the [**react/devsupport/DevSupportManagerBase.java**](https://github.com/facebook/react-native/blob/53d94c3abe3fcd2168b512652bc0169956bffa39/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/devsupport/DevSupportManagerBase.java#L689-L691) file.
- On iOS, we run `[self.callableJSModules invokeModule:@"HMRClient" method:@"setup" withArgs:@[ RCTPlatformName, path, host, RCTNullIfNil(port), @(isHotLoadingEnabled), scheme ]];` in the [**React/CoreModules
/RCTDevSettings.mm**](https://github.com/facebook/react-native/blob/53d94c3abe3fcd2168b512652bc0169956bffa39/packages/react-native/React/CoreModules/RCTDevSettings.mm#L488-L491) file.
Notice how Android does not pass in the scheme/protocol of the bundle URL, while iOS actually does? Unfortunately, because the default protocol (`http`) mismatches on Android when using HTTPS proxies, we actually try to connect the HMR client over `http` instead of `https` - which is rejected by Cloudflare's infrastructure even before we can redirect or mitigate this issue.
This change adds scheme propagation to Android, exactly like we do on iOS for the HMR Client.
## Changelog:
[ANDROID] [FIXED] Pass the bundle URL protocol when setting up HMR client on 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/48970
Test Plan: It's a little bit hard to test this out yourself, since you'd need a HTTPS-based proxy and reject HTTP connections for HTTPS/WSS Websocket requests.
Reviewed By: fabriziocucci
Differential Revision: D68711137
Pulled By: javache
fbshipit-source-id: 230c1c91c8189c0a109d20defe085966ac8f5721
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48922
Changelog: [internal]
This is a basic subclass of Event that allows setting custom values (as opposed to `Event` that is meant to be used as a superclass).
Reviewed By: yungsters
Differential Revision: D67804060
fbshipit-source-id: 9e140cc436f8e230f37275a74df23efd4841071b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48962
Changelog: [internal]
We moved away from private fields for `EventTarget` for performance, in favor of normal fields prefixed with underscore, but this would pollute the global scope when we make it extend `EventTarget`.
This refactors the implementation to use symbols for all properties to avoid that problem, leaving only `addEventListener` and `removeEventListener` as regular properties in the prototype.
Performance-wise this is neutral or a slight improvement according to the existing benchmark.
Reviewed By: javache
Differential Revision: D68672215
fbshipit-source-id: b329548efce6059ae2b9f33afa0719e057d3b8ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48918
Changelog: [internal]
Makes the constants read-only and accessible through `Event.prototype` as well.
Reviewed By: yungsters
Differential Revision: D67830012
fbshipit-source-id: 730622a642f08f532cebd4c183d859ccb2ca0641
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48426
Changelog: [internal]
This improves the performance of DOM `Event` interface implementation by migrating away from private fields.
Reviewed By: yungsters
Differential Revision: D67751821
fbshipit-source-id: e58e5a9cbb04e7d91cbc676ec7d1b00fff357e2e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48427
Changelog: [internal]
The `ReactNativeElement` class was refactored for performance reasons, and the current implementation does **NOT** call `super()`, and it inlines the parent constructor instead.
When it eventually extends `EventTarget`, things won't work as expected because the existing `EventTarget` implementation has constructor dependencies.
This refactors the current implementation of `EventTarget` to eliminate those constructor side-effects, and eliminates the constructor altogether.
This breaks encapsulation, but it has some positive side-effects on performance:
1. Creating `EventTarget` instances is faster because it has no constructor logic.
2. Improves memory by not creating maps to hold the event listeners if no event listeners are ever added to the target (which is very common).
3. Improves the overall runtime performance of the methods in the class by migrating away from private methods (which are known to be slow on the babel transpiled version we're currently using).
Extra: it also simplifies making window/the global scope implement the EventTarget interface :)
## Benchmark results
Before:
| Latency average (ns) | Latency median (ns) | Samples | Task name | Throughput average (ops/s) | Throughput median (ops/s) |
| ---|--- |--- |--- |---|---|
| 8234.22 ± 0.27% | 8132.00 | 121445 | dispatchEvent, no bubbling, no listeners | 122323 ± 0.02% | 122971 |
| 9001.22 ± 0.41% | 8883.00 | 111097 | dispatchEvent, no bubbling, single listener | 111981 ± 0.02% | 112575 |
| 51777.94 ± 0.58% | 51247.00 | 19314 | dispatchEvent, no bubbling, multiple listeners | 19393 ± 0.04% | 19513 |
| 8256.65 ± 0.29% | 8152.00 | 121115 | dispatchEvent, bubbling, no listeners | 122031 ± 0.02% | 122669 |
| 9064.32 ± 0.44% | 8933.00 | 110323 | dispatchEvent, bubbling, single listener per target | 111265 ± 0.02% | 111944 |
| 51879.66 ± 0.27% | 51447.00 | 19276 | dispatchEvent, bubbling, multiple listeners per target | 19325 ± 0.04% | 19437 |
After:
| Latency average (ns) | Latency median (ns) | Samples | Task name | Throughput average (ops/s) | Throughput median (ops/s)|
| ---------------------|---------------------|---------|--------------------------------------------------------|----------------------------|--------------------------|
| 5664.62 ± 0.50% | 5588.00 | 176535 | dispatchEvent, no bubbling, no listeners | 178219 ± 0.02% | 178955 |
| 7232.86 ± 0.50% | 7131.00 | 138258 | dispatchEvent, no bubbling, single listener | 139540 ± 0.02% | 140233 |
| 50957.51 ± 0.71% | 50336.00 | 19625 | dispatchEvent, no bubbling, multiple listeners | 19751 ± 0.04% | 19866 |
| 5692.36 ± 0.50% | 5618.00 | 175675 | dispatchEvent, bubbling, no listeners | 177315 ± 0.02% | 177999 |
| 7277.82 ± 0.38% | 7181.00 | 137404 | dispatchEvent, bubbling, single listener per target | 138560 ± 0.02% | 139256 |
| 50493.64 ± 0.28% | 50105.00 | 19805 | dispatchEvent, bubbling, multiple listeners per target | 19855 ± 0.04% | 19958 |
Reviewed By: yungsters
Differential Revision: D67758408
fbshipit-source-id: f8da1788251c9e21377de5ab730875bcc7610361
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48431
Changelog: [internal]
Adds a regression test to make sure we implement the correct spec-compliant behavior for a possible bug in ~~the Web spec~~ __Chrome__: https://github.com/whatwg/dom/issues/1346
Edit: the bug is in the Chrome implementation, not in the spec.
Reviewed By: javache
Differential Revision: D67758702
fbshipit-source-id: ecaeacac3bce286e692880f05d70297ba0c2c736
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48429
Changelog: [internal]
This implements a (mostly) spec-compliant version of the [`Event`](https://dom.spec.whatwg.org/#interface-event) and [`EventTarget`](https://dom.spec.whatwg.org/#interface-eventtarget) Web interfaces.
It does not implement legacy methods in either of the interfaces, and ignores the parts of the spec that are related to Web-specific quirks (shadow roots, re-mapping of animation events with webkit prefixes, etc.).
IMPORTANT: This only creates the interfaces and does not expose them externally yet (no `Event` or `EventTarget` in the global scope).
Reviewed By: yungsters
Differential Revision: D67738145
fbshipit-source-id: c86db29821552cc1a1b6e1023cc3a21ae55febd5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48965
Running codegen should not be a Cocoapods responsibilities, but it should be something that runs before Cocoapods to ensure that the code is already in the right place.
This change moves the invocation of Codegen to the react-native's core-cli-utils so that frameworks can integrate better with it.
It should also make it easier to migrate away from Cocoapods.
## Changelog:
[iOS][Changed] - Invoke Codegen as part of the Core-cli-utils package
Reviewed By: cortinico
Differential Revision: D68706136
fbshipit-source-id: 548c9ffad62bc561fcc948babaf75de5dad82f86
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48966
In our previous fix for concurrent-ruby, we have been a bit too strict. Version 1.3.4 is a valid and working version. The broken version is 1.3.5.
## Changelog:
[iOS][Changed] - Fix Gemfile versions
Reviewed By: cortinico
Differential Revision: D68706060
fbshipit-source-id: 8ab7a4df0eb83a82603729ff8460e64908ddc465
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48961
One of Cocoapods responsibility is to run Codegen while creating the Xcode workspace. Moving away from Cocoapods, this is a step we need to move to a different place.
This change let us to disable running codegen at cocoapods time when we pass the `RCT_SKIP_CODEGEN=1` or when we pass the `RCT_IGNORE_PODS_DEPRECATION=1` flag calling pod install.
When calling `pod install` with `RCT_IGNORE_PODS_DEPRECATION` we are either:
* using one of the Scripts provided by Expo or by the Community CLI
*or*
* we are preparing the project using the legacy mode and, therefore, we want to keep running codegen.
## Changelog
[iOS][Changed] - Stop running codegen when running pod install
Reviewed By: cortinico
Differential Revision: D68704604
fbshipit-source-id: 252e90544886c3dbfd7eff38c344dd4784a0af38
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48960
We are moving away from Cocoapods toward alternative solution.
We are adding this deprecation message to help inform our users that this change is happening.
Part of the Cocoapods tasks will be moved to an alternative script that will be invoked by Expo and by the Community CLI. The warning message tells the users what to do as an alternative to `pod install`.
## Changelog:
[iOS][Deprecated] - deprecate calling `pod install` directly
Reviewed By: cortinico
Differential Revision: D68704127
fbshipit-source-id: df93008afc055254d0c0da09566c84af99248310
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48933
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling
## This diff
- Updates files in Libraries/Interaction to use `export` syntax
- Appends `.default` to requires of the changed files.
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/Interaction` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: huntie
Differential Revision: D68629953
fbshipit-source-id: 526b18d9b64c4b27b6e3198a9725075fa11e345a
Summary:
Changelog: [General][Fixed] Update tests to support new `didOpen` delegate fn
Add support for the new `didOpen` delegate function in tests.
To follow up separately: the borked tear down sequence when these two tests are ran together (they pass when ran individually)
```
buck2 test @//fbobjc/mode/buck2/ios-tests fbsource//xplat/js/react-native-github/packages/react-native/ReactCommon/jsinspector-modern:testsAppleMac -- ReactInstanceIntegrationTest RuntimeTargetDebuggerSessionObserverTest
```
Reviewed By: hoxyq
Differential Revision: D68632974
fbshipit-source-id: 59da6d9e2d09f2c7e219c1902dd6f9b8ddfee9dc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48943
changelog: [internal]
A new helper function on Fantom flushAllNativeEvents, which will flush all pending native events.
Reviewed By: javache
Differential Revision: D68566753
fbshipit-source-id: 6cb19416e39807b9b381ff068cea5c2458101174
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48907
changelog: [internal]
Introduce new function `Fantom.scrollTo`, which will fake a scroll to particular position.
Calling the method will call onScroll event using codepath that iOS uses. It will also set C++ state so the new scroll position is observable from JavaScript.
Reviewed By: javache
Differential Revision: D68554703
fbshipit-source-id: 2fc71e96836a03ec343053ceed85764c4bc2f5c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48917
Cleaning up this flag which has already been rolled out
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D68622852
fbshipit-source-id: 5767515d02ce9804976a1363532e1e626aeae0d8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48916
Cleaning up this feature flag since we no longer require this gating. This was already fulled rulled out as default.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D68621578
fbshipit-source-id: 3fd3ad007b8beb8e2525ffa7b4da372be1dbbd94
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48877
This is a minor refactor to hoist logic that is not actually specific to the `AnimatedProps` lifecycle out of the hook named `useAnimatedPropsLifecycle`.
This will make it easier to iterate on the implementation of `useAnimatedPropsLifecycle` using a feature flag in a subsequent diff.
This has no behavior change.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D68516034
fbshipit-source-id: 2cd6d9b0f2a5c0ada10cf01c8c14ed5510fbf25a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48919
I suspect this class is unused and we should not be building it.
The same `AndroidUnicodeUtils.java` is provided by facebook/hermes instead.
Changelog:
[Internal] [Changed] -
Reviewed By: tdn120, mdvacca
Differential Revision: D68623307
fbshipit-source-id: 0a290d31e3b1103947a9dd3c46821958be9223e7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48665
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling
## This diff
- Updates files in Libraries/Utilities to use `export` syntax
- `export default` for qualified objects, many `export` statements for collections (determined by how it's imported)
- Appends `.default` to requires of the changed files.
- Updates Jest mocks of the `Platform` module, which happened to touch a lot of test files.
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/Utilities` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: huntie
Differential Revision: D68152910
fbshipit-source-id: 07f3a0957f1dbaf44f53974c6f28b273558406eb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48901
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates files in `Libraries/Text`, `Libraries/Share` and `Libraries/Settings` to use `export` syntax.
- Appends `.default` to requires of the changed files.
- Updates test files.
- Updates the public API snapshot *(intented breaking change)*
Changelog:
[General][Breaking] - Files inside `Libraries/Text`, `Libraries/Share` and `Libraries/Settings` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: huntie
Differential Revision: D68562844
fbshipit-source-id: bd71a341e33d3629121aa61549139c4b1cd62c3f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48926
# Changelog: [Internal]
Leverage [`devtools` field](https://developer.chrome.com/docs/devtools/performance/extension#devtools_object) inside [`detail` object](https://developer.mozilla.org/en-US/docs/Web/API/Performance/measure#detail) to make extension tracks work.
Right now we are only specifying track name, later we could use many more fields:
```
interface ExtensionTrackEntryPayload {
dataType?: "track-entry"; // Defaults to "track-entry"
color?: DevToolsColor; // Defaults to "primary"
track: string; // Required: Name of the custom track
trackGroup?: string; // Optional: Group for organizing tracks
properties?: [string, string][]; // Key-value pairs for detailed view
tooltipText?: string; // Short description for tooltip
}
```
In the next few diffs I will extend the spec of the local implementation for `performance.measure` and `performance.mark` to get this propagated correctly.
Reviewed By: huntie
Differential Revision: D68624603
fbshipit-source-id: 99a5d233ee1dbcd690ad8a6802ca993071f63f2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48923
# Changelog: [Internal]
Starting from this diff, React Native will emit inspector traces, the ones that will have the same UI as if it was recorded in a browser.
We are going to fake it by sending "TracingStartedInPage" event. For a corresponding logic on Chrome DevTools Frontend side, see [this](https://github.com/ChromeDevTools/devtools-frontend/blob/192673131cf3e6e0bcdb4a97bd0bd39c75f1b3c2/front_end/models/trace/handlers/MetaHandler.ts#L68-L80) as a starting point.
Because of this, custom tracks are now grouped under "Timings" track, although with a better color scheme:
- We no longer need the logic for placing tracks under arbitrary thread ids to have them grouped.
- The real support for extension tracks (custom tracks for Performance panel) will be added in the next diff.
Reviewed By: huntie
Differential Revision: D68439734
fbshipit-source-id: 8e5c525a71578375904edc6d473308eb710b5867
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48927
changelog: [internal]
Remove explicit calls to root.destroy() in favour of automated system that will call it and check for memory leaks.
Reviewed By: rubennorte
Differential Revision: D68624917
fbshipit-source-id: 44be1dee9a56ec31bea5a9eefdda086a4cb4248f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48889
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates files in `Libraries/Core` to use `export` syntax
- `export default` for qualified objects, many `export` statements for collections
- Appends `.default` to requires of the changed files.
- Changed `* as ExceptionsManager` to `ExceptionsManager` in import statements throughout product code.
- Updates test files.
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/Core` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
[General][Breaking] - `Libraries/Core/ExceptionsManager` now exports a default `ExceptionsManager` object, and `SyntheticError` as a secondary export.
Reviewed By: huntie
Differential Revision: D68553694
fbshipit-source-id: 51c9a404b2762cb1cdb5f56cae3a683ccdfffc7f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48854
Changelog: [internal]
Moves the internals to access instance handle and shadow node from public instances from `ReadOnlyNode` to `NodeInternals` so it's more obvious when people are reaching into internal APIs/state.
Reviewed By: javache
Differential Revision: D67654404
fbshipit-source-id: 1063bc9451eeacb79af34614df3be02466f93fa3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48795
# Changelog: [Internal]
Splitting `PerformanceTracer::stopTracingAndCollectEvents()` into 2 separate methods.
Once we add logic for starting and stopping tracing on `InstanceAgent`:
- We would need to stop tracing everywhere synchronously
- Populate data sources in `PerformanceTracer`, like JavaScript samples
- Collect all events from different data sources in one payload via `PerformanceTracer::collectEvents()`
Reviewed By: huntie
Differential Revision: D68331485
fbshipit-source-id: 0d6b21a522d841f7f734e2fad2e0fc533097fdee
Summary:
On older Android versions clipping doesn't have anti-aliasing by default which means that clipping with no border will always make the background not have anti-aliasing.
This is fixed by default on new Background and Border drawables since rendering logic is separated
Moving the clipping logic so it only runs when we have a border.
https://github.com/facebook/react-native/issues/41226
Changelog: [Android] [Fixed] - Fixed anti-aliasing not showing on older Android versions
Reviewed By: javache
Differential Revision: D68279400
fbshipit-source-id: e2383c71bd1ca89f66f42630b3712bb4cc5cd7ac
Summary:
This was causing links to not ellipsize and be scrollable. Gonna revert while I see if I can workaround
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D68596950
fbshipit-source-id: 432a059d0b10acbb45d34e0c98763680d280937b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48872
enableDeletionOfUnmountedViews feature flag has been enabled for 4 months with no errors on production, also it's been enabled in OSS since 0.76.
This diff removes the feature flag and fully rollout this fix
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D68511227
fbshipit-source-id: a42481c57aaab2e8c45b952af5e044bf60740df3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48843
Adds support for hsl() and hsla() funtions. This supports more modern syntax options than normalize-color, like number components, optional alpha, and fills in missing support for angle units. The underlying math was lifted pretty much directly from normalize-color though.
An aside, std::remainder for these is not guaranteed to be constexpr, but Clang is still okay with rgb function parsing to be contexpr because we never try to evaluate non-constexpr function?
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D68473990
fbshipit-source-id: 2a71d8367b22f9d1ba6a66598d40ef2683847704
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48842
This is a result of inlining isinf previously but we can never be negative infinity because we can never be less than zero.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D68474836
fbshipit-source-id: bfce78c4bd269ff2afac99c03250ede676ee1029
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48841
Right now during parsing we can ask for a next component value, with a delimeter, and even if we don't have a component value to consume, we will consume the delimeter.
This is kind of awkward since e.g. trailing comma can be consumed, then we think syntax is valid. Let's try changing this.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D68474739
fbshipit-source-id: 47a942681bc8472ca28470eba821d4d95306ae5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48839
In the last diff I mixed and matched `<legacy-rgb-syntax>` and `<modern-rgb-syntax>` a bit to keep compatiblity with `normalze-color`.
Spec noncompliant values have only been allowed since https://github.com/facebook/react-native/pull/34600 with the main issue being that legacy syntax rgb functions are allowed to use the `/` based alpha syntax, and commas can be mixed with whitespace. This seems like an exceedingly rare real-world scenario (there are currently zero usages of slash syntax in RKJSModules validated by `rgb\([^\)]*/`), so I'm going to instead just follow the spec for more sanity.
Another bit that I missed was that modern RGB functions allow individual components to be `<percentage>` or `<number>` compared to legacy functions which only allow the full function to accept one or the other (`normalize-color` doesn't support `<percentage>` at all), so I fixed that as well.
I started sharing a little bit more of the logic here, to make things more readable when adding more functions.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D68468275
fbshipit-source-id: f1dfab51b91a3f64436c2559daa3d1e8891db889
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48828
1. Rename `CSSComponentValueDelimeter` to `CSSDelimeter` bc the names are getting way too long.
2. Make the distinction between `Whitespace` and `OptionalWhitespace`. Note that for property values, and function blocks, the value parser will already remove trailing/leading whitespace, but it's weird that whitespace unlike others was not required to be present
3. Add `CSSDelimeter::CommaOrWhitespaceOrSolidus` for simpler parsing in the common pattern of alpha values, and move CSSColor function parsing to use that
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D68461968
fbshipit-source-id: 388056e47dfe6ca6003b44e82e00fe416706330b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48835
D65907786 ended up regressing a bit of the performance gains from new Background and Border Drawables. changing back to the previous approach.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D68354292
fbshipit-source-id: f2db6d7ad5c1590d5d4d8261d76281f3592f488a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48891
changelog: [internal]
add two tests covering onScroll: one for the case where onScroll is triggered multiple times during one UI tick and one where it is triggered once per UI tick.
Reviewed By: rubennorte
Differential Revision: D68499566
fbshipit-source-id: ee25227b620569e3a43038575f04b0a325e5e38b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48801
changelog: [internal]
Adds isUnique option to Fantom.dispatchNativeEvent.
isUnique controls whether only the last event of the same type and target is dispatched to JavaScript or all events are queued and dispatched.
Reviewed By: rubennorte
Differential Revision: D68416157
fbshipit-source-id: 415e7db7d258d60a6bc510d929091153bfdccb3f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48888
We have a report from OSS where Images are not displayed properly in case they are saved on disk with no extension.
We previously had a fix attempt iwith [this pr](https://github.com/facebook/react-native/pull/46971), but this was breaking some internal apps.
This second attempt should work for both cases.
## Changelog:
[iOS][Fixed] - Load images even when the extension is implicit
Reviewed By: cortinico
Differential Revision: D68555813
fbshipit-source-id: bc25970aafe3e6e5284163b663d36e00b3df3d82
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48896
This comment is not exact and should be updated.
Changelog:
[Internal] [Changed] -
Reviewed By: yungsters
Differential Revision: D68556425
fbshipit-source-id: 67427ff325809907fdeba1c6a90b84b97713bf5e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48894
## Motivation
In our efforts to migrate the RN codebase to modern Flow (to enable ingestion by modern Flow tooling) I stumbled upon the `AnimatedWeb.js` file, which does not seems to be imported anywhere throughout the monorepo.
Searching on GitHub for imports to this file in OSS projects returned no results.
In case this file has actual uses outside of Meta (e.g. in OSS), I'll abandon the diff 🙌
## This diff
- Removes `Libraries/Animated/AnimatedWeb.js` file
Changelog:
[General][Breaking] Removed `Libraries/Animated/AnimatedWeb.js` file.
Reviewed By: cortinico
Differential Revision: D68558237
fbshipit-source-id: 319b5e59eb83e518cd123b9f74642e90f0003a4a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48648
# Changelog: [Internal]
This is the pre-requisite before adding a formatter for conversion from Hermes format-agnostic API for JavaScript samples to Trace Events.
This struct will probably be used a lot around this module and big enough for a separate header.
Reviewed By: huntie
Differential Revision: D68104202
fbshipit-source-id: 93f2816de5a87471c5f7761468ccc52a34a895d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48882
Changelog: [internal]
The current hint for benchmarks is that the test body contains `unstable_benchmark` calls, but some benchmarks that need to use feature flags define their test bodies in a separate file, so the file containing the call to `unstable_benchmark` isn't the `-itest.js` one.
This adds a new hint to opt into optimized builds that uses the name of the test instead of its contents. If it contains `-benchmark` then we consider it a benchmark and do the opt in.
Reviewed By: andrewdacenko
Differential Revision: D68102300
fbshipit-source-id: 4c0909969f76b8a7d563959cccf686aefaef700d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48808
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates a handful of components in `Libraries/Components` to use `export` syntax
- `export default` for qualified objects, many `export` statements for collections (determined by how it's imported)
- Appends `.default` to requires of the changed files.
- Updates test files.
- Updates the public API snapshot *(intented breaking change)*
- Synchronizes `GoodwillVideoEditorCandidateImage.js` with www, as it was using `require`s that would result in invalid code after this Diff's changes. Added `ReactNativeImage` shim.
Changelog:
[General][Breaking] - Files inside `Libraries/Components` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: yungsters
Differential Revision: D68436611
fbshipit-source-id: 14f33e375e60429ea2340fb49ddf9dc6eb79594f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48884
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates files in `Libraries/WebSocket` to use `export` syntax
- Appends `.default` to requires of the changed files.
- Updates mocks.
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/WebSocket` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: cortinico
Differential Revision: D68554260
fbshipit-source-id: 90a660fe9e76b255171189101819253521354fda
Summary:
Found this while I was trying to make my own react native info for CI. For android Podfile.lock is being read instead of gradle.properties
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[INTERNAL][FIXED] - Fixed React native info where Podfile.lock was being read for android
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/48876
Reviewed By: blakef
Differential Revision: D68553964
Pulled By: cortinico
fbshipit-source-id: 7d6391195dab0c2230fe86fb465de6d3f94ccbef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48815
In an effort to reduce the responsibility of Cocoapods in React Native, we are moving the generation of the Reactcodegen podspec from Cocoapods itself to the codegen infrastructure.
This reduce the responsibility of Cocoapods and allow us to migrate away from it with more ease.
## Changelog:
[iOS][Changed] - Generate the ReactCodegen.podspec as part of codegen instead of as part of pod install.
Reviewed By: cortinico
Differential Revision: D68418268
fbshipit-source-id: 004ac5b6b3563bf96cc38942f2b48b6f269541c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48855
changelog: [internal]
add event category argument to Fantom.dispatchNativeEvent.
This gives tests option to control whether an event is continuous, discrete etc.
Reviewed By: rubennorte
Differential Revision: D68413879
fbshipit-source-id: f0c365df505a325440693ca7c3408dd612614946
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48871
# Changelog: [Internal]
Forward-fixing D68380665.
Requirements:
- `setUpReactDevTools` should be called before `setUpErrorHandling` to avoid React DevTools mutating `console.error` call arguments.
- `setUpReactDevTools` should be called after `setUpTimers`, because it is using `queueMicrotask`, see https://fb.workplace.com/groups/rn.panelapps/permalink/1120810879540337/.
- `setUpTimers` should be called after `polyfillPromise`, because it uses on `global.Promise`.
I went over bundles, which are not using `InitializeCore` and using either `setUpErrorHandling` or `setUpDeveloperTools` and updated their order of initialization accordingly.
Reviewed By: javache
Differential Revision: D68510100
fbshipit-source-id: 4331dcc7a7cb1dc438ca2ed5ccae49e736c41b2a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48773
This diff contains 2 fixes with regards to clickable text accessibility on Android.
1. It allows nested `Text` links to be accessible via keyboard. The accessibility here is a bit unique. The clickable text is not focused in the classical since that Android provides on `View`s (after all, the part being focused is not even a `TextView`. Its a `Span` in a `TextView`). However, it is [selected](https://developer.android.com/reference/android/widget/TextView#setSelected(boolean)), and pressing enter while it is selected will press the text, so for all intents and purposes it is focused. Some quirks here, though, are that you cannot press tab to cycle through the links in text, you have to use arrow keys. And the arrow keys no longer let you move around to the next item (as they are stuck being used to navigate the links). I *could* override this behavior but I do not see much of a point as long as one can actually get to everything on screen in a semi-logical way. Anyway, the fix here is using [`LinkMovementMethod`](https://developer.android.com/reference/android/text/method/LinkMovementMethod) to navigate between clickable spans, which is exactly what that class exists for. Note that I override this class so that touching the links does not actually highlight them like you see in the videos.
2. In the case we state update and remove the "click-ability" of the text, this diff makes it so that Explore By Touch no longer can focus on the link. The code was in the same area so I decided to just lump that together :P
Changelog: [Android] [Fixed] - Allow text links to be navigable via keyboard by default
Reviewed By: javache
Differential Revision: D68306316
fbshipit-source-id: a72145f6b60caf2a8077e1bd2ca987bdde0b82ab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48794
changelog: [internal]
Add payload argument to Fantom.dispatchNativeEvent. For example, in `TextInput.onChange` event, new value of input field must be present in the event payload.
Reviewed By: rubennorte
Differential Revision: D68410469
fbshipit-source-id: eb915f9f961efdfe9902f060173072c6259b7eea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48840
MSVC unicode handling is causing our windows test to fail. To fix,
simply replace the special characters with the their explicit UTF-16
encoding.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D68466808
fbshipit-source-id: 1bfc689972e1e5862fe6525bc48d5ebc508a95da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45552
In this diff I'm overriding the getDiffProps for ViewProps.
The goal is to verify what's the impact of calculating diffs of props in Android, starting with ViewProps.
Once we verify what are the implication we will automatic implement this diffing.
The full implementation of this method will be implemented in the following diffs
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D59969328
fbshipit-source-id: ce141528581e46e9ced4175dca040ddf8bed5ddb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48868
Original commit changeset: ac48be3305eb
Original Phabricator Diff: D68093083
Changelog: [iOS][Removed] - Removed workaround for a iOS build app running on Apple Silicon Mac(in Xcode Destination: "Mac(Designed for iPad)") TextInput crash due to serialization attempt of WeakEventEmitter
Reviewed By: javache
Differential Revision: D68452788
fbshipit-source-id: 9d3466950c43a10f36ca594997ae5a586d1a2a00
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48866
Changelog: [internal]
The current test to create a snapshot of the public API was recently modified to include `src/private` but excluding certain directories from it.
This replaces the opt-out with an opt-in mechanism, where we only use it where necessary (new DOM APIs, etc.).
Reviewed By: huntie
Differential Revision: D68496269
fbshipit-source-id: 6ae056008a6189b493cb27811d21a8619e79009d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48859
Changelog: [internal]
Just to make it easier to distinguish between public and private APIs, until we have proper support to extract that automatically.
Reviewed By: huntie
Differential Revision: D68496270
fbshipit-source-id: 83cdf95f7f33eab8835b0913cc468ccaf5e47730
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48774
[Changelog] [Internal] - Fix data race in TraceSection.h
## Issue
The `instrumentsLogHandle` variable is a static variable that is initialized lazily when the `getOrCreateInstrumentsLogHandle()` function is called. However, this initialization is not thread-safe. Multiple threads may call this function simultaneously, leading to a data race on the `instrumentsLogHandle` variable.
Reviewed By: lyahdav, javache
Differential Revision: D68366837
fbshipit-source-id: d61b85a0299a8d42b9fbcfdbecae78eb410d748f
Summary:
Adds `getConcretePropsShared()` to `ConcreteShadowNode.h`.
I need this in Nitro Views to update state in-place without throwing away the old state object and creating a new one each time.
From reading the code it seems like you use this pattern a lot tho where you create new State objects each time - so let me know if my thing is a bad idea..
## Changelog:
- [INTERNAL] [ADDED] Add `getConcretePropsShared()` to `ConcreteShadowNode.h`
<!-- 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/48710
Test Plan: Use in Nitro
Reviewed By: sammy-SC
Differential Revision: D68495697
Pulled By: javache
fbshipit-source-id: e2caa34befcaef2191ec161442c40596cc7de132
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48509
Cleans up the following feature flags from `Animated`:
- `enableAnimatedAllowlist`
- `enableAnimatedPropsMemo`
- `useInsertionEffectsForAnimations`
This will significantly simplify some future planned work here (e.g. T209740497).
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D67867115
fbshipit-source-id: adf35c70d95f42c240342fda3b4f2e9b4bdfe30a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48851
Changelog: [internal]
Remove the feature flag to disable the event loop on bridgeless, as we no longer have a use case for it. From now on, we can be 100% certain that Bridgeless == Event Loop!
Reviewed By: sammy-SC
Differential Revision: D68270102
fbshipit-source-id: c661bf11f51d4044f9f485b971c43f03197e2983
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48853
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates the `ReactNativeVersion` template to use `export` syntax.
- Regenerates the `ReactNativeVersion.js` file with the new template.
- Updates jest mock.
- Updates the public API snapshot *(intented breaking change)*
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D68492723
fbshipit-source-id: daa55d3d553aca562cf2e091cd24546681a8db2f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48856
Refactor setLayoutAnimationEnabledExperimental in BridgelessUIManager.js to be a no-op in the new architecture
Changelog:
[Android][Fixed] - Make `setLayoutAnimationEnabledExperimental` a no-op in Bridgeless
Reviewed By: javache
Differential Revision: D68313694
fbshipit-source-id: 7a79fad72b1eeda5af3ff629a609d53e4f08f26d
Summary:
changelog: [internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/48793
Adds new method `dispatchNativeEvent` to Fantom give option to dispatch fake native events.
The API is expanded in subsequent diffs. The version introduced in this diff supports only dispatching event without payload and without any options.
Reviewed By: rubennorte
Differential Revision: D68331986
fbshipit-source-id: 075360e1d6874794ba6df966087fbe6a0a820cbc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48767
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates a handful of components in `Libraries/Components` to use `export` syntax
- `export default` for qualified objects, many `export` statements for collections (determined by how it's imported)
- Appends `.default` to requires of the changed files.
- Updates test files.
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/Components` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: yungsters
Differential Revision: D68335872
fbshipit-source-id: eb0c67039edfe92e9e133726f6b01900dd2c2322
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48837
ViewHierarchyUtil is a class with package visibility and it is not used, let's delete it
changelog: [internal] internal
Reviewed By: shwanton
Differential Revision: D68467507
fbshipit-source-id: d1bd5b279a26fcecb4fed590ad2de75937b54aa6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48827
This teaches the CSSColor parser how to handle these functions.
There are a surprising amount of edge cases here, including many syntactic options added by the CSS Color Module 4 spec, and some technically invalid examples supported by normalize-color, sometimes working in Chrome.
I used the combination of the spec, and existing functionality and tests for `normalize-color`, with the end result supporting a superset of the functionality of both, while being a bit more permissive than either.
I still need to add support for the other color functions, and will probably want to share code here, but for now, just implemented everything for the rgb values as a start.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D68362477
fbshipit-source-id: 62973ba2f8361b6a43c7cf9a96029147f84582d2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48826
This ends up being a not uncommon pattern, so lets make it a bit easier.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D68359563
fbshipit-source-id: 94283c8815cf9dd2f6c0d52762d21232383fb311
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48825
Right now we preserve the state of the CSSSyntaxParser across multiple data type parse attempts, so long that a data type parser consumes an additional component value. This requires data type parsers to be careful to not consume additional forward tokens if it may lead to parse error. We can make this model a lot simpler by instead resetting the parser to original state on data type parse error.
We also introduce `peekComponentValue`, and visitor-less `consumeComponentValue` as a convenience, to allow data type parsers to view future component values without advancing, even if the data type parser does return a value, without needing to manually clone the parser.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D68357624
fbshipit-source-id: 6ff77bab8ac9eabd5dccea52daa85bbd32b5f2b6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48823
This diff is fixing the execution of Events that are sent early in the rendering of surfaces.
This diff fixes a bug in the queueing of events that are built with not surfaceId (-1), the fixes is to call getSurfaceManagerForView() to retrieve the proper surfaceId (as we do in the execution of events)
calling getSurfaceManagerForView() has a perf hit, we believe this won't be a problem because this method will only be called in edge cases (no surfaceId and early execution of events)
changelog: [Android][Fixed] Fix execution of early InteropEvents
Reviewed By: shwanton, lenaic
Differential Revision: D68454811
fbshipit-source-id: a79be0b392004e645c48d1683bba774b6b597ca0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48819
Currently, `VirtualizedList-test.js` has a subtle dependency on how asynchronous operations are queued. Specifically, it depends on...
- `Batchinator` to use `setTimeout` for...
- `InteractionManager` to use `setImmediate` for...
- `InteractionManager` to resolve a promise via microtask.
As a consequence, any changes to this queueing logic (e.g. eliminating the unnecessary `setImmediate` and microtask) unnecessarily breaks these unit tests.
This changes the Jest unit tests to instead use `jest. advanceTimersToNextTimer(<step>)` instead of `jest.runOnlyPendingTimers()` so that the unit tests are no longer dependent on these specific queueing logic.
Changelog:
[Internal]
Reviewed By: NickGerleman
Differential Revision: D68449850
fbshipit-source-id: 382b1c0a0d8fade873ccf17a9deb3622a83b8163
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48800
This just converts yet another class from Java to Kotlin
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D68417564
fbshipit-source-id: 167a27f7f80125cc81a4a0ad57952f1149ef4d7d
Summary:
This collapses all the 0.77 changelog from the various RCs into a single entry.
## Changelog:
[Internal] [Changed] -
Pull Request resolved: https://github.com/facebook/react-native/pull/48811
Test Plan: N/A
Reviewed By: robhogan
Differential Revision: D68438948
Pulled By: cortinico
fbshipit-source-id: 0ef57432901198602863e9769cd2662a0f4e30f6
Summary:
This PR adds missing nonnull annotations to make working with Swift better 👍🏻
## Changelog:
[IOS] [ADDED] - Missing nonnull annotations for RCTArchConfiguratorProtocol, RCTUIConfiguratorProtocol.h
Pull Request resolved: https://github.com/facebook/react-native/pull/48817
Test Plan: CI Green
Reviewed By: cortinico, dmytrorykun
Differential Revision: D68443519
Pulled By: cipolleschi
fbshipit-source-id: 53bf128c65421789034f45f637a08ed996684c6f
Summary:
The `ReactNativeVersion.h` file currently contains a `struct` that holds the React Native version (e.g. `1000.0.0`, as individual ints).
For some libraries, we need to conditionally compile out code when using an older React Native version, and that's where library authors usually set compiler flags that hold the react native version - those are usually resolved using a `node require.resolve` script in the Podspec or build.gradle, adding unnecessary complexity.
With this PR this becomes obsolete as we now create a `#define` that holds the React Native version directly - so e.g.
```cpp
#define REACT_NATIVE_VERSION_MAJOR 0
#define REACT_NATIVE_VERSION_MINOR 67
#define REACT_NATIVE_VERSION_PATCH 1
```
..which we can then use to conditionally compile some code in our libraries:
```cpp
#include <React/ReactNativeVersion.h>
#if REACT_NATIVE_VERSION_MINOR >= 76
// new stuff
#else
// fallback
#endif
```
## Changelog:
[INTERNAL] [ADDED] - Added `REACT_NATIVE_VERSION_*` C++ defines to `ReactNativeVersion.h`
<!-- 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/48813
Test Plan: Just import the header in a library and check if the defines exist!
Reviewed By: cortinico
Differential Revision: D68441049
Pulled By: javache
fbshipit-source-id: 55ac8875e1a3f8ad8b9d12795fed4204e9c5bb77
Summary:
As in the title, follow up from https://github.com/facebook/react-native/issues/48075 which added unit tests for this class.
## Changelog:
[INTERNAL] - Convert com.facebook.react.modules.network.ResponseUtil to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/48781
Test Plan:
```bash
./gradlew :packages:react-native:ReactAndroid:test -Dtest.single=com.facebook.react.modules.network
```
Reviewed By: javache
Differential Revision: D68393938
Pulled By: Abbondanzo
fbshipit-source-id: ed214b29ad9248c2da2e2653e75447b0a7e05a26
Summary:
Was looking into improving some of the type definitions for the `ToastAndroid` component and found out also that some of the options don't work anymore from API 30 – I revamped a bit these definitions to reflect that as I saw questions about it online. These updates could also be added to the website later.
## Changelog:
[GENERAL][CHANGED] - Improve ToastAndroid jsdocs
Pull Request resolved: https://github.com/facebook/react-native/pull/48779
Test Plan: Check the jsdocs look good when using the `ToastAndroid` component in the code.
Reviewed By: cortinico
Differential Revision: D68393949
Pulled By: Abbondanzo
fbshipit-source-id: 4be318062483db5be3825b7b21f540030f6c5b10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48765
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates a handful of components in `Libraries/Components` to use `export` syntax
- `export default` for qualified objects, many `export` statements for collections (determined by how it's imported)
- Appends `.default` to requires of the changed files.
- Updates test files.
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/Components` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: cortinico
Differential Revision: D68330077
fbshipit-source-id: 6bf00c82f72dbcaaa26470d7ea0917639fc3de4a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48763
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates files in `Libraries/BugReporting`, `Libraries/vendor`, `Libraries/Vibration` and `Libraries/YellowBox` to use `export` syntax
- `export default` for qualified objects, many `export` statements for collections (determined by how it's imported)
- Appends `.default` to requires of the changed files.
- Updates Jest mocks.
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/BugReporting`, `Libraries/vendor`, `Libraries/Vibration` and `Libraries/YellowBox` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: cortinico
Differential Revision: D68329075
fbshipit-source-id: 7079a54ce3631171f8d7559bc33cab014df1d16d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48761
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates files in Libraries/Blob to use `export` syntax
- `export default` for qualified objects, many `export` statements for collections (determined by how it's imported)
- Appends `.default` to requires of the changed files.
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/Blob` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: cortinico
Differential Revision: D68326103
fbshipit-source-id: ff0b5e0125987ed44b34c35f39af1eefa9799d8f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48799
This change moves the same scripts we have to prepare the HelloWorld project to RNTester.
This is something we forgot to do when we were decoupling the reacrt-native from the community CLI.
This is also the base to start deprecating cocoapods and add more configuration steps for the project.
## Changelog:
[Internal] - Copy cli.js script from HelloWorld to RNTester
Reviewed By: cortinico
Differential Revision: D68413419
fbshipit-source-id: 7cf19d86bd3c1beb0c1e7f3380331174352a1651
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48787
For reasons that will become clear in the next diff, I'm adding more assertions for things like LogBox being called, and the console being called. I also updated the patterns of things like `toHaveBeenCalledWith` vs `toBeCalledWith` so they're consistent throughout the file.
## Changelog:
[internal] - Add tests to ExceptionManager
Reviewed By: hoxyq
Differential Revision: D68397529
fbshipit-source-id: b05073630969c40a86546a6f5c4244836b636ee1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48784
React requires React DevTools to be the first patch for console methods, because it assumes it is the _last_ on the stack called before calling the real console.
This is because React DevTools adds additional formatting for things like StrictMode dimming, and component stack formatting for browser specific consoles like Chrome and Firefox, where the DevTool extension runs.
If it's not the first patch, then other patches (like logging, or LogBox) will pick up the DevTools additions and include them, which breaks other tools (like the issue show in the screen below).
This diff ensures React DevTools is patched before the React Native console reporter by moving it to `setupErrorHandling`.
## Changelog:
[General] [Fixed] - Always patch React DevTools first so StrictMode dim chars are excluded from logs/logbox.
## Other places?
I'm not sure how we should handle this for the console polyfill or inside useAlwaysAvailableJSErrorHandling yet.
## Screens
### Before
3 errors, 1 with ANSI dim chars:
{F1974436874}
### After
Just 1:
{F1974436879}
Reviewed By: hoxyq
Differential Revision: D68380665
fbshipit-source-id: 4f5353bb8da0038088c05ef7414bf91e965c73e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48785
## Overview
This change adds code frames for component stacks if it differs from the call stack frame.
## Background
After adding native stack based stack frames, which we already symbolicate, we had the capability to show a code frame for component stacks as well as the stack frame (if they differ).
However, this usually wasn't that useful, because the native component stack was unlikely to be more useful than the component stack (see the comparisons below for key errors).
## Owner stacks
With owner stacks the component frame is a lot more useful and in many cases are better at showing the location than the call stack frame.
## Example Screens
Before:
{F1974436645}
After (with owner stacks):
{F1974436723}
Changelog:
[General][Added] - Add owner stack code frames to LogBox
Reviewed By: hoxyq
Differential Revision: D68285627
fbshipit-source-id: 541cecbd4786fffd1970d2e85e659757e3f81604
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48782
React currently has a babel transform to replace all `console.error` calls with a special function for RN and www. The function adds component stacks, which doesn't make sense in an owner stack world because:
- not all console.error calls are replaced, creating inconsistency
- oss web users don't append component stacks to console.log any more
- component stacks can be accessed for DEV modals like logbox with `captureOwnerStack`
- owner stacks are already added to the console with createTask if you use console.error directly
- the redirection is the single greatest source of fragility in the logbox reporting pipeline
So we're removing this as part of the owner stack rollout. This should only be enabled with owner stacks.
## Example Screen
Before:
{F1974436644}
After:
{F1974436645}
## Changelog:
[General] [Added] - Add full owner stack support to React Native
Reviewed By: hoxyq
Differential Revision: D68285628
fbshipit-source-id: 9772593d7ac6e012392d18c6796580c14c852074
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48770
Splits CSSValueParserTest to be file per data type to better match new structure, before we introduce more complexity and tests for CSS colors.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D68351049
fbshipit-source-id: 1a4218e49c8c8adb056fac1dd67f064a4f890775
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48769
Must function notations do not require delimiting commas, with color function "legacy" syntax being an exception.
E.g.
```
rgb() = [ <legacy-rgb-syntax> | <modern-rgb-syntax> ]
rgba() = [ <legacy-rgba-syntax> | <modern-rgba-syntax> ]
<legacy-rgb-syntax> = rgb( <percentage>#{3} , <alpha-value>? ) |
rgb( <number>#{3} , <alpha-value>? )
<legacy-rgba-syntax> = rgba( <percentage>#{3} , <alpha-value>? ) |
rgba( <number>#{3} , <alpha-value>? )
<modern-rgb-syntax> = rgb(
[ <number> | <percentage> | none]{3}
[ / [<alpha-value> | none] ]? )
<modern-rgba-syntax> = rgba(
[ <number> | <percentage> | none]{3}
[ / [<alpha-value> | none] ]? )
```
Theoretically, this should mean an expression like `rgb(1, 2 0)`, which mixes both comma and whitespace delimeters would be malformed, but both Chrome, and RN's existing `normalize-color` package support this, so to make this pattern easier, we add the ability to scan based on using either whitespace or comma as component value delimiter.
Interestingly, the current spec revision also allows `rgb` function with alpha, or `rgba` function without alpha, which Chrome correctly supports, but `normalize-color` does not.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D68349385
fbshipit-source-id: 05cd756ee20227af4d9ec20edc9e7cfc8cc2c071
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48768
Right now, if something like `CSSColor` accepted a function notation block (e.g. for `rgb()` syntax), it is given a syntax parser which may extend beyond the scope of the current function block.
This is confusing, but also problematic for the `CSSSyntaxParser` block visiting logic to validate a correct scope exit.
This change makes it so that the `CSSSyntaxParser` passsed to `CSSDataTypeParser` for function and simple blocks is limited to the syntax within the given block. This prevents extra visiblity beyond the block we are trying to parse, and allows the function/simple block visitor to reliably fail parsing if the block is not correctly terminated, or there are unconsumed component values within the block not handled by the data type parser.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D68340127
fbshipit-source-id: 402f2eabdf6df7bce99223c966f22c2158103be5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48737
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates files in Libraries/AppState and Libraries/BatchedBridge to use `export` syntax
- `export default` for qualified objects, many `export` statements for collections (determined by how it's imported)
- Appends `.default` to requires of the changed files.
- Updates Jest mocks.
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/BatchedBridge` and `Libraries/AppState` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: robhogan
Differential Revision: D68275767
fbshipit-source-id: 97dc84c04a8dd9c9022e53fc4595302efc848338
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48745
This is the first step in a series of diff to make RNGP more Gradle-compliant (specifically for the sake of configuration caching).
Specifically the problem in those 2 tasks is that we're accessing `project.copy()` and other
functions from the `project` field.
The project should never be accessed at execution time. See more on this here:
https://docs.gradle.org/8.12/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution
This diff fixes it.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D68282777
fbshipit-source-id: 6d474f266b5bc50fba57c8cd478173c995864bbc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48764
When working on the [commit](https://github.com/facebook/react-native/commit/eced906bedf0c3d2bbc592cc27965c88278abae3) I forgot a bit that makes sure the New Architecture was the default.
This is change set the New Arch as default properly in RCTAppDelegate. Plus it refreshes the GHA caches by updating the Podfile.lock
## Changelog:
[Internal] - Ensure that the New Arch is turned on in RCTAppDelegate
Reviewed By: alanleedev
Differential Revision: D68329797
fbshipit-source-id: 9df5f805f7d3506129909f0adae5ff597f33ce3c
Summary:
In the `displayModeToInt()` function, there is no default case defined which is causing the following warning in React Native Windows when trying to build on the New Architecture:
```
##[error]node_modules\react-native\ReactCommon\react\renderer\uimanager\primitives.h(163,1): Error C2220: the following warning is treated as an error
D:\a\_work\1\s\node_modules\react-native\ReactCommon\react\renderer\uimanager\primitives.h(163,1): error C2220: the following warning is treated as an error [D:\a\_work\1\s\vnext\Microsoft.ReactNative\Microsoft.ReactNative.vcxproj]
##[warning]node_modules\react-native\ReactCommon\react\renderer\uimanager\primitives.h(163,1): Warning C4715: 'facebook::react::displayModeToInt': not all control paths return a value
D:\a\_work\1\s\node_modules\react-native\ReactCommon\react\renderer\uimanager\primitives.h(163,1): warning C4715: 'facebook::react::displayModeToInt': not all control paths return a value [D:\a\_work\1\s\vnext\Microsoft.ReactNative\Microsoft.ReactNative.vcxproj]
```
Adding the default case removes the warning and resolves the issue. Not sure if using the -1 value in this case is appropriate.
## 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] - Add default case to `displayModeToInt()` function
Pull Request resolved: https://github.com/facebook/react-native/pull/48711
Test Plan: Tested on React Native Windows New Arch application and was able to build successfully.
Reviewed By: javache
Differential Revision: D68265335
Pulled By: rshest
fbshipit-source-id: 4724a4c7391b9bf651a122f5de227a0c5e0b6212
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48753
[This commit](https://github.com/facebook/react-native/commit/cc89ddd50bed869013082ad98eb0555a386cf7c9) introduced a dependency between RCTFabric and RCTAnimation because RCTFabric is now using `RCTInterpolateColorInRange` which is defined in `RCTAnimation`.
To unblock the CI, I'm adding the dependency to the RCTFabric.podspec
However, I'm not convinced that this is the proper fix. We should move the function to a common dependency between RCTFabric and RCTAnimation. Probably in `RCTUtils`.
## Changelog:
[Internal] - Fix CI by making RCTFabric depend on RCTAnimation
Reviewed By: GijsWeterings
Differential Revision: D68322935
fbshipit-source-id: 57c8833e348fb69dc1b1703ffeedd3383405b4f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48754
The React-FabricComponent was importing some non-existent files when we build for iOS with cocoapods.
This change fixes it.
## Changelog
[Internal] - Only include ReactCommon and ios platform for TextInput
Reviewed By: GijsWeterings
Differential Revision: D68319960
fbshipit-source-id: 45ddd7765f6afc0efef6dc1dadea782871fbd779
Summary:
- Adds support for color transition hint syntax in linear gradients. e.g. `linear-gradient(red, 20%, green)`
- Adds `px` support. Combination of `px` and `%` also works.
- Simplified color stops parsing.
- The `processColorTransitionHint` and `getFixedColorStops` is moved to native code so it can support combination of `px` and `%` units as it requires gradient line length, which is derived from view dimensions and gradient line angle.
- Follows CSS [spec](https://drafts.csswg.org/css-images-4/#coloring-gradient-line) (Refer transition hint section) and implementation is referred from [blink engine source](https://github.com/chromium/chromium/blob/a296b1bad6dc1ed9d751b7528f7ca2134227b828/third_party/blink/renderer/core/css/css_gradient_value.cc#L240).
## Changelog:
[GENERAL] [ADDED] - Linear gradient color transition hint syntax and `px` unit support.
Pull Request resolved: https://github.com/facebook/react-native/pull/48410
Test Plan:
Added testcase in processBackgroundImage-test.ts and example in LinearGradientExample.js
<img width="500" alt="Screenshot 2025-01-05 at 11 38 13 PM" src="https://github.com/user-attachments/assets/62858bb7-1dbf-40cf-8dd4-ec0daf84ac1b" />
## Todo
Add testcases for `getFixedColorStops` and `processColorTransitionHint` in native code for both platforms. That's the only downside of moving it out of JS 🤦
Reviewed By: NickGerleman
Differential Revision: D67870375
Pulled By: joevilches
fbshipit-source-id: b91d741f3108c25df8000d220726bf180c64be60
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48718
This diff looks a bit scary, but it's mostly just structural changes of existing code and some deletion, on a well tested path 😅.
The current parser implementation tries to special case "basic" data types. When I was looking at how to add in support for more complex values, such as lists, function notations, and more compounded types, this distinction ends up not making much sense.
Instead of treating some types as basic, this diff instead moves to a model where a user can declare any structure as a `CSSDataType`, so long as they also supply a parser, which may be visited when iterating through CSS syntax blocks (preserved tokens, function blocks, or simple blocks, which probably won't be used). The user then specifies a list of supported CSS data types to parse, which invokes said parser, calling any defined methods for specific syntax. E.g.
```cpp
struct CSSNumber {
float value{};
};
template <>
struct CSSDataTypeParser<CSSNumber> {
static constexpr auto consumePreservedToken(const CSSPreservedToken& token)
-> std::optional<CSSNumber> {
if (token.type() == CSSTokenType::Number) {
return CSSNumber{token.numericValue()};
}
return {};
}
// Could also accept function block here as well (e.g. for future math
// expressions)
};
static_assert(CSSDataType<CSSNumber>);
```
```cpp
// Can be one of std::monostate (variant null-type), CSSWideKeyword,
// CSSNumber, CSSLength, or CSSPercentage. In this case, a CSSLength.
auto value = parseCSSProperty<CSSNumber, CSSLength, CSSPercentage>("5px");
```
This breaks a whole lot of assumptions I made a year ago, especially around `CSSValueVariant` which must now be able to handle arbitrary values. For now, for the sake of simplicity, I threw this out, and migrated parser code to use plain-old `std::variant`, which has a downside of being a bit less optimized in terms of storage. I also ended up completely throwing out `CSSDeclaredStyle`, since it would majorly need to change, and we're not going to be migrating style storage quite yet. This change also broke the `CSSProperties.h` property definitions and parsing shorthand a bit, which we will need for value processing later. I also opted to delete this for now (a big centralized list is the wrong structure anyways), but will likely copy bits from its source history later.
Another particular hairy bit, that likely won't bite us in practice, is that some strings may be parseable under different data types. This just adds caller requirement to order the types correctly, instead of precedence being implemented as part of the parser.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D68245734
fbshipit-source-id: 132b11053cf41f57483c89176a9a6dceebb69fad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48716
`transparent` is specced as a special `<named-color>` outside the table the others were derived from. Let's add it, since it is supported today by `normalizeColor`.
https://www.w3.org/TR/css-color-4/#named-colors
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D68246770
fbshipit-source-id: 3ff7ed68ebb3d6bc59b24a25d35342620670f0c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48691
We don't intent to use the prealpha logic in the near future so it makes sense to remove it for
to simplify our already complicated release process. We can always revive it if we wish.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D68206014
fbshipit-source-id: f05eeae3997d52df1127852e03437a387a01f5ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48739
Follow-up to https://github.com/facebook/react-native/pull/48603
I realized there is one last `tasks.creating` invocation inside `hermes-engine` that needs migration. This fixes it.
Changelog:
[Internal] [Changed] -
Reviewed By: alanleedev
Differential Revision: D68276984
fbshipit-source-id: d58cf64cf41c7943464f15d12c7a04c3cc43ec7d
Summary:
https://github.com/facebook/react-native/issues/48225 fixed the same problem on Mac Catalyst build, but this crash also happen on a iOS build app running on Apple Silicon Mac.
The weak event emitter in AttributedString attributes is causing a serialization error when typing into a TextInput in a iOS build app running on Apple Silicon Mac.
## Changelog
[iOS][Fixed] - Workaround for a iOS build app running on Apple Silicon Mac(in Xcode Destination: "Mac(Designed for iPad)") TextInput crash due to serialization attempt of WeakEventEmitter
## 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
Pull Request resolved: https://github.com/facebook/react-native/pull/48583
Reviewed By: javache
Differential Revision: D68093083
Pulled By: cipolleschi
fbshipit-source-id: ac48be3305eb01ff2b62d63283b929e8ab6b250c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48543
Introduces a shared interface for methods that need to be called by the `ReactScrollViewAccessibilityDelegate`
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D67948151
fbshipit-source-id: 9bafaa0b5f9ad5ba2fd73b7b1929d784fa4951c9
Summary:
Since we updated Gradle, I've noticed several warnings related to configuration avoidance API:
https://docs.gradle.org/current/userguide/task_configuration_avoidance.html
We should be using tasks.registerting rather than tasks.creating as this is going to break in Gradle 9/10.
This PR fixes it.
## Changelog:
[INTERNAL] -
Pull Request resolved: https://github.com/facebook/react-native/pull/48603
Test Plan: CI
Reviewed By: javache
Differential Revision: D68270870
Pulled By: cortinico
fbshipit-source-id: 0ed44d903692c20d102143082fd0939f4dbeaa88
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48712
Currently, all scroll events can be throttled by the `scrollEventThrottle` value when the intention is only to throttle `onScroll` calls. As a result, the scroll view helper unintentionally drops events unrelated to scrolling, like momentum begin/end. It's imperative that these momentum events dispatch so the scroll view does not lock itself in an "animated" state on the JS side; if locked in an animation state, children of the scroll view will not receive touch events. This can happen when the throttle is sufficiently high and momentum scrolling completes before the throttle time has elapsed.
Changelog:
[Android][Fixed] - Scroll view throttle no longer impacts events other than `onScroll`
Reviewed By: javache, rshest
Differential Revision: D68234045
fbshipit-source-id: d5c11412d3f273811a45e6f61af08d3fcf9f61d5
Summary:
Continuing our usual journey, this time migrating MessageQueueThread. Was not expecting to see that many assertions in ReactContext.
One important thing to note on this PR: I had to add an extra Throw RuntimeException to `startNewBackgroundThread`. It already had one from the`dataFuture.getOrThrow()`, but if your thread is not associated with a Looper, calling `myLooper` (Line 203 of MessageQueueThreadImpl) Can return null. Until now, this would have been a `NPE`, i just decided to make it a `RuntimeException` with the message `Looper not found for thread`. Let me know if you want me to make that function return a nullable, or throw another message or exception, or if you want me to treat Looper as Nullable in the whole class.
## Changelog:
[INTERNAL] [FIXED] - Migrate MessageQueueThread and MessageQueueThreadImpl to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/48652
Test Plan: <img width="1318" alt="Screenshot 2025-01-13 at 21 03 00" src="https://github.com/user-attachments/assets/462cc8af-4648-4437-9260-5ffa6c69e763" />
Reviewed By: tdn120
Differential Revision: D68155120
Pulled By: rshest
fbshipit-source-id: 1082a832df5b1d8ee64ca7be26e4b85e79152f88
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48723
## Changelog:
[Internal] -
In certain scenarios `TouchEvent` can be initialized with "unexpected" event actions, such as `ACTION_SCROLL`.
This caused an exception , even though such scenarios may be legitimate.
Reviewed By: javache
Differential Revision: D68265040
fbshipit-source-id: d31881e03d9110bb4f6af38548a4f73a41c54d2b
Summary:
The testing script is making unnecessary call to `input keyevent 82` which causes the Android device to
open the menu.
## Changelog:
[Internal] [Changed] -
Pull Request resolved: https://github.com/facebook/react-native/pull/48707
Test Plan: Tested local with local device
Reviewed By: cipolleschi
Differential Revision: D68215641
Pulled By: cortinico
fbshipit-source-id: 3e2653d8aa0c1e6606d9921f7b3794d0d27ef3f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48715
{D68154908} fixed a problem with the `onAnimatedValueUpdate` listener not being correctly attached if `__attach` were called before `__makeNative` (which sets `__isNative` to true).
We're potentially seeing production symptoms of stuttering interactions and user responsiveness, after queuing up many operations. Our hypothesis is that in scenarios where `ensureUpdateSubscriptionExists` is being called during `__makeNative` (instead of during `__attach`), a backup of operations occurs leading to these symptoms.
This diff attempts to validate and mitigate this hypothesis by deferring `ensureUpdateSubscriptionExists` to when an `AnimatedValue` instance has had both `__attach` and `__makeNative` invoked.
Changelog:
[Internal]
Differential Revision: D68236594
fbshipit-source-id: 2089100a773ebfc161fb5b567123eb58a893939f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48708
{D68171721} [facebook/react-native#48678](https://github.com/facebook/react-native/pull/48678) mitigated the bug that necessitated this revert.
Changelog:
[General][Changed] - (Reapply) The `AnimatedNode` graph will not occur during the insertion effect phase, which means animations can now be reliably started during layout effects.
Reviewed By: sammy-SC
Differential Revision: D68217144
fbshipit-source-id: 6796440f2839d897158528642e07869951651327
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48703
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling
## This diff
- Updates files in Libraries/Alert and Libraries/ActionSheetIOS to use `export` syntax
- `export default` for qualified objects, many `export` statements for collections (determined by how it's imported)
- Appends `.default` to requires of the changed files.
- Updates Jest mocks of the related modules
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/Alert` and `Libraries/ActionSheetIOS` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Differential Revision: D68210738
fbshipit-source-id: a984034b165908f75485f2bad33fcccadd865494
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48678
While diagnosing a recent issue in which `AnimatedValue` instances were not being correctly updated as expected, the insertion effects feature flag was identified as a root cause.
Upon further investigation, it appears that this is because the `onUserDrivenAnimationEnded` listener was not implemented the same way in the two feature flag states:
- When `useInsertionEffectsForAnimations` is disabled, `useAnimatedProps` listens to `onUserDrivenAnimationEnded` in a passive effect, after all nodes have been attached.
- When `useInsertionEffectsForAnimations` is enabled, `useAnimatedProps` listens to `onUserDrivenAnimationEnded` in an insertion effect when attaching nodes.
The bugs occurs because `useAnimatedProps` checks whether native driver is employed to decide whether to listen to `onUserDrivenAnimationEnded`. However, we do not know whether native driver will be employed during the insertion effect. (Actually, we do not necessarily know that in a passive effect, either... but that is a separate matter.)
This fixes the bug when that occurs when `useInsertionEffectsForAnimations` is enabled, by moving the listening logic of `onUserDrivenAnimationEnded` into a passive effect. This is the same way that it is implemented when `useInsertionEffectsForAnimations` is disabled.
Changelog:
[Internal]
Reviewed By: javache, sammy-SC
Differential Revision: D68171721
fbshipit-source-id: 50b23348fd4641580581cacebc920959651f96a7
Summary:
Whenever I run `yarn lint --fix` I noticed that this test is not formatted correctly. This fixes it.
## Changelog:
[Internal] [Changed] -
Pull Request resolved: https://github.com/facebook/react-native/pull/48692
Test Plan: CI
Reviewed By: sammy-SC
Differential Revision: D68207001
Pulled By: cortinico
fbshipit-source-id: 2a6c44ca02249f6662b03c87f0c4d4f3eb5a3054
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48690
We don't intent to use the prealpha logic in the near future so it makes sense to remove it for
to simplify our already complicated release process. We can always revive it if we wish.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D68205691
fbshipit-source-id: 22a3416335052a4bf6a76faa6e6af622254a6e56
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48689
We don't intent to use the prealpha logic in the near future so it makes sense to remove it for
to simplify our already complicated release process. We can always revive it if we wish.
Changelog:
[Internal] [Changed] - RNGP - Cleanup prealpha logic from the Gradle Plugin
Reviewed By: cipolleschi
Differential Revision: D68205665
fbshipit-source-id: 81d5257544df97b566421164944e3b6e71f06635
Summary:
In the old arch, stylistic sets were supported however in the new arch support was not added. It seems that fontVariant support was actually initially missed on iOS fabric however a limited version was added in https://github.com/facebook/react-native/pull/44112 . I referenced that PR and also old arch implementation for these changes.
<img width="480" alt="Screenshot 2025-01-14 at 11 15 18 AM" src="https://github.com/user-attachments/assets/ec32a356-fadd-4281-83b9-15871bbcd18f" />
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [ADDED] - Support stylistic sets for fontVariant
Pull Request resolved: https://github.com/facebook/react-native/pull/48674
Test Plan:
- Verified that the "Unsupported FontVariant" native log no longer displays on both platforms
- On iOS was easy to test in the tester app as SF supports stylistic sets by default:
```
<Text>
Stylistic{'\n'}
<Text>Normal: ${'\n'}</Text>
<Text style={{fontVariant: ['stylistic-four']}}>
Stylistic Four: $
</Text>
</Text>
```
<img width="391" alt="Screenshot 2025-01-14 at 11 59 29 AM" src="https://github.com/user-attachments/assets/1ede258e-783f-448f-8300-4c8c710796ef" />
- On Android I could not find any system fonts that support stylistic sets by default so I added Raleway and confirmed with a W character

I did not add font variant example to the tester apps as I felt it could be confusing for people at a glance to understand why there is only a system font example on iOS and why I chose the specific stylistic set.
Reviewed By: cipolleschi
Differential Revision: D68205738
Pulled By: javache
fbshipit-source-id: 03ce572d3c8ecafca71fe00fc0e88eeafc2558bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48664
Simplify ViewManager base-class by making `ViewManager`'s delegate non-nullable and using a single path for updating properties.
The ViewManagerDelegate API can map back to the original ViewManagerSetter API transparently, allowing us to remove the codepath from `ViewManagerPropertyUpdater`.
Changelog: [Android][Removed] `ViewManagerPropertyUpdater.updateProps` is deprected, use the related ViewManager APIs instead
Reviewed By: mdvacca, rshest
Differential Revision: D68120420
fbshipit-source-id: cd8b906dc36d4803dbe09ee0283654285eb81fd4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48658
Migrate to Kotlin before I make further changes to this. Generics are really tricky due to our previous usage of raw generics on the Java side, but were worked around by some combination of unchecked cast and `Nothing`
Changelog: [Internal]
Reviewed By: mdvacca, rshest
Differential Revision: D68102210
fbshipit-source-id: 90013f09db0826f571a4e2a84132ae3b49fa299d
Summary:
This change improves the E2E testing by downloading the iOS RNTesterApp that is built in CI instead of building it locally. This should let us save 10 to 20 minutes when we test a new release.
## Changelog:
[Internal] - Use the RNTester app built in CI for release testing on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/48637
Test Plan:
- build the app in ci
- run `yarn test-e2e-local -c <my-token>` and `yarn test-e2e-local -h false -c <my-token>` and verify that the iOS app is not built, but run in the simulator
Reviewed By: cortinico
Differential Revision: D68161477
Pulled By: cipolleschi
fbshipit-source-id: 577d110f9ff0197a2d3348a08a60e60a4d0a752b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48547
For some unknown reason, we have been swallowing [`requestFocus`](https://developer.android.com/reference/android/view/View#requestFocus(int) calls since `TextInput` is a controlled component - meaning you can control this components value and focus state from JS. This decision was originally made pre 2015 and I cannot find the reason why
I do not think this makes sense. We can still request focus from JS, while allowing the OS to request focus as well in certain cases and we would still be controlling this text input.
This is breaking keyboard navigation. Pressing tab or arrow keys will no-op if the next destination is a `TextInput`. This is because Android will call `requestFocus` from [here](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/view/ViewRootImpl.java;l=7868?q=performFocusNavigation) when handling key events. Notably, Explore By Touch (TalkBack) swiping gestures WOULD focus `TextInputs` since they go through `ExploreByTouchHelper` methods which we override to call the proper `requestFocusInternal()` method.
**In this diff**: I move the logic in `requestFocusInternal()` into `requestFocus`.
Changelog: [Android] [Fixed] - TextInputs can now receive focus via external keyboard
Reviewed By: NickGerleman
Differential Revision: D67953398
fbshipit-source-id: 506006769a7c8a63f0a9b7ce27cfbe8578777790
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48677
E2E tests are flaky again.
Let's bump maestro to see if stability improves.
This will also remove some noise from the logs, make them easier to read.
## Changelog
[Internal] - Bump maestro version
Reviewed By: cortinico
Differential Revision: D68160005
fbshipit-source-id: 40a25f974dfda75785bf08d8d236e771b44d13cf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48672
## Changelog:
[General] [Fixed] - Buttons becoming unresponsive when transform is animated
# The problem
D67872307 changes when `ensureUpdateSubscriptionExists` is called to in `__attach`. This breaks the functionality because `__attach` is called before flag `__isNative` is set and subscriptions are never setup.
# Fix
The diff sets up subscriptions in `__makeNative` method.
Reviewed By: yungsters
Differential Revision: D68154908
fbshipit-source-id: e2ac108b064a66dda08902653d6bd20286f92458
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48666
The New Architecture sample is getting too big and the two views are not visible anymore.
I'm fixing this but having buttons side by side.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D68153245
fbshipit-source-id: 5557fd40f81078fe3994d8efe0e73784e043ed78
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48670
The `LICENSE-docs` was needed when this repo was also containing the reactnative.dev docs.
As this is not the case anymore, this file is unncessary.
Changelog:
[Internal] [Changed] - Remove unnecessary LICENSE-docs
Reviewed By: cipolleschi
Differential Revision: D68156336
fbshipit-source-id: 489bf2cb95916c20eb61bfb00e34b8e271bc08e3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48656
While working on 0.78, I realize we were not testing the template app with JSC.
This change should fix this.
## Changelog:
[Internal] - Disable Hermes for the JSC E2E tests with Maestro
Reviewed By: cortinico, fabriziocucci
Differential Revision: D68147849
fbshipit-source-id: 4fbe005b5d04d6163a37041d1bd57fd48a9dfda8
Summary:
On bridgeless mode, `reactHost` is kept in memory even after destroying the `DefaultReactNativeHost` in brownfield scenario. Since it keeps references to the modules, they are not deallocated, and their `initialize` methods are not fired again when creating new instance of `react-native` later. It breaks the behavior of e.g. `react-native-screens`, which wants to listen for mutations and should get new `FabricUIManager`: https://github.com/software-mansion/react-native-screens/blob/20b7e83782cd5f79ddd0d61dadc13eeb4db4b258/android/src/main/java/com/swmansion/rnscreens/ScreensModule.kt#L45.
In this commit we change the `DefaultReactNativeHost.clear()` method to also invalidate the instance retained inside `DefaultReactHost`
## Changelog:
[ANDROID] [FIXED] - Make DefaultReactNativeHost.clear() also invalidate DefaultReactHost
Pull Request resolved: https://github.com/facebook/react-native/pull/48338
Test Plan: In brownfield scenario, destroy the instance of RN and see that modules are also destroyed.
Reviewed By: cipolleschi
Differential Revision: D67977140
Pulled By: cortinico
fbshipit-source-id: 1804f093ab1a905bef499078ddec32a13c50cc85
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48659
Changelog:
[Internal] - Replaced ExactReactElement_DEPRECATED with React.Node as a children type in ScrollViewStickyHeader
Reviewed By: fabriziocucci
Differential Revision: D68151420
fbshipit-source-id: d4406de67176ae1fea95b8b2ea85f41dc7f5045e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48660
RN-Tester is currently instacrashing on release due to a migration to Kotlin for HermesExecutor
This fixes it.
Changelog:
[Internal] [Changed] - Fix crash for Hermes Release due to HermesExecutor migration
Reviewed By: javache
Differential Revision: D68151666
fbshipit-source-id: 31f404ec518831cf2151dc670cdf8553427ae8ab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48609
# Motivation
This is an attempt at modernizing the export syntax in some of the files in `Libraries/StyleSheet/`. It will allow these files to get properly ingested by modern Flow tooling.
# This diff
- Migrates the use of `module.exports` into `export default` for files located in `Libraries/StyleSheet/*.js`. Some files were omitted due to ballooning complexity, but will be addressed in other Diffs.
- Updating internal *require*s to use ".default", no product code seems to be affected.
- Migrating `require`s into `import`s where applicable, taking into account the performance implications (context: https://fb.workplace.com/groups/react.technologies.discussions/permalink/3638114866420225/)
- Updates the current iteration of API snapshots (intended).
- Updates `react-native-codegen`'s require of processColorArray, analogous to D42346452.
Changelog:
[General][Breaking] - Deep imports from some files in `StyleSheet/` can break when using the `require()` syntax, but can be easily fixed by appending `.default`
Reviewed By: javache
Differential Revision: D68017325
fbshipit-source-id: 3c5b94742f101db0b2914c91efab6003dba2b61a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48602
See context in D64532446 / https://github.com/facebook/react-native/pull/47086
These argument types were already consumed as nullable in various OSS libraries, which prevents correct Kotlin migration of this code.
Changelog: [Android][Changed] Deprecated ViewManagerDelegate#setProperty and ViewManagerDelegate#receiveCommand
Reviewed By: mdvacca
Differential Revision: D67277871
fbshipit-source-id: a0743584891c7b2b4b50fff11de15da0078d5a1a
Summary:
Migrating HermesExecutor and it's factory to Kotlin. Not sure if the TAG in HermesExecutorFactory is needed anymore or not, but the rest of the changes are pretty bog standard
## Changelog:
[INTERNAL] [FIXED] - Migrate HermesExecutor and HermesExecutorFactory to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/48617
Test Plan:
`./gradlew test`:
<img width="1266" alt="Screenshot 2025-01-11 at 04 01 12" src="https://github.com/user-attachments/assets/c0f1402c-796b-45fa-9ee3-41c5a5ffc356" />
Reviewed By: tdn120
Differential Revision: D68094681
Pulled By: cortinico
fbshipit-source-id: 16eae5c7c24886421cbd2cbf213295134a9c01cf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48634
Changelog: [internal]
Just a placeholder to add new tests in the future.
Reviewed By: sammy-SC
Differential Revision: D68093342
fbshipit-source-id: 1e1d7fd71865763ef66b3bb1c76ff8b8ebca9fd9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48631
This step is already carried out by [generate-artifact-executor](https://github.com/facebook/react-native/blob/main/packages/react-native/scripts/codegen/generate-artifacts-executor.js#L385) if needed.
We can remove it from cocoapods and this will make it easier to migrate away from them.
For 3rd party apps that uses a specific version of React Native, codegen is shipped in NPM as already built in the react-native/codegen package.
This change really affects only the React Native monorepo.
## Changelog
[Internal] - Remove build codegen step from cocoapods
Reviewed By: cortinico
Differential Revision: D68019743
fbshipit-source-id: 7aaf9275886ba8b86d38d943d2b26bd8eed11aa8
Summary:
While investigating https://github.com/facebook/react-native/issues/22186, some false positives showed up as some of the examples also have non-strict mode compatible code.
In this PR:
- Converting from class to functional components some TextInput and Image examples that were using `UNSAFE_` lifecycles.
- Unifying the auto-expanding example as it was exactly the same for iOS and Android.
## Changelog:
[INTERNAL] - Fix RNTester strict mode warnings for TextInput and Image examples
Pull Request resolved: https://github.com/facebook/react-native/pull/48619
Test Plan:
- Wrapped the the entry app component in `RNTesterAppShared.js` with `StrictMode` and verified that no warnings are shown anymore for the updated components.
- Checked the examples are still working as they were.
Reviewed By: fabriziocucci
Differential Revision: D68094402
Pulled By: rshest
fbshipit-source-id: e13878cb290735095afaef3d0377fd6dab33c380
Summary:
## Changelog:
[iOS] [Fixed] - Fix app becoming unresponsive when RefreshControl is used inside of <Modal />
Fixes: https://github.com/facebook/react-native/issues/48579
This is a UIKit bug. Switching to `didMoveToSuperview` resolves it.
Reviewed By: cipolleschi
Differential Revision: D68025099
fbshipit-source-id: 5d5e730f002ca93748674655a8393b770dc11611
Co-authored-by: kkafar <kacperkafara@gmail.com>
Summary:
Follow up from https://github.com/facebook/react-native/issues/48619. While investigating https://github.com/facebook/react-native/issues/22186, some false positives showed up as some of the examples also have non-strict mode compatible code.
In this PR: Converting from class to functional components some `AnExApp` examples that were using `UNSAFE_` lifecycles.
## Changelog:
[INTERNAL] - Fix RNTester strict mode warnings for AnExApp examples
Pull Request resolved: https://github.com/facebook/react-native/pull/48620
Test Plan:
- Wrapped the the entry app component in `RNTesterAppShared.js` with `StrictMode` and verified that no warnings are shown anymore for the updated components.
- Checked the examples are still working as they were.
Reviewed By: rshest
Differential Revision: D68092958
Pulled By: cipolleschi
fbshipit-source-id: 0f2cea3c679f8db0f13054e2851a73dc23a4c906
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48556
Changelog: [Internal]
the only place in view module that uses folly is `ViewPropsInterpolation.h` and that is only on Android.
This diff makes that dependency explicit and make it android only.
Reviewed By: javache
Differential Revision: D67942951
fbshipit-source-id: 2a1a41f5a4caba553e81d4bb78ac9c84ba90b60b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48584
[Changelog] [Internal] - Align logic in BaseTextInputShadowNode to calculate placeholder string with AndroidTextInputShadowNode
As a preparation for https://github.com/facebook/react-native/pull/48165 this aligns the implementation of those 2 methods
Reviewed By: NickGerleman
Differential Revision: D68004218
fbshipit-source-id: 722a33bb2665c59347ef1b0cd8ed7b35a05b2113
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48581
Previously the CXX only modules were not being inclued in the schema for these apps, and therefore weren't being caught by the compat check.
Reviewed By: cipolleschi
Differential Revision: D68000360
fbshipit-source-id: 5d56bc840bd220f3b8b814e5d90eb49d9a2beb0b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48548
In this diff I'm introducing the new public API ViewManagerInterface, this will be used in the next diffs of the stack to be implemented by all viewManagerInterfaces that are code-gen when using the new architecture
changelog: [Android][Changed] Introduce new public API ViewManagerInterface
Reviewed By: javache
Differential Revision: D67957886
fbshipit-source-id: 372bf99e4c977c3a4d2252b54371ec9f0dae6e9f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48582
[Changelog] [Internal] - Preparation for sharing common ShadowNode functionality in BaseTextInputShadowNode for Android
As a preparation for https://github.com/facebook/react-native/pull/48165 this change aligns the order of methods between:
- BaseTextInputShadowNode.h
- AndroidTextInputShadowNode.h
to make it easier for future changes to look at the delta between both implementations.
The goal is land https://github.com/facebook/react-native/pull/48582 which aligns the RN iOS and RN Android implementation
Reviewed By: NickGerleman
Differential Revision: D68001423
fbshipit-source-id: 5a5efa6542de676bd175744e7313c2b819e67f11
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48577
This has been enabled by default for about two and a half months. Let's clean up the old path.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D67985133
fbshipit-source-id: 024c1b3f10d7d23caba04ed4b6eec122de1a7c14
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48607
This feature flag acted as a killswitch but it was effectively never used, so we can clean it up now.
Changelog:
[Internal] [Changed] - Cleanup `enableAlignItemsBaselineOnFabricIOS`
Reviewed By: cipolleschi
Differential Revision: D68018624
fbshipit-source-id: 2340b505021a6632b07a3a872e35b35522b6f361
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48558
Running `yarn test-e2e-local -t "RNTester" -p "Android" -h true -c <TOKEN>`
currently fails if you start from RNTester Android.
That's because codegen is not built. This commit fixes it.
Changelog:
[Internal] [Changed] - Fix test-e2e-local with RNTester due to unbuilt codegen
Reviewed By: cipolleschi
Differential Revision: D67972074
fbshipit-source-id: c5c721a913b655675ed6e03e60efbb5ccdf613b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48568
We only need this dependency for internal builds, as we only rely on fbjni, which is its own open-source project.
This code was forked for open-source and not synced in anyway, which is a potential liability.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D67796633
fbshipit-source-id: 8609783ed0921a53a823658b9fd07a57651e91fe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48567
We don't need the `FBLOG_PRI` macro which does unnecessary additional interpolation, and can instead directly call `__android_log_write`
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D67461225
fbshipit-source-id: 3f2c881ce996b9638ef62e40ecc05f3e5a3e6ac1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48606
Fixes https://github.com/facebook/react-native/issues/48009
The app is currently crashing on Android API lvl 26 attempting to invoke the method
`setEventEmitterCallback` which is defined inside BaseJavaModule.
I'm not entirely sure why this is happening only for API lvl 26, but I've verified
that by having the method protected, this doesn't happen anymore.
The visibility is consistent with the field `mEventEmitterCallback` which is also
protected and accessed to codegen. So let's keep them aligned for consistency.
Changelog:
[Android] [Fixed] - Fix crash for setEventEmitterCallback NoSuchMethodError on API lvl 26
Reviewed By: cipolleschi
Differential Revision: D68018506
fbshipit-source-id: 87eda718c9774b584abdf771eaad5833d452a1ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48595
Historically React Native used to include the JitPack repository be default in the default repositories.
This sadly exposes React Native projects to supply chain attacks as explained here:
https://blog.oversecured.com/Introducing-MavenGate-a-supply-chain-attack-method-for-Java-and-Android-applications/
Moreover, artifacts on Jitpack are not GPG signed it's complicated to verify the identity of artifact authors.
I'm introducing a Gradle property to control if Jitpack should be included by default or not.
User can control this behavior by changing their `gradle.properties` file as such:
```
includeJitpackRepository=false
```
The default value of this property is currently true, but we're looking into changing it to false in the future.
Changelog:
[Android] [Added] - Make the addition of JitPack repository configurable
Reviewed By: cipolleschi
Differential Revision: D68016028
fbshipit-source-id: 392513fef389a4835b4e00a8184459e00d51fdd0
Summary:
Adding .kotlin to gitignore. This folder starts to get used with K2 (with Kotlin 2.0) so we should be
adding it to the gitignore files
## Changelog:
[INTERNAL] - Add .kotlin to gitignore
Pull Request resolved: https://github.com/facebook/react-native/pull/48598
Test Plan: N/A
Reviewed By: cipolleschi
Differential Revision: D68018000
Pulled By: cortinico
fbshipit-source-id: 78be3597071d07d105145d8ba94cd83cbf4f21bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48592
Changelog: [General][Added] Add support for the second parameter of `console.table` to specify a list of columns to print in the table.
Reviewed By: javache
Differential Revision: D67803665
fbshipit-source-id: 354476404bad7cd2d280c8b3d963d5acba41f86b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48591
Changelog: [General][Changed] Improved formatting of values logged via `console.table` (including Markdown format).
This provides several improvements over the format of tables logged via `console.table`:
* Markdown format for easy integration in existing documents.
* Increased alignment with the spec and Chrome/Firefox implementations:
* Added index columns.
* Logged all available columns.
* Format for all types of values (including objects, functions, etc.).
Reviewed By: javache
Differential Revision: D67794858
fbshipit-source-id: 464c938ed51f28a8e071bc46f0f5b0d970005873
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48589
Changelog: [internal]
Added basic tests for the current implementation of the `console.table` polyfill (not the CDP implementation).
Reviewed By: sammy-SC
Differential Revision: D67791579
fbshipit-source-id: 80d64903a92e87e0724ed302ec0521419f45f9a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48572
Because of this extra step on build-android, we're seeing the version 1000.0.0-<SHA>
on commits on the release branch. This prevents it.
Changelog:
[Internal] [Changed] - Do not reset rn-artifacts-version on release branch
Reviewed By: cipolleschi
Differential Revision: D67975049
fbshipit-source-id: dace7c931ec310538c11c4b9e544fdc2241a1d0c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48588
Changelog: [internal]
This has proved to be very CI and makes it fail a lot, so we're removing this for now.
Reviewed By: javache
Differential Revision: D67985917
fbshipit-source-id: 5ec7c1387ddfb8fb2a4e90450a98cb3caea9399f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48541
Shows how to use tintColor in conjunction with new XML file format, and serves as a good E2E test bench to ensure that drawables don't accidentally reuse the same state (if the underlying implementation isn't careful enough to call `buildCopy`, both icons will render red)
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D64136753
fbshipit-source-id: 3bd0933e587364425ac14a0635690d4b274a55fe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48523
Current AndroidTextInputShadowNode logic measures the height of the TextInput by fitting text into the constraints of the TextInput box. This results in the wrong height for single line TextInputs, since a single line TextInput is infinitely horizontally scrollable (whearas the outer TextInput component itself has a fixed width).
After this change, we measure text under single line textinputs with an infinite width constraint, then clamp to the final constraints of the TextInput, to better emulate what is happening under the hood.
iOS ended up solving this in a slightly different way, by measuring paragraph with `maximumNumberOfLines={1}` when not multiline, but think this is a bit more fraught. E.g. up until recently, it would have meant that the width could have been less than max width, depending on where line-breaking happened. I ended up duplicating the new logic to use for both instead (D66914447 will eventually deduplicate).
Changelog:
[Android][Fixed] - Fix incorrect height of single line TextInputs without definite size
Reviewed By: christophpurrer
Differential Revision: D67916827
fbshipit-source-id: b827185c4640835481794cb985c2b62dcf643abe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48570
Changelog: [internal]
We're still iterating on this feature and making sure it reports stable results, so marking it as `unstable` to set expectations.
Reviewed By: andrewdacenko
Differential Revision: D67975844
fbshipit-source-id: 41e93cb9cb0c887a96178e4a4d5078d1899b2478
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48573
changelog: [internal]
remove main.cpp for cxxreact/tests. It is not needed for tests to work and it breaks build for C++ only tests.
Reviewed By: javache
Differential Revision: D67975182
fbshipit-source-id: b9cbc5b5b6a87aafc69448e99877e664ed2d5af2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48561
The changelog for 0.77 needs some love as there are some entry that are incorrectly classified.
In this diff I took care of fixing the `Fixed` entries.
We need to go through all the other classes of entries.
## Changelog:
[Internal] - Refine 0.77 changelog
Reviewed By: cortinico
Differential Revision: D67972217
fbshipit-source-id: 343dd5a4e8a6cd6d6806447063594ba466db3b1e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48562
The changelog for 0.77 needs some love as there are some entry that are incorrectly classified.
In this diff I took care of fixing the `Changed` entries.
We need to go through all the other classes of entries.
## Changelog:
[Internal] - Refine 0.77 changelog
Reviewed By: cortinico
Differential Revision: D67941153
fbshipit-source-id: 59bc5a8a37242a1a5dc17baa4d85d0e18df35d46
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48563
The changelog for 0.77 needs some love as there are some entry that are incorrectly classified.
In this diff I took care of fixing the `Changed` entries.
We need to go through all the other classes of entries.
## Changelog:
[Internal] - Refine 0.77 changelog
Reviewed By: cortinico
Differential Revision: D67941107
fbshipit-source-id: 2352c901810587a0d4d5ccbbaa09960f03999378
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48564
The changelog for 0.77 needs some love as there are some entry that are incorrectly classified.
In this diff I took care of fixing the `Added` entries.
We need to go through all the other classes of entries.
## Changelog:
[Internal] - Refine 0.77 changelog
Reviewed By: cortinico
Differential Revision: D67940751
fbshipit-source-id: 345bd0e4e9564a1d8d16418f31ee6a917f27b202
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48565
The changelog for 0.77 needs some love as there are some entry that are incorrectly classified.
In this diff I took care of fixing the entries in the RCs.
We need to go through all the other classes of entries.
## Changelog:
[Internal] - Refine 0.77 changelog
Reviewed By: cortinico
Differential Revision: D67940292
fbshipit-source-id: 3373d2f2879c7137ad93b4b53672a0f8e322776f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48528
The changelog for 0.77 needs some love as there are some entry that are incorrectly classified.
In this diff I took care of fixing the `Breaking Changes` and the `Removed` entries.
We need to go through all the other classes of entries.
## Changelog:
[Internal] - Refine 0.77 changelog
Reviewed By: robhogan, cortinico
Differential Revision: D67937294
fbshipit-source-id: 18278abae4680a9dab3f46e41c1b7f7f8a7ad367
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48560
changelog: [internal]
add tests for width and height and margin style. Covering percentage-based dimensions and invalid inputs.
The test coverage is needed to make removal of folly::tryTo safe.
Reviewed By: rubennorte
Differential Revision: D67942139
fbshipit-source-id: c1e517dfb102eea892c998cf6ff4190fa69cdfa7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48555
Changelog: [internal]
Small move to align with the existing convention.
Add `README.md` file for feature flags in JS directory, to link to canonical docs.
Reviewed By: huntie
Differential Revision: D67897751
fbshipit-source-id: d5091ab4537701ee5cfdf29ebd0fe79e858e3134
Summary:
We currently see this error message on console:

This will silence it by piping stderr to /dev/null
## Changelog:
[INTERNAL] - Silence the `eden info` output from react-native-codegen
Pull Request resolved: https://github.com/facebook/react-native/pull/48540
Test Plan: CI
Reviewed By: robhogan
Differential Revision: D67948411
Pulled By: cortinico
fbshipit-source-id: f805634a65713f4f9bc2dce6d781664e7564bc96
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48428
Changelog: [internal]
Adding a few more tests for `ReactNativeElement` for symmetry with future tests for when it implements `EventTarget`.
Reviewed By: javache
Differential Revision: D67738147
fbshipit-source-id: 04c8f3539fefd15f7c778986eb9e39f2c2386b6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48545
RootViewManager is meant to be used by the internals of React Native, ther are no external usages. I'm internalizing it
changelog: [internal] internal
Reviewed By: christophpurrer
Differential Revision: D67952865
fbshipit-source-id: 4c7f7de01c4de7ae00f62bd4f5b49e0082ec3f2b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48533
Replaces the custom `XmlFormat` introduced in https://github.com/facebook/react-native/pull/46711 with the built-in support from Fresco. Fresco utilizes a very similar approach to load binary XML files and offers the XML format as part of its built-in `DefaultImageFormats`
Changelog:
[Android][Changed] - Replaced custom XML decoder with Fresco's built-in decoder
Reviewed By: NickGerleman
Differential Revision: D66553842
fbshipit-source-id: 096e60140f893d461be1cdb48e250749e58bbb4c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48542
Updates Fresco from 3.5.0 to 3.6.0. Picks up a few new features and bug fixes for XML drawables, including a required fix that [automatically supplies the XML drawable factory to Fresco's PipelineDraweeControllerBuilder](https://github.com/facebook/fresco/commit/e6b052610aab461601cfabc00f7240758a415878). Without this change, we cannot switch from RN's custom XmlFormat to Fresco's built-in format
Changelog:
[Android][Changed] - Update Fresco to 3.6.0
Reviewed By: NickGerleman, rshest
Differential Revision: D67950225
fbshipit-source-id: 9afd87565a5f069493c9c5ef87977cbd6d7cf3d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48525
Fixes https://github.com/facebook/react-native/issues/48249
`TextMeasureCacheKey` hash and equality functions only incorporates the maximum width constraint. I'm guessing this was an attempt at an optimization, but it can lead to incorrect results in pretty trivial cases. E.g. if Yoga knows a definite size of `Text` in one dimension, and measures via `YGMeasureModeExactly`, we can have a minimum size corresponding specific to the style in which the text was laid out.
Changelog:
[General][Fixed] - Fix TextMeasureCacheKey Throwing Out Some LayoutConstraints
Reviewed By: christophpurrer
Differential Revision: D67922414
fbshipit-source-id: 0ee0220059fc4e4645b1684c42a0587fe728bedd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48524
I've confirmed that we are no longer using `eslint-plugin-prettier` in Metro or React Native. This removes it from the package dependencies.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D67920511
fbshipit-source-id: 9c8036ccfb94d974d344d861942c076dc2b70125
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48511
{D60499583} added a new`onUserDrivenAnimationEnded` listener that requires `AnimatedValue` instances to have up-to-date values reported by `onAnimatedValueUpdate` (if native driver is in use).
Previously, the only way to ensure `onAnimatedValueUpdate` events were always fired to update JavaScript values in `AnimatedValue` instance was to attach a listener — even an empty one. This is exactly what D60499583 did: it traverses `props` for `AnimatedNode` instances and attaches listeners to them.
However, this is really inefficient and makes the code extra convoluted. Instead, this diff changes `AnimatedValue` so that it always subscribes to changes in `__attach`, and then it cleans up the extraneous props traversal and "empty listener" logic.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D67872307
fbshipit-source-id: e7d7e486bbfd9ef03e2dd9f201089e2f68b2dbb2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48529
These classes are identical and we already have a dependency on :uimanager in fabric.
Looking at OSS, I found no usages of `fabric.GuardedFrameCallback`.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D67913226
fbshipit-source-id: 97d7a9b45b877b98e9549c71135bd9b21386d78c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48520
Both `ReactScrollViewHelper.parseSnapToAlignment` and `ReactScrollViewHelper.parseOverScrollMode` accept a nullable string. This is a precursor to migrating these files to Kotlin (since they're already marked as nullsafe). The prop itself is a nullable string so this should be reflected in the native types as well
Changelog: [Internal]
Reviewed By: tdn120
Differential Revision: D67911553
fbshipit-source-id: aabe55c2dc65a933b170d76b89f62f25493ab0ee
Summary:
This PR guards code that enables/disables keyboard shortcuts only on iOS (iPadOS included).

## Changelog:
[IOS] [FIXED] - enable/disable keyboard shortcuts only on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/48518
Test Plan: CI Green
Reviewed By: rshest
Differential Revision: D67900442
Pulled By: javache
fbshipit-source-id: 249a7c3124d02d2c30303d218e2b26e987ae1f0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48514
Currently, `AnimatedNode` implements logic to start listening to updates on the current native node if a listener is added.
However, the `startListeningToAnimatedNodeValue` native module method only supports native tags for instances of `AnimatedValue`, which is a subclass of `AnimatedNode`. In fact…
* On Android, [`startListeningToAnimatedNodeValue`](https://fburl.com/code/bdsl4sro) throws if the node is not an instance of `ValueAnimatedNode`.
* On iOS, [`startListeningToAnimatedNodeValue`](https://fburl.com/code/hlpk1rzk) does nothing if node is not an instance of `RCTValueAnimatedNode`.
As such, this refactors `AnimatedNode` to never manage this subscription for native nodes. Instead, the logic is moved into the `AnimatedValue` subclass, ensuring that we never accidentally try to `startListeningToAnimatedNodeValue` with non-`AnimatedValue` native tags.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D67884973
fbshipit-source-id: 5601efd8c29104a991301eabd97ddb88fd03c4a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48513
While refactoring `Animated`, I noticed that many subclasses of `AnimatedNode` override `__attach` without invoking the superclass method, even though we do this for `__detach`.
In order to minimize surprise (e.g. if someone were to add logic into `AnimatedNode.prototype.__attach`), this diff updates all method overrides to invoke `super.__attach()`.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D67884975
fbshipit-source-id: f3a5456cf944d4d70ba1cfe7c44897c110e5fc7e
Summary:
Some of these parameters were incorrectly marked as nullable during the Kotlin migration
Changelog: [Internal]
Reviewed By: tdn120
Differential Revision: D67091825
fbshipit-source-id: c660164e41ba7d47f1d1d3dc28a01b79b7c8cb03
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48337
`SurfaceRegistryBinding` refers to a forked `SurfaceRegistry` we had for a while in bridgeless but which was merged back into `AppRegistry`. Align the native name as well to make it explicit that all this class does is call into `AppRegistry`.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D67342499
fbshipit-source-id: 797d8080611cb2576a2052999c2bf46d2eea9f72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48336
`RN$AppRegistry` and `RN$stopSurface` are always set on the init path, regardless of bridgeless or not, so we can remove the fallback path and cleanup this code.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D67342498
fbshipit-source-id: db47e52fee5075f11258364d82474579d2bb21f4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48335
This API was never adopted or implemented on iOS, and is not compatible with bridgeless.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D67342500
fbshipit-source-id: a6740514d0347c0f497e1aa2f850328cc4607d24
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48470
This introduces:
- `validate_rn_cpp_api`: run a shell script that fails if the user changes the C++ API. Importantly it produces an artifact with details to share with the user: `message`.
- `message` has to be extracted from `stdout`, which **get_user_message** does if the `validate_rn_cpp_api` action is not successful (**warning**).
- The then users `comment_to_signalhub` to share this as a warning to the user (until we're confident this entire stack is very stable, at which time we'll block).
The provides 2 classes of warning:
1. vanilla you've change the API,
2. you've change the API and haven't included the correct changelog.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D67776215
fbshipit-source-id: 4ac7451c8ecef62ba968710ec41804ba42153976
Summary:
Time to migrate some of Hermes's instruments. I see that HermesMemoryDumper(`react/hermes/instrumentation/HermesMemoryDumper.h`) implements the interface on C++, ~but not sure if i need to update the `getId` call to just `id` (same with `getInternalStorage`) or if the interop between Kotlin and Java applies to these things as well. cortinico Any thoughts on your side would be appreciated.
HermesSamplingProfiler just became an object, since it was a singleton and a static anyway.
Here is what HermesMemoryDumper.h looks like:
<img width="1840" alt="Screenshot 2024-12-24 at 10 03 00" src="https://github.com/user-attachments/assets/d18e378a-9b23-47a9-83c9-402d29aeaa5f" />~
*Updated*: I ended up making them match the function signature on Cxx, because even if it does have that implicit behavior, doesn't feel right to tap into it like this.
## Changelog:
[INTERNAL] [FIXED] - Migrate HermesMemoryDumper and HermesSamplingProfiler to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/48378
Test Plan:
`/gradlew test`:
<img width="1840" alt="Screenshot 2024-12-24 at 09 54 29" src="https://github.com/user-attachments/assets/1b23fb6f-9da8-42e4-a348-7da868df77c1" />
Reviewed By: cortinico
Differential Revision: D67657481
Pulled By: philIip
fbshipit-source-id: 4fb5e003789d51d464d0cca5800704ea51324b69
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48487
[Changelog] [Internal] - Add getSurfaceProps helper method to SurfaceManager
When reload a reactHost we need to know which surface properties have been applied when starting the surface. This adds a utility function for that.
Reviewed By: rshest
Differential Revision: D67822459
fbshipit-source-id: 6d1f182514ed6e7ae8e31d3e1ca052c93bac2843
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48476
Command param array types were generating invalid schemas due to untyped parser code. The invalid schemas occurred for any alias type, including custom objects and basics like Int32. This was also inconsistent between Flow and TypeScript.
We already had one component utilizing this issue, so this just codifies that support into the schema so it reflects reality. This is only a partial solution. The more full solution would be to fully encode the custom types in the schemas like we do for Native Modules.
# More Information:
Tl;dr, DebuggingOverlay is abusing a FlowFixMe in codegen commands.
## The problem:
The [CodegenSchema](https://www.internalfb.com/code/fbsource/[d3ab2f79b377]/xplat/js/react-native-github/packages/react-native-codegen/src/CodegenSchema.js?lines=220) should be the source of truth for anything that can be in the schema. If something is in the schema that isn't allowed by the types, that's a bug. We have a bug. I'm adding compat-check support for components and it's blowing up on prod schemas because DebuggingOverlay causes an invalid schema.
## The details:
Support for Arrays as arguments in commands was added to the Codegen in D51866557. [Code Pointer](https://fburl.com/code/8yy1rm0p)
The intention appears to be to support arrays of primitives. There is a TODO for supporting complex types.
```
interface NativeCommands {
+addOverlays: (
viewRef: React.ElementRef<NativeType>,
overlayColorsReadOnly: $ReadOnlyArray<string>,
)
}
```
This support was added to TypeScript in D52046165 where it types the allowed Array arguments to be only
```
{
readonly type: 'ArrayTypeAnnotation';
readonly elementType:
| Int32TypeAnnotation
| DoubleTypeAnnotation
| FloatTypeAnnotation
| BooleanTypeAnnotation
| StringTypeAnnotation
};
```
However, because the Parsers are treating the input type as `any`, it isn't safe to pass through an input value into the schema as Flow won't catch mismatches.
The Flow parser just passes it through:
```
{
type: 'ArrayTypeAnnotation',
elementType: {
// TODO: T172453752 support complex type annotation for array element
type: paramValue.typeParameters.params[0].type,
}
```
Whereas the TypeScript parser has the more correct behavior of validating the inputs and returning specific outputs. Unfortunately, the return type is also typed here as $FlowFixMe, losing most of the benefits.
```
function getPrimitiveTypeAnnotation(type: string): $FlowFixMe {
switch (type) {
case 'Int32':
return {
type: 'Int32TypeAnnotation',
};
case 'Double':
return {
type: 'DoubleTypeAnnotation',
};
case 'Float':
return {
type: 'FloatTypeAnnotation',
};
case 'TSBooleanKeyword':
return {
type: 'BooleanTypeAnnotation',
};
case 'Stringish':
case 'TSStringKeyword':
return {
type: 'StringTypeAnnotation',
};
default:
throw new Error(`Unknown primitive type "${type}"`);
}
}
```
[DebuggingOverlay](https://fburl.com/code/zfe3ipq7) is abusing this gap in the Flow parser by sticking an Array of Objects in.
```
export type ElementRectangle = {
x: number,
y: number,
width: number,
height: number,
};
...
+highlightElements: (
viewRef: React.ElementRef<DebuggingOverlayNativeComponentType>,
elements: $ReadOnlyArray<ElementRectangle>,
) => void;
...
```
This isn't allowed in the schema, but it seems to fall through the holes of the flow parser and generators.
The resulting schema from Flow is this. Note the GenericTypeAnnotation which isn't allowed to be in the schema.
```
{
"name": "highlightElements",
"optional": false,
"typeAnnotation": {
"type": "FunctionTypeAnnotation",
"params": [
{
"name": "elements",
"optional": false,
"typeAnnotation": {
"type": "ArrayTypeAnnotation",
"elementType": {
"type": "GenericTypeAnnotation"
}
}
}
],
"returnTypeAnnotation": {
"type": "VoidTypeAnnotation"
}
},
```
The TypeScript parser fails with `Error: Unsupported type annotation: GenericTypeAnnotation`.
The generators don't seem to check beyond the ArrayTypeAnnotation so they fall through to generating generic arrays.
```
// ios
elements:(const NSArray *)elements
// android
ReadableArray locations
```
## So how do I fix this?
I think there are a couple of different options here. The key problem is that the Schema types need to represent reality of what can be in the schema.
1. We revert DebuggingOverlay to not use features that aren't supported (I assume nobody would be happy with this, but the change shouldn't have been made in the first place)
2. **(This is the approach taken in this diff)** We add MixedTypeAnnotation to the allowed types in Command arrays and have it generate that and add official support for that to the TypeScript parser as well. That is probably the quickest and easiest approach. It leaves the same type unsafety we have today on the native side.
3. NativeModules seem to have a lot more complex type safety here. They persist the alias type in the schema so that the CompatCheck can check them on changes. And then in C++ they generate structs and RCTConvert functions although for Java and ObjC it looks like they just use the same untyped native code. The matching approach here would be to add `aliasMap` and the whole data to the schema for commands, use that for the compat check, and still generate the same unsafe native code.
```
export type ObjectAlias = {|
x: number,
y: number,
|};
export interface Spec extends TurboModule {
+getAlias: (a: ObjectAlias) => string;
}
```
stores the ObjectAlias in the schema
```
{
"aliasMap": {
"ObjectAlias": {
"type": "ObjectTypeAnnotation",
"properties": [
{
"name": "x",
"optional": false,
"typeAnnotation": {
"type": "NumberTypeAnnotation"
}
},
{
"name": "y",
"optional": false,
"typeAnnotation": {
"type": "NumberTypeAnnotation"
}
},
]
}
},
"spec": {
"methods": [
{
"name": "getAlias",
"optional": false,
"typeAnnotation": {
"type": "FunctionTypeAnnotation",
"returnTypeAnnotation": {
"type": "StringTypeAnnotation"
},
"params": [
{
"name": "a",
"optional": false,
"typeAnnotation": {
"type": "TypeAliasTypeAnnotation",
"name": "ObjectAlias"
}
}
]
}
}
]
}
}
```
and then generates the appropriate structs on the native side and generates [this](https://www.internalfb.com/code/fbsource/[d3ab2f79b377]/xplat/js/react-native-github/packages/react-native-codegen/src/generators/modules/__tests__/__snapshots__/GenerateModuleHObjCpp-test.js.snap?lines=818)
```
Reviewed By: hoxyq
Differential Revision: D67806838
fbshipit-source-id: 31f20455c816fdb6b1a86f8f9d0f6f7d0a452754
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48475
This will be needed for the compat-check.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D67806831
fbshipit-source-id: b660c9557cafbfa2e713e85a0fd2bdc9edabf537
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48474
The previous definition said that you could put prop types into commands, which definitely isn't allowed.
For example, the schema would have allowed `WithDefault` types.
```
interface NativeCommands {
+methodInt: (viewRef: React.ElementRef<NativeType>, a: WithDefault<string, 'hi'>) => void;
}
```
This change separates out the things that are allowed in commands from what's allowed in props.
Commands should be very similar to what's allowed in native modules, but it isn't exact enough to be able to merge those.
## Changelog:
[General][Breaking] - Codegen: Separate component array types and command array types
Reviewed By: cipolleschi
Differential Revision: D67806818
fbshipit-source-id: 58e504fe2e2e5efa612e836b18af22a167e7ae2f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48473
This is such a simpler approach lol.
I'll need this later for when I want to pass in arrays or objects of these types to the compat check
Changelog: [internal]
Reviewed By: cipolleschi
Differential Revision: D67806812
fbshipit-source-id: 5cc361815fea901098d2931ba78293693ecc0a35
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48477
Over the years of copying and moving and renaming types through CodegenSchema, this type ended up in the Command params, although the Command parser doesn't allow it.
I made this change to a fixture:
{F1974104959}
and got this error
```
FAIL xplat/js/react-native-github/packages/react-native-codegen/src/parsers/flow/components/__tests__/component-parser-test.js
● RN Codegen Flow Parser › can generate fixture COMMANDS_DEFINED_WITH_ALL_TYPES
Unsupported param type for method "scrollTo", param "speed". Found UnionTypeAnnotation
127 | default:
128 | (type: empty);
> 129 | throw new Error(
| ^
130 | `Unsupported param type for method "${name}", param "${paramName}". Found ${type}`,
131 | );
132 | }
```
Also, a default value for enum an argument of a Command doesn't make sense anyways.
Commands should probably have support for enums and string literal unions, but that's out of scope here.
Still need to add to this vec\concat on www: https://www.internalfb.com/code/www/[ebfa58f888a6064e17879934d447f59bcc2b6951]/flib/intern/sandcastle/react_native/ota_steps/SandcastleOTACompatibilityCheckReportingStep.php?lines=62
Changelog: [internal]
Reviewed By: cipolleschi
Differential Revision: D67806808
fbshipit-source-id: f0f31cca30abbf61f569933ea7c49cf6bfd18a3f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48485
[Changelog] [Internal] - Make SurfaceManager const correct
This marks methods which don't modify member props as `const` and others as non `const`.
The current API signature is misleading as `const` methods do alter `mutable` members
Reviewed By: rshest
Differential Revision: D67820439
fbshipit-source-id: 6a991bd7ccbd464c2390e33e0c29b136892d65e0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48486
[Changelog] [Internal] - Add RuntimeSchedulerKey constant for RuntimeScheduler lookup
Similar to https://github.com/facebook/react-native/pull/48127 this adds a contant to avoid typos when inserting or retrieving the RuntimeScheduler
Reviewed By: rshest
Differential Revision: D67822346
fbshipit-source-id: af982c6d4b875ffde06aae8e953c4892754a074b
Summary:
**iOS** does offer a native property for **UITextField** called `inputAssistantItem`. According to the [documentation](https://developer.apple.com/documentation/uikit/uitextinputassistantitem), we can hide the **"shortcuts"** by setting the `leadingBarButtonGroups` and `trailingBarButtonGroups` properties to empty arrays.
I propose adding a new property for **TextInput** in **React Native**, which would set these native properties to empty arrays. This new property could be called `disableInputAssistant` or `disableKeyboardShortcuts` and would be a `boolean`.
Developers can manage this behavior (the redo & undo buttons and suggestions pop-up hiding) after applying these native props.
https://github.com/react-native-community/discussions-and-proposals/discussions/830
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [ADDED] - [TextInput] Integrate a new property - `disableKeyboardShortcuts`. It can disable the keyboard shortcuts on iPads.
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [ADDED] - [TextInput] Integrate a new property - `disableKeyboardShortcuts`. It can disable the keyboard shortcuts on iPads.
Pull Request resolved: https://github.com/facebook/react-native/pull/47671
Test Plan:
Manual
1. Open TextInput examples.
2. Scroll down and reach the "Keyboard shortcuts" section.
3. Test each case.
Note: **TextInput** behaves the same as now when the new prop is not passed or is `false`.
https://github.com/user-attachments/assets/5e814516-9e6c-4495-9d46-8175425c4456
Reviewed By: javache
Differential Revision: D67451609
Pulled By: cipolleschi
fbshipit-source-id: 59ba3a5cc1644ed176420f82dc98232d88341c6e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48450
Changelog: [internal]
This implements a basic benchmark to compare `ReactFabricHostComponent` and `ReactNativeElement` (legacy and DOM implementations for native component instances).
Reviewed By: rshest
Differential Revision: D66698546
fbshipit-source-id: dd4bde833e5c9eb32c79a52d06f3c360fb012e23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48451
Changelog: [internal]
Modifies the execution of benchmarks in CI to run benchmarks in test mode when they don't define a `verify` method.
If a benchmark uses `verify`, the test is meant to make sure that the benchmark doesn't regress in CI. If it doesn't, then running the benchmark on CI doesn't provide much value. In that case, we run a single iteration of each test case just to make sure things don't break over time.
Reviewed By: rshest
Differential Revision: D67637754
fbshipit-source-id: 33b78a9c809386cf2e040314b0427de6a53da3e3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48452
Changelog: [internal]
Implements a basic API to run benchmarks with Fantom (using `tinybench` under the hood):
```
import {benchmark} from 'react-native/fantom';
benchmark
.suite('Suite name', {
// options
})
.add(
'Test name',
() => {
// code to benchmark
},
{
beforeAll: () => {},
beforeEach: () => {},
afterEach: () => {},
afterAll: () => {},
},
)
.verify(results => {
// check results and throw an error if the expectations fail
});
```
Features:
* Print benchmark results in the console as a table.
* It opts into optimized builds automatically
* Verifies that optimized build is used (unless manually opting out of the check via `disableOptimizedBuildCheck`).
* Supports verification of results (making expectations and making the test fail if the benchmark doesn't meet some expectations).
Reviewed By: rshest
Differential Revision: D66926183
fbshipit-source-id: 61cfa7689ea7684eb870fbbc815b8d236a1871e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48453
Changelog: [internal]
Adds tinybench 3.1.0 (which has support for sync execution) and defined Flow types for the package.
Reviewed By: dmytrorykun
Differential Revision: D66698545
fbshipit-source-id: faf44add74e5711ac0d50794ce3360eedc45f0a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48454
Changelog: [internal]
This implements a native module for Fantom to provide information about the CPU time used by the current process. This will be used by Fantom as the clock to run benchmarks more accurately.
It provides 2 implementations:
1. One based on `clock_gettime` with `CLOCK_THREAD_CPUTIME_ID` that's available on Linux. This provides the CPU time for the current process with decent precision (tens of nanoseconds).
2. A fallback implementation that uses a monotonic clock (not actually CPU time).
We can add a MacOS equivalent in a following diff.
Reviewed By: rshest
Differential Revision: D67596312
fbshipit-source-id: dd712c0171aa998ddbb6fed9187b3c467cd5417d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48504
Following D67857739, fixes accidental change where the removed `ReactNativeFeatureFlags` flag read was not replaced with `true`. This temporarily disabled Fusebox on `main`, where not configured via other build flags.
{F1974195736}
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D67857739
fbshipit-source-id: 2a6fb2e6733035245e7ad959c7d3c650a9fde994
Summary:
Currently the `AppStateModule` doesn't have any unit tests in the Android implementation. This should make it safer for future changes or refactors.
## Changelog:
[INTERNAL] - Add `AppStateModule` Android unit tests
Pull Request resolved: https://github.com/facebook/react-native/pull/48492
Test Plan:
```bash
yarn test-android
```
Reviewed By: cipolleschi
Differential Revision: D67857498
Pulled By: cortinico
fbshipit-source-id: f90ced1cf02ac12a3438495b425ce7931decf19a
Summary:
As a prerequisite of enabling running unit tests on CI again, this PR suggests changes needed to the Ruby unit tests.
I've added comments on the code below, justifying changes where I deem a justification might be needed.
For use internally, I suggest accessing the folly_config and boost_config directly via the `Helpers` class instead of the `get_folly_config` and `get_boost_config` because these global functions are defined in `react_native_pods` which would be result in circular requires. An alternative would be to move these global functions to a separate file.
## Changelog:
[INTERNAL] [FIXED] - Fix Ruby unit tests.
Pull Request resolved: https://github.com/facebook/react-native/pull/48498
Test Plan:
- `cd packages/react-native`
- `./scripts/run_ruby_tests.sh`
Reviewed By: rshest
Differential Revision: D67852809
Pulled By: cipolleschi
fbshipit-source-id: 54d8bd708a9e3fd9aef3569ac89ec6ddcd244437
Summary:
This PR updates podspecs and resolve the following Xcode warnings:
```
Run script build phase '[CP-User] [RN]Check rncore' will be run during every build because it does not specify any outputs. To address this issue, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase.
```
```
Run script build phase '[CP-User] [RN]Check FBReactNativeSpec' will be run during every build because it does not specify any outputs. To address this issue, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase.
```
Enabling the `always_out_of_date` flag will uncheck "Based on dependency analysis" in a script phase.
## Changelog:
[INTERNAL] [FIXED] - Resolve run script build phase warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/48495
Test Plan:
1. Run `bundle exec pod install` in the RNTester folder
2. Open the Xcode workspace
3. Check "Based on dependency analysis" is unchecked in the '[CP-User] [RN]Check rncore' script phase and the '[CP-User] [RN]Check FBReactNativeSpec' script phase
Reviewed By: cipolleschi
Differential Revision: D67835376
Pulled By: rshest
fbshipit-source-id: 11eec80d8172bc0129bfdcf7c79b5edf40427fab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48490
## Changelog:
[Internal] -
This makes the `RootViewTest` and `JSPointerDispatcher` tests to use mockito-kotlin instead of the Java Mockito, which is the legacy of the conversion of the corresponding tests from Java.
Which:
* is the right thing to do, as we have more Kotlin-idiomatic tests
* helps with some Kotlin conversion with classes under test down the line, as Kotlin Mockito handles things like nullability etc properly
Reviewed By: javache
Differential Revision: D67824679
fbshipit-source-id: 055e9c7c4a33164ce6f4b9a5c47f16051d2a132f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48469
This change downloads the generated artifact and uses it in the E2E tests
## Context
While looking at the recent failures of the E2E tests, I realized that the Hermes, NewArch, Debug variant often fails to build, not to test, for some misconfiguration.
I also realized that we are already building that varaint successfully once, so why not reuse it? To reuse prebuilds, we need a few steps:
1. make sure we build all the variants we need
2. store the .app file as an artifact
3. download the artifact and use it in the E2E tests
## Changelog:
[Internal] - Build release variant for RNTester
Reviewed By: mdvacca
Differential Revision: D67800932
fbshipit-source-id: 6f3c8bbc42ad95cabab85dafff00e233a936d136
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48444
While debugging why the Debug variant was failing, I realised that the code to store video artifacts and the code to record the videos were not working properly.
This diff fixes that
## Context
While looking at the recent failures of the E2E tests, I realized that the Hermes, NewArch, Debug variant often fails to build, not to test, for some misconfiguration.
I also realized that we are already building that varaint successfully once, so why not reuse it? To reuse prebuilds, we need a few steps:
1. make sure we build all the variants we need
2. store the .app file as an artifact
3. download the artifact and use it in the E2E tests
## Changelog:
[Internal] - Build release variant for RNTester
Reviewed By: mdvacca
Differential Revision: D67760436
fbshipit-source-id: ee4b034f7c54cbf0b46c0afc16c31389b11353fe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48442
This change stores the RNTester `.app` in an artifact so that E2E tests can reuse it.
## Context
While looking at the recent failures of the E2E tests, I realized that the Hermes, NewArch, Debug variant often fails to build, not to test, for some misconfiguration.
I also realized that we are already building that varaint successfully once, so why not reuse it? To reuse prebuilds, we need a few steps:
1. make sure we build all the variants we need
2. store the .app file as an artifact
3. download the artifact and use it in the E2E tests
## Changelog:
[Internal] - Build release variant for RNTester
Reviewed By: mdvacca
Differential Revision: D67760380
fbshipit-source-id: 8be0bbbadf4240dce1bcf5b44dadb41d49ed4c06
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48439
Changelog: [internal]
This is in preparation for implementing `getRootNode` and `ownerDocument` properly in the DOM APIs.
Reviewed By: rshest
Differential Revision: D67137215
fbshipit-source-id: bda6b1f843f219e03df533797fa9e4adbaa54c60
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48438
Changelog: [internal]
Just adding tests to make sure we cover the cases where the root is unmounted.
Reviewed By: rshest
Differential Revision: D67752010
fbshipit-source-id: 3cc17cd25878013a26dc407640be00e8dc251eea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48434
Changelog: [internal]
We were starting to repeat this logic too much in tests, so extracting so we can reuse it.
Reviewed By: rshest
Differential Revision: D67520443
fbshipit-source-id: 64e4e5b35f83dc45e41bb0efae9685aeaf0cf2e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48436
Changelog: [internal]
Changing the defaults to use something that resembles a real device (in this case the iPhone 14 which is a very common device).
Reviewed By: christophpurrer
Differential Revision: D67759914
fbshipit-source-id: 87fe3be19196ece62c412e5076c601be746a4f22
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48468
Clang will add this code by default at the preprocessor phase. I'd observed a difference in output on sandcastle where it didn't include `stdlib` by default.
This stops `stdlib` being included locally. **It isn't important wrt tracking user API changes.**
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D67793848
fbshipit-source-id: 0c88aee05a78e2410b308fe10c48db2552b8a148
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48460
We can only specify `hg` as a dependency, so have to use it in our shell script.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D67718641
fbshipit-source-id: 557d980a9b6c3dbcd2621481d39a24b47075a3f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48457
Adding CI support will require executing through buck. Sandboxing means the package has to be well-formed to work, so this cleans up some earlier mess.
- yarn workspace
- check-api.sh to configure the environment correctly when running form sandcastle
- explicity dependencies in our package.json
This is the first step
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D67726588
fbshipit-source-id: 7f8605695e323ef332550820b23b85d3af5f4d69
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48456
This is the current output of running the api snapshotting tool. I've also shown some test examples that show how trivial changes affect the API file.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D67713415
fbshipit-source-id: f68c7e15b0d1e26878e39f22f49e64cdd7340df2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48435
Cleans up the runtime `fuseboxEnabledDebug` feature flag. The modern CDP backend has been enabled by default in open source since 0.76.
- Updates `ReactInstanceIntegrationTest` to preserve testing under both backend modes (legacy Hermes debugger vs Fusebox).
- Preserves ability to override `ReactNativeFeatureFlags` in tests via `InspectorFlagOverridesGuard` — we anticipate that future CDP features will continue to read from the `ReactNativeFeatureFlags` system (`fuseboxEnabled` was/is a special case).
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D67759600
fbshipit-source-id: 5878dd879bae435e59c48823a9b9faf85561b028
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48440
Changelog: [internal]
Modifies the Fantom runner to read 2 new environment variables to help with debugging:
- `FANTOM_PRINT_OUTPUT`: prints the output of the CLI to the output of the test.
- `FANTOM_LOG_COMMANDS`: logs the buck commands executed by the runner, so they can be re-run outside the runner for debugging, etc.
Reviewed By: rshest
Differential Revision: D67682750
fbshipit-source-id: aff48c4f47078db1be53e0ee105089fbc921768f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48372
Changelog: [internal]
Implements log streaming in Fantom tests. This allows us to see the logs emitted from tests as they're logged, so we don't need to wait until the test completes to flush all of them at the same time.
Reviewed By: rshest
Differential Revision: D67600609
fbshipit-source-id: efb3125e13fd9aec1800a5f1ddaf0d93dcb29218
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48371
Changelog: [internal]
Adds a new favor for `runCommand` and `runBuck2` that works asynchronously and support parsing their output in real time.
Reviewed By: javache
Differential Revision: D67600614
fbshipit-source-id: 99dd2ce9bff11036829f214bf19208b10c9c1b25
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48369
Changelog: [internal]
This improves logs in Fantom by preserving the original log levels. It's also in preparation for adding support for log streaming in tests.
Reviewed By: javache
Differential Revision: D67600616
fbshipit-source-id: 1c4997d5e836a78327f33092527543fe025c90c6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48367
Changelog: [internal]
We removed the calls to `AppRegistry` in Fantom, so this filter isn't necessary anymore (just a no-op).
Reviewed By: rshest
Differential Revision: D67600610
fbshipit-source-id: d985cc5f0ee1728ac72c567bc091a6c2877f2659
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48391
Changelog: [internal]
When we enabled log streaming in Fantom, we saw a lot of logs that we were previously not forwarding (console.error, console.warn) in existing tests.
This removes all the warnings and errors from those tests.
Reviewed By: rshest
Differential Revision: D67602299
fbshipit-source-id: 111f373eafd8707f2746ff727894f1fa4283b83f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48432
Changelog: [internal]
This moves the native module definition for Fantom to the `react-native` package so we can migrate the module to use the codegen.
Also implements the migration.
Reviewed By: christophpurrer
Differential Revision: D67759729
fbshipit-source-id: d79d078908b05fc4b6f5f26f0144ab7e3485cb83
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48368
Changelog: [internal]
Just a minor rename to align with the existing convention.
Reviewed By: javache
Differential Revision: D67549203
fbshipit-source-id: faa9e34cdce7c59e2c6b3f7e697c90df103699d0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48465
Removes the `packages/hermes-inspector-msggen` workspace. Since https://github.com/facebook/react-native/pull/39300, this is no longer referenced in React Native, and is now part of the Hermes repo.
Changelog: [Internal]
Reviewed By: cortinico, hoxyq
Differential Revision: D67791612
fbshipit-source-id: 73da135b264d8df632fefe87cc4e3101075ae98c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48430
Changelog: [internal]
This expectation currently prints a very generic message that is hard to parse, so this change improves it a bit to account for more cases. E.g.:
* Before: "Expected <function> to throw"
* After: "Expected <function> to throw with message 'foo', but threw with message 'bar'"
Reviewed By: rshest
Differential Revision: D67738146
fbshipit-source-id: 690f15971cec0e8a7b038eeacc9302c9f3edc323
Summary:
Fixes https://github.com/facebook/react-native/issues/38537
Setting `WindowManager.LayoutParams.FLAG_SECURE` in the window flags is not respected in the Android Modal component, causing security issues with screenshots or screen recordings as the content in the modal is visible. The flag works correctly in the rest of the components, see the videos in the linked issue.
This PR addresses that by checking whether this flag is set in the current activity and then setting it in the dialog when creating a new one in the `ReactModalHostView`.
## Changelog:
[ANDROID][FIXED] - `FLAG_SECURE` not respected in Modal dialog
Pull Request resolved: https://github.com/facebook/react-native/pull/48317
Test Plan:
To test this, you need a physical device as with the emulator the flags don't seem to be respected either.
The easiest way to test this in code is by setting the flags in the main activity. You can do so by adding this code snippet:
<details>
<summary>onCreate in RNTesterApplication.kt</summary>
```kt
override fun onCreate() {
ReactFontManager.getInstance().addCustomFont(this, "Rubik", R.font.rubik)
super.onCreate()
...
registerActivityLifecycleCallbacks(
object : ActivityLifecycleCallbacks {
override fun onActivityCreated(activity: Activity, savedInstanceState: Bundle?) {
activity.window.setFlags(
WindowManager.LayoutParams.FLAG_SECURE,
WindowManager.LayoutParams.FLAG_SECURE
)
}
override fun onActivityStarted(activity: Activity) {}
override fun onActivityResumed(activity: Activity) {}
override fun onActivityPaused(activity: Activity) {}
override fun onActivityStopped(activity: Activity) {}
override fun onActivitySaveInstanceState(activity: Activity, outState: Bundle) {}
override fun onActivityDestroyed(activity: Activity) {}
}
)
}
```
</details>
Then, you can render a simple modal component:
<details>
<summary>RNTesterPlayground.js</summary>
```tsx
function Playground() {
const [modalVisible, setModalVisible] = React.useState(false);
return (
<>
<Modal
visible={modalVisible}
testID="playground-modal">
<Text testID="inner-text-test-id">Hello World!</Text>
<Button title="Close Modal" onPress={() => setModalVisible(false)} />
</Modal>
<Button
title="Open Modal"
onPress={() => {
setModalVisible(true);
}}
/>
</>
);
}
```
</details>
You can then try to record the screen or take screenshots. You will notice that before opening the modal, you won't be able to see anything in the recording, but when opening the modal, the content is visible.
I've tried my best to record the before and after the fix, but as the screen recordings will mostly show a black screen, you have to forward a bit in both videos to see the difference.
<details>
<summary>Before the fix (notice the blank screen and then content visible)</summary>
https://github.com/user-attachments/assets/fc5bbe26-d238-425b-90d3-0e43c89ccaac
</details>
<details>
<summary>After the fix (notice all the screen recording is a black screen)</summary>
https://github.com/user-attachments/assets/0d6991a0-974b-45c5-8f4a-bf4718c284e6
</details>
Reviewed By: cipolleschi
Differential Revision: D67368741
Pulled By: alanleedev
fbshipit-source-id: 9f31063a9208a6df257da424bf3096bf15a5ddcb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48455
This is a followup to earlier issues in the stack.
Two fixes here:
1. Make the paths more consistent esp. from the config, so everything is working out of react-native-github.
2. Just declare `__cpluscplus`, as we don't seem to care about the value in our code.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D67716883
fbshipit-source-id: 359c33210d6b66bb0d75724a177587a7d5f837b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48449
This is the simplest possible way to track changes to our public CPP / Objective-C API.
This is going to be really noisy, and there's a good chance it's not complete.
The tooling is also incomplete, as it just runs the preprocessor (then does some funky work to undo noise generated by the preprocessor). If we want more control over this, we're going to have to jump into the guts of each of our build targets (and tooling) OR more clearer layout the repo to separate public and private header files to our users.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D67713408
fbshipit-source-id: 9578179bbc4d9be2f07d040b01f8a3ef105d7034
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48414
Was looking into https://github.com/facebook/react-native/issues/48078 which was brought to my attention due to my recent refactorings of iOS Views, especially around how overflow: hidden works. This bug was not brought on by my changes but seems to be a lingering Fabric bug (iirc this bool was not changed when I refactored things)
Anyway, dotted/dashed borders did not work with overflow: hidden. The reason why is we use core animation borders in this case which is incorrect as CA cannot do these types of borders. So I added a check to make sure that the borders are solid as well if we want to use CA to draw them.
Changelog: [iOS] [Fixed] - Dashed & dotted borders now work with overflow: hidden
Reviewed By: mdvacca
Differential Revision: D67720492
fbshipit-source-id: 5aecc15f2d7cbd71952d78d6972f6fc6b7a93ea8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48343
components store unions as 'StringEnumTypeAnnotation' even though it isn't actually a union, it's a literal.
Native Modules store these as 'StringLiteralTypeAnnotation' so this converges those and reuses the same types.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D67427656
fbshipit-source-id: e39028114285588584596012d07db40c117b4b94
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48318
These structures were the same, but the component side didn't use generics and just had duplicates. Making a base one to be shared.
I need to follow up to this and constrain the types that components allow.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D67371894
fbshipit-source-id: bb1a30fcd0efe6cc567b88bc6f11e7b385bd7c41
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48458
NOTE: This change is made once and is not guaranteed.
**Motivation**: Requiring Flow parsing for `react-native` and its dependencies in user space can involve friction. For the case of `react-native/assets-registry` → `react-native-web`, I believe we should do the pragmatic thing to relax this requirement.
- This is a convenience stopgap until https://github.com/facebook/react-native/pull/39542 can be stabilised.
- This package is tiny and infrequently modified — I believe it's pragmatic/safe to do a one-time conversion, with the above notice and no changelog (i.e. "experimental" for now).
Resolves https://github.com/facebook/react-native/issues/48349.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D67764460
fbshipit-source-id: 7687fd79c6dea73c234a46e475c1cc745225830b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48443
This change makes sure we build the Release variant of RNTester so we can store the generated app as an artifact and forward it to the E2E tests.
## Context
While looking at the recent failures of the E2E tests, I realized that the Hermes, NewArch, Debug variant often fails to build, not to test, for some misconfiguration.
I also realized that we are already building that varaint successfully once, so why not reuse it? To reuse prebuilds, we need a few steps:
1. make sure we build all the variants we need
2. store the .app file as an artifact
3. download the artifact and use it in the E2E tests
## Changelog:
[Internal] - Build release variant for RNTester
Reviewed By: cortinico
Differential Revision: D67760372
fbshipit-source-id: 02cc9ec64d5a7b4fa2ad05bca6aa91a69b2b5907
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48419
This change moves the E2E scripts for iOS to a JS script.
This should make it much easier to modify the code in case we need to change it.
## Changelog
[Internal] - Move e2e script from bash to JS
Reviewed By: cortinico
Differential Revision: D67737950
fbshipit-source-id: d0b0411c8a4d688c10e460e70b11dbfc83aaa135
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48418
RNTester JSC Debug is currently insta-crashing on the 0.77 release branch due to:
```
12-31 10:59:36.388 15165 15204 E ReactNativeJS: React Native version mismatch.
12-31 10:59:36.388 15165 15204 E ReactNativeJS:
12-31 10:59:36.388 15165 15204 E ReactNativeJS: JavaScript version: 0.77.0-rc.5
12-31 10:59:36.388 15165 15204 E ReactNativeJS: Native version: 1000.0.0-bb9d7ad9a
12-31 10:59:36.388 15165 15204 E ReactNativeJS:
12-31 10:59:36.388 15165 15204 E ReactNativeJS: Make sure that you have rebuilt the native code. If the problem persists try clearing the Watchman and packager caches with `watchman watch-del-all && npx react-native start --reset-cache`.
```
This is causing a `console.error` that is resulting in the crash as one of the frame in the stack doesn't have the line/column number information. Calling `.putDouble(string,double)` is forcing a conversion from `null` -> `double` which is result in the crash.
This is happening only on CI because the `set-rn-version` step on GitHub Action is executed with `--dry-run` (as this is not a release run) so the version of React Native is set back to `1000.0.0-<SHA>`. Locally this doesn't happen because the React Native version is read from the local file which is never manipulated by the `set-rn-version`.
Changelog:
[ANDROID] [FIXED] - Fix JSC Debug instacrashing
Reviewed By: cipolleschi
Differential Revision: D67735962
fbshipit-source-id: 363218385277374d33b8313cacd14159b2f17106
Summary:
### Issue
When a real device is oriented into landscape and the user locks the screen during said orientation incase the user rotates back to previous orientation and unlocks the screen `useWindowDimensions` will not get the correctly updated values. This is due to `applicationState` being equal to UIApplicationStateInactive still when `interfaceFrameDidChange` gets called.
### Fix
`didUpdateDimensions` on iOS. Now correctly emits the dimension values after the device has been oriented and device has been locked. By adding `UIDeviceOrientationDidChangeNotification` to `NSNotificationCenter`
## Changelog:
[IOS] [FIXED] - Emit didUpdateDimensions correctly
```
// RCTDeviceInfo.mm
// Adds the interfaceFrameDidChange to UIDeviceOrientationDidChangeNotification
[[NSNotificationCenter defaultCenter] addObserver:self
selector:selector(interfaceFrameDidChange)
name:UIDeviceOrientationDidChangeNotification
object:nil];
```
Pull Request resolved: https://github.com/facebook/react-native/pull/46353
Test Plan:
### ***Note***: This doesn't seem to be replicable on simulators. It only happens on real iOS devices.
### Before change:
Rotate Device > Lock Screen > Rotate back to portrait > Unlock phone

### After change:
Same steps as above, now emits correct values

Reviewed By: cortinico
Differential Revision: D67735523
Pulled By: cipolleschi
fbshipit-source-id: 146e5d62d55eeef0f6b17f962ca84ab418a7b7f0
Summary:
This PR implements ReactNativeFactory to encapsulate further the logic of creating an instance of React Native for iOS.
This will remove the strong coupling on the RCTAppDelegate and allow us to support Scene Delegate in the future.
The goal is to have a following API:
```objc
self.reactNativeFactory = [[RCTReactNativeFactory alloc] initWithDelegate:self];
UIView *rootView = [self.reactNativeFactory.rootViewFactory viewWithModuleName:self.moduleName
initialProperties:self.initialProps
launchOptions:launchOptions];
// Standard iOS stuff here
```
## Changelog:
[IOS] [ADDED] - implement ReactNativeFactory
Pull Request resolved: https://github.com/facebook/react-native/pull/46298
Test Plan: Test out all the methods of AppDelegate
Reviewed By: huntie
Differential Revision: D67451403
Pulled By: cipolleschi
fbshipit-source-id: 9e73cd996ffc27ca1e3e058b45fc899b1637bdba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48347
Vector drawable support was added behind a feature flag in https://github.com/facebook/react-native/pull/45354 and is ready to release more widely. This change is effectively the same as removing the feature flag but allows our holdout to continue until mid-January.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D67482531
fbshipit-source-id: 1733c4748f79fd4df72f531a24efcbd8a7822611
Summary:
X-link: https://github.com/facebook/litho/pull/1036
X-link: https://github.com/facebook/yoga/pull/1775
Pull Request resolved: https://github.com/facebook/react-native/pull/48404
## Changelog:
[Internal] -
This popped up when profiling some heavy UI performance, calling `fmod` operation in Yoga's `roundLayoutResultsToPixelGrid` in `PixelGrid.cpp` can be expensive, furthermore it turns out that some of the calls were redundant.
This replaces the duplicate calls to fmod with an equivalent single round operation, which for e.g. clang compiler on Windows brings the code in question from ~50 instructions (including 4 call instructions to the fmod function) down to ~30 instructions (without any external calls), and the layout operation being **~1% more efficient** for the particular benchmark I was looking into.
Reviewed By: christophpurrer
Differential Revision: D67689065
fbshipit-source-id: 2a074a1cb81bd7f7a3c414050b9ddda2ba90180f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48401
This change adds a flag to JS Error's prototype to specify the jsEngine.
Reviewed By: fkgozali
Differential Revision: D67665484
fbshipit-source-id: 64b7b4bd986bcbd45d58e70c1a16de6752b05ccd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48400
A couple of days ago, the iOS CI started failing for the E2E tests on main.
This is because We were not using the hermes artifacts we were preconfiguring.
In fact, this is the log of the `test_e2e_ios_rntester`, which is not using the prebuilt.
{F1974129000}
For comparison, this is the `test_ios_rntester`, which is using the prebuilt
{F1974129001}
While investigating why this was happening, I realized that we were not testing the old architecture anymore, because we forget to update the script after the release of the New Architecture.
This change should fix both.
## Changelog:
[Internal] - Fix E2E tests for iOS and test the Old Arch
Reviewed By: robhogan
Differential Revision: D67670976
fbshipit-source-id: 7d1383a89e06c138f437a9c5f876a2e900878fb0
Summary:
### Error message:
we got an error
```
t[n] is not a function. (In 't[n]()', 't[n]' is undefined) \n <unknown> (index.bundle:317:168:317)
```
it related the BackHandle execute handle function.
### Investigation result
our project has screen files`App.tsx`, `Dashboard.tsx`, and `Profile.tsx`.
When launching the app, the screen order is `App.tsx` -> `Dashboard.tsx`, then user can switch to `Profile.tsx`
For `App.tsx` and `Dashboard.tsx`, we just prevent the hardware button action use `usePreventHardwareBackPressEffect()` in the first line of screen code.
```js
export const useHardwareBackPressEffect = (goBack?: () => boolean): void => {
useEffect(() => {
if (goBack) {
BackHandler.addEventListener("hardwareBackPress", goBack);
return () => {
BackHandler.removeEventListener("hardwareBackPress", goBack);
};
}
return undefined;
}, [ goBack ]);
};
export const usePreventHardwareBackPressEffect = (): void => useHardwareBackPressEffect(() => true);
```
currently, `_backPressSubscriptions ` has 2 callback functions.
then user switch to `Profile.tsx` screen, and has the below code for hardwareback button and the second doesn't `return true`:
```js
// first one
usePreventHardwareBackPressEffect();
...
// second one
useEffect(() => {
const backButtonListener = BackHandler.addEventListener(
"hardwareBackPress",
() => navigate(Navigation.Login);
);
return () => backButtonListener.remove();
});
```
currently, `_backPressSubscriptions ` has 4 callback functions, include previous 2 and new 2 of `Profile.tsx`.
When the user press hardwareback button, it will navigate to the login screen, so the issue occurs:
the latest callback will be executed first, then the navigation will let the screen unmount, which will destroy the effect, so the code removing 2 hardwareBackPress callback of `Profile.tsx` by executed
```js
return () => {
BackHandler.removeEventListener("hardwareBackPress", goBack);
};
```
After the navigation ends and the loop is restored, the init `i` is 3, then `i--`, `i` is 2, then `_backPressSubscriptions[2]` is `undefined` now and executes as a function, so the app crashes.
```js
for (let i = _backPressSubscriptions.length - 1; i >= 0; i--) {
if (_backPressSubscriptions[i]()) {
return;
}
}
```
that's the issue I met.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID] [FIXED] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [FIXED] - Fix BackHandle callback undefined cause crash issue
Pull Request resolved: https://github.com/facebook/react-native/pull/48388
Reviewed By: blakef
Differential Revision: D67648077
Pulled By: rshest
fbshipit-source-id: 5ca685b0c0c474ef11772fd803743968ec2d912e
Summary:
https://github.com/facebook/react-native/issues/48376 removed `applicationDidEnterBackground` from `RCTAppDelegate` but RNTester called it, leads to crash. cc cipolleschi can you please help to review?
## Changelog:
[INTERNAL] [FIXED] - RNTester: Fixes crash when app back to background
Pull Request resolved: https://github.com/facebook/react-native/pull/48385
Test Plan: RNTester iOS back to background not crash.
Reviewed By: cipolleschi
Differential Revision: D67657449
Pulled By: philIip
fbshipit-source-id: e6d806b2677050fa2faa273a7468055d9d21c2a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48383
## Changelog:
[Internal] -
This changes the name of `SystraceSection` class to `TraceSection`, the purpose being to make it Systrace/FBSystrace agnostic (and that it can be mapped to e.g. Perfetto instead).
It changes all the internal callsites to the RN code code, and also adds a shim include, `<cxxreact/SystraceSection.h`, for backward compatibility with the external callers for now (which will be addressed separately).
Reviewed By: javache
Differential Revision: D67621914
fbshipit-source-id: 337c63c45a7b075c6e00cfca67ecc06c298c94c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48381
Right now, the E2E tests for RNTester does not have a timeout.
It can happen that the emulator get stuck and the action times out.
The default timeout is 6 hours, which is definitely too much and wasteful, so let's reduce it to 1 hour.
{F1974112110}
## Changelog:
[Internal] - Set timeout for E2E tests to 1 hour
Reviewed By: robhogan, blakef
Differential Revision: D67620423
fbshipit-source-id: c507d1222fca49287fafe6da4bffe559d8687b99
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48379
## Changelog:
[Internal] -
We have a good portion of RN core code already instrumented with `SystraceSection` blocks, and those do the timing via fbsystrace, which may or may not be enabled in the system and generally is obsolete.
This maps the blocks to the corresponding Perfetto instrumentation, in case the latter is enabled, which will allow to get this information in Perfetto sessions without need to have fbsystrace present.
Reviewed By: javache
Differential Revision: D67619443
fbshipit-source-id: 52e5666472ad118fbec176a0e82d72a5200a358a
Summary:
While investigating the root cause of app hanging on older devices in Instruments, I noticed that the heaviest stack trace was pointing to `RCTRecursiveAccessibilityLabel` in RCTView.m.
<details>
<summary>Heaviest stack trace in Instruments</summary>
<img width="473" alt="Screenshot 2024-05-17 at 4 22 48 PM" src="https://github.com/facebook/react-native/assets/849905/fab8ed01-7a2f-4113-b2ca-04e76f25cd9d">
</details>
The profiling was done on an iPad (5th generation) running iOS 16.7.4. The app is text heavy which makes the issue more visible than in RNTester for instance.
### Before
<img width="854" alt="Screenshot 2024-05-17 at 4 19 46 PM" src="https://github.com/facebook/react-native/assets/849905/5e3cc7ad-299c-4814-ab4a-031c0e677b12">
It turns out that `[NSMutableString stringWithString:@""]` is initialized in every call of the recursion even though most of the time it's only used to check the length at the end and return `nil`.
My change only initialize the mutable string if it's going to be used. I applied the same logic to the equivalent Fabric component. It's a small change that improved the accessibility label generation by 60ms in my case.
## 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] [CHANGED] - Reduce memory allocations when computing accessibilityLabel
Pull Request resolved: https://github.com/facebook/react-native/pull/44605
Test Plan:
Running the same measurements after the change, computing the accessibility label is not the heaviest stack trace anymore. And the line by line tracing shows that `[NSMutableString stringWithString:@""]` impact has been significantly reduced.
### After
<img width="769" alt="Screenshot 2024-05-17 at 4 53 04 PM" src="https://github.com/facebook/react-native/assets/849905/1ad638ac-ba7e-4dca-ac77-10df5d2dad49">
I have been using this change in production thanks to a patch-package and it effectively improved the performances when navigating between screens.
I also tested in RNTester with and without Fabric. For both architectures, I made sure the return value of `RCTRecursiveAccessibilityLabel`.
Interestingly, when there is no label, the Fabric implementation returns an empty string while the `RCTView.m` returns `nil`.
I'm open to align both implementations to return `nil` if you believe there is no underlying reason requiring the Fabric implementation to return an empty string.
Reviewed By: cipolleschi
Differential Revision: D67620818
Pulled By: javache
fbshipit-source-id: 1a6937075a5ff5a9ad03fbbf910d64b3884c0fe0
Summary:
I noticed that `AppDelegate` subscribers listening for `applicationDidEnterBackground` events in Expo projects (as documented [here](https://github.com/expo/expo/blob/238b6f57e459dd2c0b13ee158f0af709fe922460/docs/pages/modules/appdelegate-subscribers.mdx?plain=1#L56) aren't working as expected anymore.
While investigating, I discovered that the events aren't reaching the `ExpoAppDelegate` implementation ([source](https://github.com/expo/expo/blob/71f2c55ff3f11e43ab43761bb5cece2e48eae0bf/packages/expo-modules-core/ios/AppDelegates/ExpoAppDelegate.swift#L61)) because the `RCTAppDelegate` implementation of `applicationDidEnterBackground` interrupts the event chain. This appears to be affecting some legitimate use cases.
I believe we could improve this by removing the current implementation, but I'd love to hear your thoughts on this approach. I might be missing some context about why this implementation was originally needed, so any insights would be greatly appreciated!
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - Fix applicationDidEnterBackground not being called
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [FIXED] - Fix applicationDidEnterBackground not being called
Pull Request resolved: https://github.com/facebook/react-native/pull/48376
Test Plan: Ran a local test after change
Reviewed By: javache
Differential Revision: D67621557
Pulled By: cipolleschi
fbshipit-source-id: 2d73711372deba867bd616c79ef4d00c79aa86d5
Summary:
I think parsed isn't a good enough name.
React native also does a lot of processing of the error.
This also opens the door for eventually forwarding the original error in the future.
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D67526700
fbshipit-source-id: 895d64fa1ee4061ecbf0c1a6033c25b6fca95fd6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48363
jq is already installed on M1 machines on GithubActions. There is no need to install it again and this is outputting a warning in CI:
{F1974100065}
## Changelog:
[Internal] - Do not install jq as it is already installed
Reviewed By: blakef
Differential Revision: D67599961
fbshipit-source-id: 1f621f796b0c67ec877fc35269137537618f47ae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48364
The configuration to run E2E tests on maestro has a typo that was outputting a warning in CI:
{F1974100056}
## Changelog
[Internal] - Fix typo on E2E test configuration
Reviewed By: robhogan
Differential Revision: D67599849
fbshipit-source-id: 9504f821172782e188ff524176bc4c2ec48dea97
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48365
For a mistake, the local E2E test we use to test a release is still pointing to the release APK instead of using the debug apk.
This change fix that. The change has been manually applied to the release branches, for example [here](https://github.com/facebook/react-native/commit/385318bf6a83b124d9e8eb925932edff02115c85)
## Changelog
[Internal] - use Debug apk instead of release one to test the release
Reviewed By: robhogan
Differential Revision: D67599760
fbshipit-source-id: 224b5b8d8f664bb579b09ee68f1b92c0774a9b5e
Summary:
Sometimes, specific E2E tests can fail. This change tries to run specific E2E tests with retries, to compensate for their flakyness.
## Changelog:
[Internal] - Add single test retry for Android E2E tests
Pull Request resolved: https://github.com/facebook/react-native/pull/48324
Test Plan: GHA
Reviewed By: huntie
Differential Revision: D67396758
Pulled By: cipolleschi
fbshipit-source-id: 7d806fe7354bd9e826c591ea9628c73c3b258fce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48327
This PR introduces necessary changes to let React Native uses latest version of static Hermes.
## Explanation
### Part 1
```cmake
append("/d2UndefIntOverflow-" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
```
It seems like this flag doesn’t exist anymore in the MSVC 16 compiler.
CI logs - https://github.com/piaskowyk/react-native/actions/runs/11815096269/job/32915591004
```
fatal error C1007: unrecognized flag '-UndefIntOverflow-' in 'p2'
```
### Part 2
```cmake
if("${CMAKE_CXX_COMPILER_ID}" MATCHES "MSVC")
# MSVC needs C++20
set(CMAKE_CXX_STANDARD 20)
else()
set(CMAKE_CXX_STANDARD 17)
endif()
```
Some of the new syntax in static Hermes requires the newer C++ standard on MSVC.
### Part 3
```cmake
# Changes in lib/CMakeLists.txt
```
These updates are necessary to successfully build the Hermes Framework for iOS.
### Part 4
```diff
namespace hermes {
namespace hbc {
namespace {
class BytecodeSerializer {
- friend void visitBytecodeSegmentsInOrder<BytecodeSerializer>(
+ friend void hermes::hbc::visitBytecodeSegmentsInOrder<BytecodeSerializer>(
```
Due to additional additional anonymous namespace, the MSVC wasn't able to recognise proper symbol without explicite definition.
X-link: https://github.com/facebook/hermes/pull/1566
Test Plan: Build RNTester app from here - https://github.com/piaskowyk/react-native/tree/%40piaskowyk/build-static-hermes
Reviewed By: tmikov, cipolleschi
Differential Revision: D67316013
Pulled By: neildhar
fbshipit-source-id: cf03850f94a75acd827b68794700a8f143a90e09
Summary:
Follow up from https://github.com/facebook/react-native/issues/48271 and https://github.com/facebook/react-native/issues/48254, I noticed that the Modal component also doesn't map the `resource-id` from the `testID` on Android. This PR addresses that.
## Changelog:
[ANDROID] [FIXED] - Modal: Setting `resource-id` from `testID` prop
Pull Request resolved: https://github.com/facebook/react-native/pull/48313
Test Plan:
Alternatively do:
```
$ adb shell uiautomator dump
UI hierchary dumped to: /sdcard/window_dump.xml
$ adb pull /sdcard/window_dump.xml
/sdcard/window_dump.xml: 1 file pulled, 0 skipped. 1.1 MB/s (3505 bytes in 0.003s)
```
and check in XML: ` resource-id="playground-modal" class="android.view.ViewGroup" `
-------
Using Appium, check that the `testID` prop passed from JS is mapped as `resource-id` in the rendered view group of the Modal.
<details>
<summary>Example of the code implementation in the RNTester Playground:</summary>
```tsx
function Playground() {
const [modalVisible, setModalVisible] = React.useState(false);
return (
<>
<Modal
visible={modalVisible}
testID="playground-modal">
<Text testID="inner-text-test-id">Hello World!</Text>
</Modal>
<Button
title="Open Modal"
onPress={() => {
setModalVisible(true);
}}
/>
</>
);
}
```
</details>
<details>
<summary>Output in Appium Inspector:</summary>
<img width="913" alt="image" src="https://github.com/user-attachments/assets/514ae2b3-35a8-4a1a-8efc-1ca6bd73f189" />
</details>
Reviewed By: javache
Differential Revision: D67369350
Pulled By: alanleedev
fbshipit-source-id: a799ad5b974895a39d9287e3d76d1139a6ef6a83
Summary:
If 3rd party libs are using `inputAccessoryView` - the current code can easily break it. Whenever props gets changed we call `setDefaultInputAccessoryView` which will simply overwrite the current `inputAccessoryView` (which is highly undesirable).
The same fix on paper was made ~7 years ago: https://github.com/facebook/react-native/commit/bf3698323d81508fc77174df2b1ffe5fb03224e7
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - Fixed problem with accessory view & 3rd party libs
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/48339
Test Plan: Make sure `inputAccessoryView` functionality works as before
Reviewed By: javache
Differential Revision: D67451188
Pulled By: cipolleschi
fbshipit-source-id: bc3fa82ae15f8acedfd0b4e17bdea69cbd8c8a8d
Summary:
All newly generated react native apps are still showing warnings to use react in the jsx scope. That is not needed anymore as of react 18 with built-in jsx transform plugin.
Reproduction: https://github.com/matinzd/react-in-jsx-warning-repro
Run `npm run lint` in this repo.
## Changelog:
[GENERAL] [FIXED] - Disable `react-in-jsx-scope` rule in eslint config
Pull Request resolved: https://github.com/facebook/react-native/pull/46587
Test Plan: Initiate a new template with community CLI and you should not see this warning anymore.
Reviewed By: christophpurrer
Differential Revision: D67394923
Pulled By: cipolleschi
fbshipit-source-id: cfe8e44e33e1b3ae9fe17ca56dd3c7258b7bff69
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48250
LLVM-15 has a warning `-Wunused-variable` which we treat as an error because it's so often diagnostic of a code issue. Unused variables can compromise readability or, worse, performance.
This diff either (a) removes an unused variable and, possibly, it's associated code or (b) qualifies the variable with `[[maybe_unused]]`.
- If you approve of this diff, please use the "Accept & Ship" button :-)
Reviewed By: palmje
Differential Revision: D66839601
fbshipit-source-id: dfba4aab6d73a2fd805ad2761a49c23612c28ccd
Summary:
Originally with https://github.com/facebook/react-native/commit/5cf8f43ab182781ea82e88077df425c3efbfc21f , we added a call to a new Apple API `JSGlobalContextSetInspectable` to ensure that our Javascript running with JSC is debuggable. That change was guarded with a `__builtin_available(macOS 13.3, iOS 16.4, tvOS 16.4, *)` check to make sure it only ran on OS'es where to function existed. Later, in https://github.com/facebook/react-native/commit/3eeee11d7ac4075d0917233d3be4a9469f802d35 we did an extra guard in the way of a macro to check we were compiling against a new enough version of Xcode (so that Xcode knows about the symbol).
Between the runtime check and the compile time check, we should be good right? Wrong! As it turns out, this bit of code still caused crashes on iOS 15 devices (See this [Apple Forum Thread](https://forums.developer.apple.com/forums/thread/749534)). To address this, https://github.com/facebook/react-native/pull/44185 was added which added a new compiler guard (`__OSX_AVAILABLE_STARTING(MAC_NA, IPHONE_16_4)` was added. Unfortunately, this guard is incorrect: It is basically checking if our minimum iOS deployment target is 16.4 (It's not, as of writing it is iOS 13.4), which effectively means this code is never compiled and one can never direct debug with JSC on iOS 16.4+ 😨!
So what went wrong, and why were the first two guards not good enough? Three main reasons..
Firstly, this is a device only crash, and not reproducible on simulator. This is probably why the crash was not caught earlier. Secondly, It's because system frameworks (like JavascriptCore) are _dynamically_ linked: the linker doesn't look for the symbol till runtime (and crashes when doing so). Thirdly, It's because we are _strongly_ linking the framework, so every symbol must be present and the macros / guard Apple provides with `AvailabilityMacros.h` don't work.
What we want to do is link JavascriptCore as a `weak_framework`, more info here: https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html
From that link:
> One challenge faced by developers is that of taking advantage of new features introduced in new versions of OS X while still supporting older versions of the system. Normally, if an application uses a new feature in a framework, it is unable to run on earlier versions of the framework that do not support that feature. Such applications would either fail to launch or crash when an attempt to use the feature was made. Apple has solved this problem by adding support for weakly-linked symbols.
>When a symbol in a framework is defined as weakly linked, the symbol does not have to be present at runtime for a process to continue running. The static linker identifies a weakly linked symbol as such in any code module that references the symbol. The dynamic linker uses this same information at runtime to determine whether a process can continue running. If a weakly linked symbol is not present in the framework, the code module can continue to run as long as it does not reference the symbol. However, if the symbol is present, the code can use it normally.
This seems to be exactly what we want, and the Apple provided method for using new APIs in system frameworks!
Let's update our podspecs so we link JavascriptCore weakly. As a bonus (and admittedly, the original purpose of this PR) let's add macOS support to the `JSC_HAS_INSPECTABLE` macro (This file `JSCRuntime.cpp` used to have more explicit macOS support in it's macros, but I had removed it with https://github.com/facebook/react-native/commit/fb30fcaa2f526cc1f7c2d4189ec9c57f9cf9b3c5).
## Changelog:
[IOS] [FIXED] - Fix Direct Debugging with JSC
Pull Request resolved: https://github.com/facebook/react-native/pull/39549
Test Plan:
Tested that RNTester doesn't crash on boot running on an iPad Air 2 running iOS 15.8., and that an iOS 17.2 simulator is debuggable.
Built RN-Tester and RN-Tester-macOS and verified both show up in Safari Web Inspectors' debug menu:
<img width="1316" alt="Screenshot 2023-09-19 at 10 48 43 PM" src="https://github.com/facebook/react-native/assets/6722175/c642e6e0-36af-4c9f-845a-7e491489f419">
macOS screenshot small bc I got some internal stuff I gotta crop 😅
<img width="347" alt="Screenshot 2023-09-19 at 10 53 46 PM" src="https://github.com/facebook/react-native/assets/6722175/1e802c88-02b8-49e1-8fd2-d91726ca1e93">
Reviewed By: huntie
Differential Revision: D67338150
Pulled By: cipolleschi
fbshipit-source-id: 620c3b3cc1e37e54de7fa4dc9956a02c8f3c09f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48312
I figured out how to fix these FlowFixMes
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D67313962
fbshipit-source-id: 21b109824411c1537f397aca45b7cdc2495f5e11
Summary:
This is an automatically generated fixup patch to bring fbsource back into sync with
facebook/react on GitHub. Please land this patch as soon as possible, as the difference
reflected on here is already on GitHub and future changes may depend on these
changes!
<< DO NOT EDIT BELOW THIS LINE >>
diff-train-skip-merge
bypass-react-native-oss-changelog
Generated by: https://www.internalfb.com/intern/sandcastle/job/36028798618339642/
GitHub Repo: facebook/react
Reviewed By: kassens
Differential Revision: D67286468
fbshipit-source-id: 66632a2524e80bca065d0a0f94342c4ec2d2a7b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48307
Changelog:
[General][Fixed] - Fix a bug when fantom tests could not be run in parallel, e.g. in a stress-test.
Reviewed By: rubennorte, danalex97
Differential Revision: D67334828
fbshipit-source-id: 3db18f6a100925480dbf8385f9ea414187406f4a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48306
Extract a constant for SoftAssertions so they can be logged appropriately
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D67296589
fbshipit-source-id: c8823fd5dfa09a771bb8fbf498edb8d9264f053f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48303
## Context
If a component is re-rendered/committed multiple times before mount, Android mounting layer creates and executes mounting instructions for every commit. Component's native representation is updated multiple times, potentially triggering expensive computations (e.g. recreating boxShadows) for a single draw.
A more efficient way would be to create mounting instructions to update the component from the initial state (before the first render) to the final state (after the last render) in one go.
iOS does that.
This diff is an attempt to experiment on achieving such behaviour for Android.
## Implementation Details
1. When cloning a ShadowNode, accumulate all the updates in `Props.rawProps`.
2. For calculating prop update payloads to be sent to the Android mounting layer, diff old and new `rawProps` by calling `newProps->getDiffProps(oldProps)`.
3. Most importantly, move computing of the mounting instructions from `schedulerDidFinishTransaction`, which is called after every commit, to `schedulerShouldRenderTransactions` which happens only once, after the final commit.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D63457028
fbshipit-source-id: 991727838a4e11628cb696d66d41e1d441a5ef4f
Summary:
Fixes https://github.com/facebook/react-native/issues/45810
Upgrading `typescript-config` module version from `es2015` to `esnext`, in order to support dynamic imports.
## Changelog:
[GENERAL] [CHANGED] - Upgrading `typescript-config` module version to `esnext`
Pull Request resolved: https://github.com/facebook/react-native/pull/48230
Test Plan:
Create a new React Native project:
```bash
npx react-native-community/cli@latest init AwesomeProject
```
Copy the changes in the reproducer from the linked issue and add a lazy import:
```tsx
const LazyAssetExample = React.lazy(() => import('./components/AssetExample'));
```
See the error when running `yarn tsc`:
<img width="739" alt="image" src="https://github.com/user-attachments/assets/99989cd1-e11a-4b23-b178-f221d8cdd8ca" />
---
To fix the error, apply the following patch:
```patch
diff --git a/node_modules/react-native/typescript-config/tsconfig.json b/node_modules/react-native/typescript-config/tsconfig.json
index d5e1bce..51f54c1 100644
--- a/node_modules/react-native/typescript-config/tsconfig.json
+++ b/node_modules/react-native/typescript-config/tsconfig.json
@@ -3,7 +3,7 @@
"display": "React Native",
"compilerOptions": {
"target": "esnext",
- "module": "es2015",
+ "module": "esnext",
"types": ["react-native", "jest"],
"lib": [
"es2019",
```
Verify it is fix by running `yarn tsc` again
Reviewed By: cipolleschi
Differential Revision: D67334277
Pulled By: NickGerleman
fbshipit-source-id: d26525023ff6fcfff651d1e4cee48ab2854b8d83
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48286
This change bumps the specs for the Android E2E tests. This has been reported to improve the stability of the tests.
We need to keep part of the `flatlist.yml` commented as it creates an issue with Maestro as it takes too much memory.
I'll reach out to the people working on Maestro to try and understand what's going on there.
## Changelog:
[Internal] - Improve android Stability and reenable E2E tests on main
Reviewed By: fabriziocucci
Differential Revision: D67276601
fbshipit-source-id: 7cca253547063a0ec39da7de58806286c6632b07
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48279
The text tests has 2 issues:
* on iOS, the Text cell was sometimes rendered below the tabbar, with a small percentage visible. When this happens, the test was actually moving to a different tab rather then navigating to the Text screen
* on Android, sometimes navigation took too long and a scroll command was issued. This moved the screen away from the right screen we wanted to test.
This change fixes both issues by ensuring that the Text cell is 100% visible (not behind the tabbar) and by ensuring that the title "Text" is visible in Android, so the navigatin has actually happened
## Changelog:
[Internal] - Fix Text tests
Reviewed By: fabriziocucci
Differential Revision: D67274009
fbshipit-source-id: ed12f096788e7e6e74ee8d336dba350b35b85e81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48280
In an attempt to improve times and stability, I bumped the android machine to an ubuntu with 4 cores.
Sometimes the emulator can hang, so i set a timeout for the E2E tests executions of 1 hours to avoid wasting money in CI
## Changelog
[Internal] - Bump Android machine and add timeout
Reviewed By: fabriziocucci
Differential Revision: D67273842
fbshipit-source-id: b7212f52016f8ead1dbb2b4da03cb6f564222893
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48281
While working on Maestro E2E I realized that we were waiting for Metro to start even when metro was not running.
This moves the waiting only when metro is actually started.
I also added another waiting point as it takes several seconds for the app to load the bundle from metro the first time. Subsequent attempts are faster as the metro cache is warm.
## Changelog:
[Internal] - Improve metro waiting times in E2E
Reviewed By: fabriziocucci
Differential Revision: D67273648
fbshipit-source-id: 912be4d14869c8ce87d7c4e4f7ee37b643f5845c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48282
This change bump maestro to the latest version as it present better reporting.
## Changelog:
[Internal] - Bump maestro to 1.39.5
Reviewed By: fabriziocucci
Differential Revision: D67273486
fbshipit-source-id: da41a002528a3b3c0934f86888da2bb53ae131b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48289
Provide a mechanism to register specific category constants, which can be used by individual `ReactSoftExceptionListener`s to differentiate behavior, if desired.
Changelog: [Android][Added] SoftException categories
Reviewed By: makovkastar
Differential Revision: D66785403
fbshipit-source-id: cb2c8861bb1dce29a6787d328b814cee09f36464
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47749
Migrate ReactPointerEventsView to kotlin
changelog: [Android][Breaking] Mikgrating pointerEvents API breaks compatibility for kotlin usages of this api as a val
Reviewed By: cortinico
Differential Revision: D66217250
fbshipit-source-id: ff192c9f92d1df93c082b563937eb3f37176f144
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48269
# Changelog: [Internal]
I've noticed that our definition of Trace Event is different from the one that is defined in Google's doc / V8 / Chrome. This has some flaws:
* It creates fragmentation, like with custom track ids or with mocked process ids.
* Current implementation is strict the relationship between `performance.mark()`, `performance.measure` APIs and Instant, Complete Trace Events. Basically only something recorded with `performance.mark` can be an instant trace event.
This should unblock recording custom trace events inside `PerformanceTracer`, such as when tracing started and others. Same could be said about events related to CPU profiling from Hermes, which will be based on these APIs.
This is the pre-requisite for next diff that will add emitting `TracingStartedInPage` event. With this event, the trace should look similar to the one recorded in the browser, and Timings / Main tracks no longer should be registered manually.
Reviewed By: huntie
Differential Revision: D67207107
fbshipit-source-id: fd7f55dd82167c14a63c2d93aaa649072c5a2a2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48292
These dependencies are making the CI on main to fail.
## Changelog:
[General][Fixed] - Fix peer dependencies on React types
Reviewed By: javache, hoxyq
Differential Revision: D67283609
fbshipit-source-id: b325246f5de654a9ccbf7f96eec24434047a38ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48160
Shift to mockito-kotlin and fix ReactCookieJarContainerTest so it's not just testing a mock.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D66898956
fbshipit-source-id: 5ccc652b86e5a80b81d257d3ec645d7bc813301b
Summary:
When building a react native app from Xcode and ccache has been set to be used, the `ccache-clang.sh` and `ccache-clang++.sh` scripts cannot find `ccache`, because Xcode PATH does not include ccache binary.
What I've done is setting a `CCACHE_BINARY` user-defined Xcode setting containing the result of executing `command -v ccache` during pod install execution and directly calling it in ccache scripts, set by ReactNativePodsUtils when ccache is enabled.
Fixes https://github.com/facebook/react-native/issues/46126
## Changelog:
[IOS] [FIXED] - fix ccache not found error exporting ccache binary path as Xcode user-defined setting to be used by ccache scripts
Pull Request resolved: https://github.com/facebook/react-native/pull/48257
Test Plan: Correctly builds helloworld and RNTester apps using ccache by enabling it at pod install time: `USE_CCACHE=1 pod install`.
Reviewed By: christophpurrer
Differential Revision: D67280700
Pulled By: cipolleschi
fbshipit-source-id: 5478a191f9bd77606a56ccd340fea225ab62d4bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48291
Changelog: [internal]
`react-native-fantom` was added to `.eslintignore` when we upgraded to React 19 because we wanted to reduce the amount of warnings to ease the migration.
This re-enables ESLint for that directory and removes the warnings.
Reviewed By: cipolleschi
Differential Revision: D67283104
fbshipit-source-id: 4ec2363ceaff3cd7bd6e5d70e9588c3dd22d7d85
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48263
Changelog: [internal]
Customize log level in Fantom based on flag in runner.js.
Reviewed By: javache
Differential Revision: D67199970
fbshipit-source-id: 31cdd2eaeee8e7ab4c8985661b35822d78d0457b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48262
Changelog: [internal]
At the moment, we can't start surfaces in Fabric without calling `AppRegistry.runApplication`.
This is completely unnecessary in cases like Fantom, where the creation of the surface is done manually from JS and we render to it immediately after (so we don't need to call into JS again to run AppRegistry).
Reviewed By: javache
Differential Revision: D67199971
fbshipit-source-id: e6402686b6f544a4a7651f6a21a57891ca6be3d1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48268
No need to store and compare strings here when a simple boolean will do.
Changelog: [Internal]
Reviewed By: NickGerleman, mdvacca
Differential Revision: D67204387
fbshipit-source-id: c78cc758797980c2bce11875e0f6ea1961058f05
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48267
`parentShadowView.tag` was renamed to `parentTag` in D66656411. This one callsite is hidden behind an `#ifdef`, so it didn't produce a compile error.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D67203413
fbshipit-source-id: 8c1b1af616165b9a80bd38ab4d7376cb2f27cce5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48284
Changelog: [internal]
We recently prevented tasks that run via `runTask` to synchronously call `runTask` because the execution is synchronous and we can't nest tasks in the event loop (D67107664 / https://github.com/facebook/react-native/pull/48235).
This adds `scheduleTask` to schedule tasks (also within tasks) with the right expectations (the task will not run synchronously on that call but at the right time).
It also adds `runWorkLoop` so we can run scheduled tasks if they're not scheduled from an already running task.
Reviewed By: javache
Differential Revision: D67275518
fbshipit-source-id: acde0093802fbcb7083334f2c0247b37b759a6b1
Summary:
Fixes https://github.com/facebook/react-native/issues/39092
Right now, the `testID` prop that is passed to the ActivityIndicator component is not being applied as a `resource-id`. In this PR, we overwrite the `onInitializeAccessibilityNodeInfo` in the `ProgressBarContainerView` to set this `resource-id`.
## Changelog:
[ANDROID][ADDED] - ActivityIndicator: setting `resource-id` from the `testID` prop
Pull Request resolved: https://github.com/facebook/react-native/pull/48271
Test Plan:
Render a simple activity indicator and pass a `testID` as follows:
```tsx
import {ActivityIndicator} from 'react-native';
function Playground() {
return (
<ActivityIndicator
color="white"
testID="default_activity_indicator"
accessibilityLabel="Wait for content to load!"
/>
);
}
```
<details>
<summary>Inspect the element using an e2e tool such as Maestro or Appium, the `resource-id` is not present: (see screenshot)</summary>
<img width="736" alt="image" src="https://github.com/user-attachments/assets/3aecce5f-3850-4c62-b1ab-aed4133e12bc" />
</details>
---
Apply the changes and then:
<details>
<summary>Inspect again, the `resource-id` is present now: (see screenshot)</summary>
<img width="731" alt="image" src="https://github.com/user-attachments/assets/5a0e3bfa-924a-4a50-8eef-2f7fff7e1290" />
</details>
Reviewed By: rshest
Differential Revision: D67274852
Pulled By: javache
fbshipit-source-id: 2ac8d2bbebed5d1723eb33e735bbf3b477a42572
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48283
Migrate from custom JSI integration to use TurboModule base-class.
This doesn't use codegen right now for ease of migration, and to avoid needing to setup a js_library buck definition for react-native-fantom. We should also figure out what the right abstraction/division of responsibilities is going forward for TesterAppDelegate and FantomModule.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D67111850
fbshipit-source-id: e1623d80f1f25ec123315b3620930dd17dd8a8a7
Summary:
Building RNTester fails locally because my node path contains a space " ".
(I'm using [fnm](https://github.com/Schniz/fnm) which installs into `/Users/{username}/Library/Application Support/fnm`).
I haven't verified this, but I suspect this is broken for other apps as well, as the script is called when bundling for any app.
<details>
<summary>Expand to see output from the failed build</summary>
```
Node found at: /Users/kraen.hansen/Library/Application Support/fnm/node-versions/v22.11.0/installation/bin/node
+ DEST=/tmp/RNTesterBuild/Build/Products/Release-iphonesimulator/RNTester.app
+ [[ ! -n '' ]]
+ [[ Release = *Debug* ]]
+ [[ -n '' ]]
+ case "$CONFIGURATION" in
+ DEV=false
+++ dirname ../react-native/scripts/react-native-xcode.sh
++ cd ../react-native/scripts/..
++ pwd
+ REACT_NATIVE_DIR=/Users/kraen.hansen/Repositories/react-native/packages/react-native
+ PROJECT_ROOT=/Users/kraen.hansen/Repositories/react-native/packages/rn-tester
+ cd /Users/kraen.hansen/Repositories/react-native/packages/rn-tester
+ [[ -n /Users/kraen.hansen/Repositories/react-native/packages/rn-tester/js/RNTesterApp.ios.js ]]
+ :
+ source /Users/kraen.hansen/Repositories/react-native/packages/react-native/scripts/node-binary.sh
++ '[' -z '/Users/kraen.hansen/Library/Application Support/fnm/node-versions/v22.11.0/installation/bin/node' ']'
++ type '/Users/kraen.hansen/Library/Application Support/fnm/node-versions/v22.11.0/installation/bin/node'
+ HERMES_ENGINE_PATH=/Users/kraen.hansen/Repositories/react-native/packages/rn-tester/Pods/hermes-engine
+ '[' -z /Users/kraen.hansen/Repositories/react-native/packages/rn-tester/Pods/hermes-engine/build_host_hermesc/bin/hermesc ']'
+ [[ true != false ]]
+ [[ -f /Users/kraen.hansen/Repositories/react-native/packages/rn-tester/Pods/hermes-engine ]]
+ '[' -z '' ']'
+ export NODE_ARGS=
+ NODE_ARGS=
+ '[' -z '' ']'
+ CLI_PATH=/Users/kraen.hansen/Repositories/react-native/packages/react-native/scripts/bundle.js
+ '[' -z '' ']'
+ BUNDLE_COMMAND=bundle
+ '[' -z '' ']'
+ COMPOSE_SOURCEMAP_PATH=/Users/kraen.hansen/Repositories/react-native/packages/react-native/scripts/compose-source-maps.js
+ [[ -z '' ]]
+ CONFIG_ARG=
+ [[ -z '' ]]
+ BUNDLE_NAME=main
+ BUNDLE_FILE=/tmp/RNTesterBuild/Build/Products/Release-iphonesimulator/main.jsbundle
+ EXTRA_ARGS=()
+ case "$PLATFORM_NAME" in
+ BUNDLE_PLATFORM=ios
+ '[' '' = YES ']'
+ EMIT_SOURCEMAP=
+ [[ ! -z ../sourcemap.ios.map ]]
+ EMIT_SOURCEMAP=true
+ PACKAGER_SOURCEMAP_FILE=
+ [[ true == true ]]
+ [[ true != false ]]
++ basename ../sourcemap.ios.map
+ PACKAGER_SOURCEMAP_FILE=/tmp/RNTesterBuild/Build/Products/Release-iphonesimulator/sourcemap.ios.map
+ EXTRA_ARGS+=("--sourcemap-output" "$PACKAGER_SOURCEMAP_FILE")
+ [[ true != false ]]
+ [[ false == false ]]
+ EXTRA_ARGS+=("--minify" "false")
+ [[ -n '' ]]
+ [[ -n '' ]]
+ EXTRA_ARGS+=("--config-cmd" "$NODE_BINARY $NODE_ARGS $REACT_NATIVE_DIR/cli.js config")
+ '/Users/kraen.hansen/Library/Application Support/fnm/node-versions/v22.11.0/installation/bin/node' /Users/kraen.hansen/Repositories/react-native/packages/react-native/scripts/bundle.js bundle --entry-file /Users/kraen.hansen/Repositories/react-native/packages/rn-tester/js/RNTesterApp.ios.js --platform ios --dev false --reset-cache --bundle-output /tmp/RNTesterBuild/Build/Products/Release-iphonesimulator/main.jsbundle --assets-dest /tmp/RNTesterBuild/Build/Products/Release-iphonesimulator/RNTester.app --sourcemap-output /tmp/RNTesterBuild/Build/Products/Release-iphonesimulator/sourcemap.ios.map --minify false --config-cmd '/Users/kraen.hansen/Library/Application Support/fnm/node-versions/v22.11.0/installation/bin/node /Users/kraen.hansen/Repositories/react-native/packages/react-native/cli.js config'
/bin/sh: /Users/kraen.hansen/Library/Application: No such file or directory
node:internal/errors:983
const err = new Error(message);
^
Error: Command failed: /Users/kraen.hansen/Library/Application Support/fnm/node-versions/v22.11.0/installation/bin/node /Users/kraen.hansen/Repositories/react-native/packages/react-native/cli.js config
/bin/sh: /Users/kraen.hansen/Library/Application: No such file or directory
at genericNodeError (node:internal/errors:983:15)
at wrappedFn (node:internal/errors:537:14)
at checkExecSyncError (node:child_process:888:11)
at execSync (node:child_process:960:15)
at Command.handleAction (/Users/kraen.hansen/Repositories/react-native/packages/react-native/scripts/bundle.js:48:9)
at Command.listener [as _actionHandler] (/Users/kraen.hansen/Repositories/react-native/node_modules/commander/lib/command.js:542:17)
at /Users/kraen.hansen/Repositories/react-native/node_modules/commander/lib/command.js:1502:14
at Command._chainOrCall (/Users/kraen.hansen/Repositories/react-native/node_modules/commander/lib/command.js:1386:12)
at Command._parseCommand (/Users/kraen.hansen/Repositories/react-native/node_modules/commander/lib/command.js:1501:27)
at Command.parse (/Users/kraen.hansen/Repositories/react-native/node_modules/commander/lib/command.js:1064:10)
at Object.<anonymous> (/Users/kraen.hansen/Repositories/react-native/packages/react-native/scripts/bundle.js:71:11)
at Module._compile (node:internal/modules/cjs/loader:1546:14)
at Object.<anonymous> (node:internal/modules/cjs/loader:1689:10)
at Module.load (node:internal/modules/cjs/loader:1318:32)
at Function._load (node:internal/modules/cjs/loader:1128:12)
at TracingChannel.traceSync (node:diagnostics_channel:315:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:218:24)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:170:5)
at node:internal/main/run_main_module:36:49 {
status: 127,
signal: null,
output: [
null,
'',
'/bin/sh: /Users/kraen.hansen/Library/Application: No such file or directory\n'
],
pid: 64660,
stdout: '',
stderr: '/bin/sh: /Users/kraen.hansen/Library/Application: No such file or directory\n'
}
Node.js v22.11.0
Command PhaseScriptExecution failed with a nonzero exit code
warning: Run script build phase '[CP-User] [RN]Check FBReactNativeSpec' will be run during every build because it does not specify any outputs. To address this warning, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase. (in target 'React-RCTFBReactNativeSpec' from project 'Pods')
warning: Run script build phase 'Build JS Bundle' will be run during every build because it does not specify any outputs. To address this warning, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase. (in target 'RNTester' from project 'RNTesterPods')
warning: Run script build phase '[RN] Copy Hermes Framework' will be run during every build because it does not specify any outputs. To address this warning, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase. (in target 'RNTester' from project 'RNTesterPods')
** BUILD FAILED **
```
</details>
This PR add single quotes around the `$NODE_BINARY` and `$REACT_NATIVE_DIR` to avoid `--config-cmd` escaping similarly to the way they're escaped when invoked just below: https://github.com/facebook/react-native/blob/00c7174c24fd15db7723633e3e67aa59a7e73a6c/packages/react-native/scripts/react-native-xcode.sh#L155
## Changelog:
[IOS] [FIXED] - Properly escape paths in Xcode build script used when bundling an app.
Pull Request resolved: https://github.com/facebook/react-native/pull/48275
Test Plan:
- Change your node path to contain a space (possibly through a symlink and manually updating the `.xcode.env.local` file in `packages/rn-tester`.
- Build the RNTester app for e2e tests: `yarn e2e-build-ios`
- See the failure mentioned above 💥
- Apply this patch and re-run the build command to success ✅
Reviewed By: NickGerleman
Differential Revision: D67256815
Pulled By: robhogan
fbshipit-source-id: e27a8cd079347fdf982c28b5af347be621c8feba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48265
For some clang warnings configurations, you may hit `-Winconsistent-missing-destructor-override` without this override modifier.
## Changelog
[Internal]
Reviewed By: cipolleschi
Differential Revision: D67203040
fbshipit-source-id: 51f8f9bc4e45ebdb008dc440b779302b1103668a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48226
Adding logging to onHostPause to help diagnose cases when the activity is incorrectly null.
Reviewed By: fkgozali
Differential Revision: D67123351
fbshipit-source-id: f694a3a89e4584776050f6bca2f33f2805528d4b
Summary:
We're trying to pass `jsi::Value`s directly to our view components (and convert them to java/swift types manually). That way we can pass "complex" objects to our views (such as `jsi::Object`s with `NativeState` attached, without the need to convert them to e.g. `folly::dynamic`).
On android we store our complex prop values on the `StateWrapperImpl` to pass the complex types between c++ and java/kotlin. See an example here:
https://github.com/hannojg/nitro/blob/2378fe7754294c496b2cbcd62f7109529e276427/packages/react-native-nitro-image/nitrogen/generated/android/c%2B%2B/JValueFromStateWrapper.cpp#L21-L23
```
const auto& customStateData = dynamic_cast<const ConcreteState<CustomStateData>&>(state);
CustomStateData data = customStateData.getData();
std::shared_ptr<HybridTestObjectSwiftKotlinSpec> nativeProp = data.nativeProp;
```
> (And then it might be used in java like this:)
https://github.com/hannojg/nitro/blob/2378fe7754294c496b2cbcd62f7109529e276427/packages/react-native-nitro-image/android/src/main/java/com/margelo/nitro/image/NitroExampleViewManager.java#L31-L38
```kotlin
public Object updateState(NonNull View view, ReactStylesDiffMap props, StateWrapper stateWrapper) {
StateWrapperImpl stateWrapperImpl = (StateWrapperImpl) stateWrapper;
HybridTestObjectSwiftKotlinSpec nativeProp = ValueFromStateWrapper.valueFromStateWrapper(stateWrapperImpl);
long value = nativeProp.getBigintValue();
Log.d("NitroExampleViewManager", "Value from state: " + value);
```
For that we need to be able to access the underlying state, which is what we added in this PR.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [ADDED] - Added `getState` method for `StateWrapperImpl`
Pull Request resolved: https://github.com/facebook/react-native/pull/48255
Test Plan: Internal change, just make sure all tests are passing
Reviewed By: cipolleschi
Differential Revision: D67196130
Pulled By: javache
fbshipit-source-id: 7da74bcddef79abd3122baaad1bfce30330ecc80
Summary:
I was getting build errors when I tried to include `StateWrapperImpl.h` in my library's code on android. The error was:

```
node_modules/react-native/ReactAndroid/build/prefab-headers/reactnative/react/fabric/StateWrapperImpl.h:11:10: fatal error: 'react/common/mapbuffer/JReadableMapBuffer.h' file not found
#include <react/common/mapbuffer/JReadableMapBuffer.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3 warnings and 1 error generated.
```
The problem is that the map buffer files inside the mapbuffer folder are nested, so the prefab outcome looks like this:

Hence it can't resolve the header path.
This change removes the header prefix part as its not needed, since the nested folder structure in mapbuffer already matches what we need, see:
https://github.com/facebook/react-native/tree/main/packages/react-native/ReactAndroid/src/main/jni/react/mapbuffer
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [FIXED] - Fixed build issue when including mapbuffer jni headers in library code
Pull Request resolved: https://github.com/facebook/react-native/pull/48243
Test Plan:
make sure the header path looks correct in the prefab build dir:

Reviewed By: cipolleschi
Differential Revision: D67200010
Pulled By: cortinico
fbshipit-source-id: 127a17392fcca0a3a07643497729979849f0a17a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48222
Changelog: [internal]
Tiny improvement over the current setup so it might help detect some current issues.
Reviewed By: yungsters
Differential Revision: D67021976
fbshipit-source-id: 7829f2ea0d839178f1a50d176b42dc0906c2e585
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48188
Yoga is full of bugs! Some of these bugs cannot be fixed without breaking large swaths of product code. To get around this, we introduced "errata" to Yoga as a mechanism to preserve bug compatibility, and an `experimental_layoutConformance` prop in React Native to create layout conformance contexts. This has allowed us to create more compliant layout behavior for XPR.
This prop was originally designed as a context-like component, so you could set a conformance level at the root of your app, and individual components could change it for compatibility. This was difficult to achieve at the time, without introducing a primitive like `LayoutConformanceView`, which itself participated in the view tree. This prop has not been the desired end-goal, since it does not make clear that it is setting a whole new context, effecting children as well!
Now that we've landed support for `display: contents`, we can achieve this desired API pretty easily.
**Before**
```
import {View} from 'react-native';
// Root of the app
<View {...props} experimental_layoutConformance="strict">
{content}
</View>
```
**After**
```
import {View, experimental_LayoutConformance as LayoutConformance} from 'react-native';
// Root of the app
<LayoutConformance mode="strict">
<View {...props}>
{content}
</View>
</LayoutConformance>
```
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D66910054
fbshipit-source-id: e6a304b5c30ad3c5845a7ce2d1021996a74c2f34
Summary:
This module is no longer functional, the global method `pokeSamplingProfiler` does not exist. There are no implementations in the core of `JSCSamplingProfiler` (removed back in 2019! - https://www.internalfb.com/diff/D10473627)
Changelog: [Internal]
Reviewed By: fabriziocucci
Differential Revision: D67140119
fbshipit-source-id: 9dfe80d63e935004ef4a1956e8a7a544a2f9a8c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48073
Small change so we can know what the final value of the feature flag will be
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D64077789
fbshipit-source-id: 2a9e2c7ceeb18813b4556f92db547697bba966a5
Summary:
In this PR we added a change that allows the RawPropsParser to construct its RawValues directly from the `jsi::Value` instead of converting it to `folly::dynamic` first.
We added a global feature flag to turn this on, however, for migrations it might be better to use this functionality as an opt-in on a component basis. With this change `ComponentDescriptors` can now create their RawPropsParser instance with the `useRawPropsJsiValue` flag to opt into it.
(Note: a few more changes are needed to make this accessible to the `ComponentDescriptor`, for which I opened [this follow up PR here](https://github.com/facebook/react-native/pull/48232))
## 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
-->
[INTERNAL] [ADDED] - Added `useRawPropsJsiValue` parameter to `RawPropsParser` to opt into skipping folly::dynamic conversions during prop parsing.
Pull Request resolved: https://github.com/facebook/react-native/pull/48231
Test Plan: Internal change / just make sure all tests are passing.
Reviewed By: NickGerleman
Differential Revision: D67139641
Pulled By: javache
fbshipit-source-id: 5b243edb8149870aad0a5a1b3998ee67997783d7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48242
This std::function is immediately invoked, no need to copy it around.
Changelog: [Internal]
Reviewed By: fabriziocucci
Differential Revision: D67093042
fbshipit-source-id: 2b863fb1857da73568afaf6f3d3c8c7bbef0d61b
Summary:
### Motivation
- We need to exclude certain prop keys from conversion to `folly::dynamic` on android for our custom use case where we pass down `jsi::object`s with NativeState attached down the props
Otherwise we run into crashes such as:

### Changes
- `dynamicFromValue` was marked as `noexcept` although it can throw, I removed the `noexcept` for correctness
- Made it so you can pass down a filter function to exclude certain props from conversion (using the existing mechanism for that)
- I think there is no way to pass a filter function and retain it in `RawProps` as that is constructed very early on in `UIManagerBinding`
## 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
-->
[INTERNAL] [ADDED] - Allow passing a filter function to `BaseViewProps` to exclude certain props on android from being dynamically casted
Pull Request resolved: https://github.com/facebook/react-native/pull/48202
Test Plan:
You can try modifying for example `ScrollViewProps.cpp` and pass a fourth argument to `ViewProps` to confirm that the filtering is working:
```cpp
ScrollViewProps::ScrollViewProps(
const PropsParserContext& context,
const ScrollViewProps& sourceProps,
const RawProps& rawProps)
: ViewProps(context, sourceProps, rawProps, [&](const std::string& keyName){
return true;
}),
```
Reviewed By: NickGerleman
Differential Revision: D67088540
Pulled By: javache
fbshipit-source-id: ed8cf5d773d357dfc54553f5ccf7adf27c781d56
Summary:
Apple introduced system font families
```
font-family: system-ui;
font-family: ui-sans-serif;
font-family: ui-serif;
font-family: ui-monospace;
font-family: ui-rounded;
```
for Safari at 2020 (see https://developer.apple.com/videos/play/wwdc2020/10663/?time=872).
This PR implementation supports above font families on iOS.
bypass-github-export-checks
## Changelog:
[IOS] [ADDED] - Support system font families (system-ui, ui-sans-serif, ui-serif, ui-monospace, and ui-rounded) on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/47544
Test Plan: Run `RNTester` and view the `Text` component where shows the usage for those font families.
Reviewed By: NickGerleman
Differential Revision: D65761307
Pulled By: cipolleschi
fbshipit-source-id: 18628160b7753b314389e887cddfe9d0ec96ee1d
Summary:
This PR converts the HelloWorld app to Swift. The HelloWorld app is our internal copy of the Template and the template is now using Swift. It's important that this macroscopic changes are synched between the template and HelloWorld, otherwise we risk to ship changes that works in the helloworld app but that break the template, and therefore the next release. That already happened once this month.
## Changelog:
[Internal] - Migrate HelloWorld app to swift
Pull Request resolved: https://github.com/facebook/react-native/pull/48246
Test Plan: GHA
Reviewed By: cortinico
Differential Revision: D67143408
Pulled By: cipolleschi
fbshipit-source-id: f74412116570e44c2a394173f7d4d3b6dd85e2e5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48209
[Changelog] [Internal] - (Almost) align Android TextLayoutManager interface with iOS one
This change aligns the public API surface of `TextLayoutManager` from RN Android closer to the RN iOS one.
Reviewed By: javache
Differential Revision: D67061225
fbshipit-source-id: b06f47c7e322bdac429cefb85bf2f2a80210a64f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48223
[Changelog] [Internal] - Use ShadowNode::Traits instead of directly enable Yoga measurement
The goal of this change is to simple use ShadowNodeTraits to enable measurement of ShadowNode props
Reviewed By: NickGerleman
Differential Revision: D67114097
fbshipit-source-id: dccb0f9b83f339c07ca41678533d97191277b520
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48237
Noticed this when trying to diagnose what seemed like a stale caching issue. It effectively reverts D59917944.
D59917944 added logic to only do yarn caching on main, but it has some correctness issues:
1. We cache `node_modules` instead of the yarn cache, which may contain e.g. build artifacts, or other scratch/cache files written (such as anything that writes to `node_modules/.cache`). We really want to be caching the yarn cache, which has pristine packages before install, which I think it will also need to perform the real install anyways.
2. We key the cache on root `package.json`, which is missing a lot of information (both provided by the other `package.json` in the repo, but mostly, the lockfile resolution).
We only save cache when we're on `refs/heads/main` (so continuous builds against main), and supposedly, builds against base branch should be able to restore against those, but recent PR jobs I have seen, where `package.json` has not changed, all have `Cache not found for input keys: node-modules-068350889e87919c1c6c2c220c8d2d92db13f38820bf2efb315d1274b97bc367`
Because of the potential correctness issues, and that the strategy for limiting to main seemingly is not allowing cache to be used in PR, this diff goes back to previous solution, which may store more artifacts (but working cache should also reduce cost by making jobs run faster).
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D67140004
fbshipit-source-id: f74074a498af56b1837fa23cf80795f76935b762
Summary:
This pr tests the Old Arch on the Template app using Maestro
## Changelog:
[Internal] - Test old arch in CI with Maestro for template app
Pull Request resolved: https://github.com/facebook/react-native/pull/48244
Test Plan: GHA
Reviewed By: cortinico
Differential Revision: D67141524
Pulled By: cipolleschi
fbshipit-source-id: bef3a9b6fec9d7c91d858d534a2d00e91f1842b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48238
Use the helper module we have, which has better type-safety and less code duplication.
Changelog: [Internal]
Reviewed By: fabriziocucci
Differential Revision: D67139572
fbshipit-source-id: 39ae9119d97f937b30ad6e7451468cbb3cc37a84
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48235
Recursively calling runTask is not supported, as the inner call will no-op since we're already executing the eventloop.
Currently errors are not correctly propagated, but this at least makes it so that we don't attempt to schedule the task either, which could lead to incorrect assumptions being made.
Changelog: [internal]
Reviewed By: rubennorte
Differential Revision: D67107664
fbshipit-source-id: e665a96671f4812308d87aec3b880ce2009328e2
Summary:
In this PR we introduced a new mechanism for `RawPropsParser` to construct its RawValues directly from `jsi::Value` instead of converting it to `folly::dynamic` first:
- https://github.com/facebook/react-native/pull/48047/
In this PR we added a parameter to `RawPropsParser` to opt-into using the above described mechanism:
- https://github.com/facebook/react-native/pull/48231
Whats missing is that `RawPropsParser` was default constructed in `ComponentProvider` and there is no way to pass a custom instance (where you'd for example set the above described parameter). This PR adds support for that.
## 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
-->
[INTERNAL] [ADDED] - Add `RawPropsParser` as optional parameter to Concrete-/ComponentDescriptor
Pull Request resolved: https://github.com/facebook/react-native/pull/48232
Test Plan: Internal change, just make sure all CI tests are passing.
Reviewed By: cipolleschi
Differential Revision: D67135357
Pulled By: javache
fbshipit-source-id: 45f384d42314976c16cae10d5ea0419d13fd0889
Summary:
`react_native_assert` on iOS uses glog under the hood, and https://github.com/facebook/react-native/pull/47911 added usage to a new podspec, which means new entire binary under some build modes. Need to add missing dependency I think?
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/48241
Test Plan: tes_ios_helloworld passes with DynamicLibraries
Reviewed By: cipolleschi
Differential Revision: D67141052
Pulled By: NickGerleman
fbshipit-source-id: 299a499f40e9b54c4aca5d6e1c95c43ce933fb2b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48224
Changelog: [General][Fixed] Removed unnecessary state updates in React to reflect the current state of looping animations.
This enables that feature flag by default and prepares for an incoming cleanup.
Reviewed By: yungsters, dmytrorykun
Differential Revision: D67109980
fbshipit-source-id: 3c98731221b0fb01a8d49d537df859fe23c0ae45
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48229
Changelog: [internal]
The type definitions for these objects (the exported value by the `ReactNativeFeatureFlags` module, and the input value for `ReactNativeFeatureFlags.override()` method) were writable objects, which is incorrect and causes other problems down the line.
This just makes them read-only.
Reviewed By: yungsters
Differential Revision: D67109719
fbshipit-source-id: 8d56e05042587a53cdd05e51b4207ef27ace2d91
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48225
Fixes https://github.com/facebook/react-native/issues/47762
The weak event emitter in AttributedString attributes is causing a serialization error when typing into a TextInput in a Mac Catalyst build. We can resolve this by not putting the event emitters in the attributed string, but this is likely to cause other issues with event handling for nested <Text> components.
## Changelog
[iOS][Fixed] - Workaround for Mac Catalyst TextInput crash due to serialization attempt of WeakEventEmitter
Reviewed By: NickGerleman
Differential Revision: D66664583
fbshipit-source-id: efdfbcb0db4d5e6b9bf7c14f9bbb221faae2d724
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48200
Wires up `Performance.mark()` events, completing support for User Timings in Fusebox.
Other changes:
- Refactors `reportMeasure` to receive a `duration`.
- Fixes conversion for time values (ms -> µs) in emitted trace events.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D66704283
fbshipit-source-id: 352abbade26eb976e793481dde04463431bf2eb7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48043
Adds a new `PerformanceTracing` API to replace `ReactPerfLogger` and `FuseboxTracer`.
- Mostly a clone of `FuseboxTracer`, with small refactorings.
- Exposes a new `CdpTracing.h` header, intended for shared CDP/Chrome types (that will later propagate through to the runtime impl of `performance.mark,measure()`).
- These live in a new `jsinspector_tracing` library, to avoid a dependency cycle.
**Key change**: With both diffs, `PerformanceTracer` is added to `PerformanceEntryReporter` to initially wire up the `performance.measure` event — replacing the previous routing.
- `FuseboxTracer` remains load-bearing for the out-of-tree call to `stopTracingAndWriteToFile()`.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D66650181
fbshipit-source-id: 9092257f23cdb8746e69f5ff3eb7dbf4c8142938
Summary:
When running the linter locally, noise is generated from the `packages/react-native/ReactAndroid/build` folder. This folder does not need to be checked, as it is already excluded in the [.gitignore](https://github.com/facebook/react-native/blob/main/.gitignore#L33).
## Changelog:
[INTERNAL] - Exclude `packages/react-native/ReactAndroid/build` from lint checks
Pull Request resolved: https://github.com/facebook/react-native/pull/48217
Test Plan:
```bash
yarn lint
```
Reviewed By: huntie
Differential Revision: D67134035
Pulled By: cortinico
fbshipit-source-id: f314c8601d6a3bf8ac6ebed67bdc392c6a6aeba8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48227
This option is on by default in Flow v0.256
Reviewed By: gkz
Differential Revision: D67117062
fbshipit-source-id: 1595afe48178529ad43b33a215d84ff225cf9fa9
Summary:
In react-native-windows our static analysis tools report an error for `timeoutForSchedulerPriority` due to cases where it may not always return a value. This is an upstreaming of the patch we have to fix that error.
## Changelog:
[INTERNAL] [FIXED] - Fix no return static analysis error in SchedulerPriorityUtils.h
Pull Request resolved: https://github.com/facebook/react-native/pull/47911
Test Plan: Building should be sufficient.
Reviewed By: christophpurrer
Differential Revision: D66992063
Pulled By: NickGerleman
fbshipit-source-id: 999fea328d0c66ad92314f537e41beff5856c285
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47946
Object creation with custom prototype can currently be done, but it is
unnecessarily convoluted. Users have to call into the global object to
get the `Object.create` function, then call it with the custom
prototype.
This diff adds a JSI API for Object.create(prototype) to make it easy
for users.
Changelog: [Internal]
Reviewed By: avp
Differential Revision: D66485209
fbshipit-source-id: 32018f847190ac16f695f011a78be0c45c4c4659
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47996
Getting and setting an Object's prototype is convoluted. Users have to
call into the global object to get the method, then call it.
This diff adds a JSI API for Object.getPrototype and Object.setPrototype
to make it easy for users.
Changelog: [Internal]
Reviewed By: fbmal7
Differential Revision: D66562549
fbshipit-source-id: 85a2e49deb9d00500544de4cc5ab123c4717398e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48208
[Changelog] [Internal] - Remove unused (Android) TextLayoutManager getter
This getter
```
void* getNativeTextLayoutManager() const;
```
is not used on Android and different in signature to the iOS one:
```
std::shared_ptr<void> getNativeTextLayoutManager() const;
```
Deleting it for now to make future code sharing between various platforms easier.
This change removes further the by now discouraged pattern of:
```
using SharedTextLayoutManager = std::shared_ptr<const TextLayoutManager>;
```
and changes callers to use
```
std::shared_ptr<const TextLayoutManager>;
```
directly.
Reviewed By: javache
Differential Revision: D67059514
fbshipit-source-id: b94dc7f664083c5c62c4ba7defca480549ca9dc1
Summary:
# Summary
I'm working to get the main `react-native` package parsable by modern
Flow tooling (both `flow-bundler`, `flow-api-translator`).
This diff trivially removes some redundant Flow comment syntax in
`ReactNativeTypes.js`, which fixes parsing under these newer tools.
## How did you test this change?
Files were pasted into `react-native-github` under fbsource, where Flow
validates ✅.
DiffTrain build for [92b62f500c3fca44a9dc9ead936ef3bf19481f02](https://github.com/facebook/react/commit/92b62f500c3fca44a9dc9ead936ef3bf19481f02)
Reviewed By: huntie
Differential Revision: D67100354
Pulled By: hoxyq
fbshipit-source-id: 575e4bd8ceefad15576273920a263ae89d027cad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48216
The `React-graphics` podspec is manually excluding some paths from the source_files but this approach is error prone. For esample changes that added new paths that must be excluded can create failures.
This change the podspec file to explicitly add only the files that iOS requires.
## Changelog:
[iOS][Changed] - Explicitly define the source files for React-graphics
## Facebook:
This change is necessary because we added the macos platform that was not included before and now we can't build RNTester from fbsource using the internal pipeline.
Reviewed By: hoxyq
Differential Revision: D67095677
fbshipit-source-id: 701d5938f6e141a313be62c8f930a089e1d6ee96
Summary:
### Motivation:
We are looking for a way to access the "raw" jsi value in our fabric view components, so that we can pass complex types like `HostObjects` or `jsi::Object` with `NativeState` attached to our components directly.
Currently the props are converted from `jsi::Object` to `folly::dynamic`, which prevents us from accessing these values directly.
### Changes
This PR is a implementation of the proposal discussed here:
- https://github.com/facebook/react-native/pull/44966#issuecomment-2503915245
These changes extend `RawValue` so that it can be directly constructed from `RawValue(Runtime*, jsi::Value&)` (not just from `folly::dynamic`).
`RawValue`s are created by the `RawPropParser.cpp`. By default it will use the `RawValue(folly::dynamic)` constructor, but we added a feature flag called `useRawPropsJsiValue`, which will sue the JSI constructor.
This enables to test this feature at runtime incrementally.
This change might also be tested on a component basis, by setting a flag in the component descriptor to enable JSI prop parsing for the RawPropParser, as outlined in this PR:
- https://github.com/hannojg/react-native/pull/2
## 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] - Add `useRawPropsJsiValue` feature flag to represent props internally as `jsi::Value`s instead of converting them to `folly::dynamic`
[General] [Added] - Added `RawValue(Runtime*, jsi::Value&)` constructor to make a `RawValue` from a `jsi::Value`.
Pull Request resolved: https://github.com/facebook/react-native/pull/48047
Test Plan: Enable the `useRawPropsJsiValue` feature flag and test the rn-tester app on android and iOS. Make sure you get no new errors / warnings in the native console.
Reviewed By: NickGerleman
Differential Revision: D66877093
Pulled By: javache
fbshipit-source-id: 7342e5f86d2492ad63a9ccf5508f04e7eb252def
Summary:
`JSBigFileString` incorrectly passes the file offset to `mmap`, causing errors when `offset` is non-zero.
## Changelog:
[GENERAL] [FIXED] - `JSBigFileString` fails for non-zero offset arguments
Pull Request resolved: https://github.com/facebook/react-native/pull/48198
Test Plan: - verify the new unit test passes
Reviewed By: cipolleschi
Differential Revision: D67086826
Pulled By: javache
fbshipit-source-id: 0991bb34a710b85ff0263dc553efb85ba62b4cd8
Summary:
While I was [working on fixing the iOS debugger logic](https://github.com/facebook/react-native/pull/48174) based on configuration name regex match, I wanted to know if other logic was also based on configuration names. I think I found and fixed the only other configuration name-based logic in the repo in this PR.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [CHANGED] - Use configuration type when adding ndebug flag to pods in release
Pull Request resolved: https://github.com/facebook/react-native/pull/48193
Test Plan:
In a fresh react-native project, I added to the Podfile:
```ruby
installer.aggregate_targets.each do |aggregate_target|
aggregate_target.xcconfigs.each do |config_name, config_file|
is_release = aggregate_target.user_build_configurations[config_name] == :release
puts "aggregate_targets #{config_name} is_release: #{is_release}"
end
end
installer.target_installation_results.pod_target_installation_results.each do |pod_name, target_installation_result|
target_installation_result.native_target.build_configurations.each do |config|
is_release = config.type == :release
puts "target_installation_results #{config.name} is_release: #{is_release}"
end
end
```
to confirm my logic. It output the following:
```
aggregate_targets Release is_release: true
aggregate_targets Local is_release: false
...
target_installation_results Local is_release: false
target_installation_results Release is_release: true
...
```
I also updated the applicable tests I could find for this logic.
Reviewed By: cortinico
Differential Revision: D67025325
Pulled By: cipolleschi
fbshipit-source-id: 45d68ee86e3255d843275a72916883c8c4bbc13d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48164
[Changelog] [Internal] - Share common ShadowNode functionality in BaseTextInputShadowNode for iOS
The current Android and iOS implementations have quite some overlapping functionality. Not sharing common logic makes it also harder to reuse this [functionality] for out of tree platforms.
This change moves the current iOS implementation into a shared location.
The next change allows to reuse it for Android.
Reviewed By: NickGerleman
Differential Revision: D66901676
fbshipit-source-id: a870155633875377d881fbd9f41fafb305672949
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48201
For any build for which we enable the perfetto build flag, we should probably enable the `__RCTProfileIsProfiling` so we get systrace markers.
Changelog: [Internal]
Reviewed By: bgirard
Differential Revision: D67031171
fbshipit-source-id: 5e7f56f911acacd3156778bd9151202fc809e291
Summary:
Fixes https://github.com/facebook/react-native/issues/39260
Right now, there is a small issue when you try debugging the Networking library methods as it seems like they are empty in Android. This is not an actual functional issue as everything in code works fine, but rather an inconsistency in how the iOS and Android methods are being exported. In iOS it was exported as an object, in Android it was a class.
## Changelog:
[INTERNAL] - Making `RCTNetworking` js exports consistent
Pull Request resolved: https://github.com/facebook/react-native/pull/48166
Test Plan:
I've checked that `XMLHttpRequest` is still working as expected, as this is used mostly there.
And below there are screenshots of how the module methods are logged after the refactor. Which addresses what was reported in the linked issue.
```js
import {Networking} from 'react-native';
import AndroidNetworking from 'react-native/Libraries/Network/RCTNetworking.android.js';
import IOSNetworking from 'react-native/Libraries/Network/RCTNetworking.ios.js';
console.log({Networking, AndroidNetworking, IOSNetworking});
```
Before | After
-- | --
<img width="1196" alt="image" src="https://github.com/user-attachments/assets/b7ab1dcd-9dd1-4ed9-ade5-d90251a77d5e"> | <img width="1196" alt="image" src="https://github.com/user-attachments/assets/5ae17c6a-b068-462a-b228-576dcf08ef12">
Reviewed By: fabriziocucci
Differential Revision: D67022711
Pulled By: javache
fbshipit-source-id: 81f9988295fb3f559a795077f09ee0f14827dc86
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47247
Changelog: [internal]
Bye bye `ReactNativeConfig` 👋.
All existing usages of the API have been cleaned up or migrated to `ReactNativeFeatureFlags`, so this is no longer needed.
Reviewed By: GijsWeterings
Differential Revision: D65062306
fbshipit-source-id: 76afcd48ad72023b6dc2a90955ae2f03a1164cca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47246
Changelog: [internal]
Just to use CI to verify there are no more existing usages of the API before cleaning it up.
Reviewed By: GijsWeterings
Differential Revision: D65062302
fbshipit-source-id: e1b71d39ef1fba23cc68e36fe0a0b57cfc2a614e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48199
`animatedShouldUseSingleOp` relies on a queue always being active, or for a call to `flushQueue` later down the line. If these are missing, a call will be queued up but only executed whenever the next animation flush happens.
Changelog: [General][Fixed] Animation.stop() executes when `animatedShouldUseSingleOp` is enabled.
Reviewed By: yungsters
Differential Revision: D67025831
fbshipit-source-id: 66a7f50d833b7bbaf9f16dd04d24b90c7a699fa0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48182
Maintainers from SVG reached out because of an edge case they inencountered when generating the ComponentProvider. In their setup, they had a `.git` folder in the repo and the algorithm was spending a lot of time crawling the git folder.
In general, we should avoid crawling hidden folders.
This change fix that.
## Changelog:
[General][Fixed] - Skip hidden folders when looking for third party components.
Reviewed By: javache
Differential Revision: D66959345
fbshipit-source-id: 992a79f3cff22cd6a459e0272c8140bc329888da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48029
Changelog: [Internal]
Adding snapshot support for rendered output only for now.
This will only work if snapshot is created beforehand by hand.
# Next steps
* Create snapshot when no prior snapshot is available
* Pass and update if instructed
Reviewed By: christophpurrer
Differential Revision: D66601387
fbshipit-source-id: fe528cded43c5ba36d314bd9af8e3fb84b98ac3e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47939
Before we were clipping Android background drawable to the padding box. This is not how its done on web.
The background should remain under the border so that if the border is traslucent you can see the background underneath
Reviewed By: NickGerleman
Differential Revision: D66463305
fbshipit-source-id: 427acea760b2748a07cc28bbd362aaaae0811093
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48133
[Changelog] [Internal] - Share common (Base)TextInputState properties
This change allows to share common TextInput State properties between various platforms.
Reviewed By: rshest
Differential Revision: D66855831
fbshipit-source-id: d0f85c419b82445ac84bfcc606f1bf752f5dba73
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47973
Gap can be styled using both `points` and `percentages`, but YGNodeStyleGetGap currently returns a float value.
To maintain alignment with the `padding` and `margin` functionalities and allow it to be handled in bridging code, this function has been updated to return YGValue.
X-link: https://github.com/facebook/yoga/pull/1753
Reviewed By: joevilches
Differential Revision: D66513236
Pulled By: NickGerleman
fbshipit-source-id: b7110855c037f20780f031f22a945bde4446687d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48161
[Changelog] [Internal] - Remove unused defaultThemePaddingStart|End|Top|Bottom from AndroidTextInputState
This data is set, but never read
Reviewed By: javache
Differential Revision: D66904641
fbshipit-source-id: 4db1cd49e9ec63b62f75070b478d2006ea101f8c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48180
Changelog: [Internal]
Releasing runtime shadow node reference updates, enabling it by default now that the fix for RN Windows landed.
Reviewed By: javache
Differential Revision: D66959896
fbshipit-source-id: dcf1c4a7257fe60ae0faffe1952fc2c80effe406
Summary:
Fixes https://github.com/facebook/react-native/issues/47045
On Android `adjustsFontSizeToFit` relies on two metrics:
- Text with line breaks results in more lines than `maximumNumberOfLines`
- The overall height of the text is larger than the available height
None of these two was fulfilled when a single-character string had a higher width than the available one (a single character will not be broken into multiple lines). This PR adds exactly that as a third option to trigger the scaling algorithm - a single-character string that has a higher width than the available one.
On iOS `adjustsFontSizeToFit` relies on `truncatedGlyphRangeInLineFragmentForGlyphAtIndex` which seems to be returning `NSNotFound` when a single-character sting gets truncated. Similarly to Android, this PR adds an additional check to make sure that single-character strings actually fit inside the container.
## Changelog:
[GENERAL] [FIXED] - Fixed `adjustsFontSizeToFit` not working for text with a single character
Pull Request resolved: https://github.com/facebook/react-native/pull/47082
Test Plan:
Tested on the code from the issue:
|Android (old arch)|Android (new arch)|iOS (old arch)|iOS (new arch)|
|-|-|-|-|
|<img width="406" alt="android_old" src="https://github.com/user-attachments/assets/91b1af41-4ef7-46cc-bb04-374f860d93ac">|<img width="406" alt="android_new" src="https://github.com/user-attachments/assets/90e3cde1-e6c0-4b25-8325-c62a37773002">|<img width="546" alt="ios_old" src="https://github.com/user-attachments/assets/902b9c10-84e0-4372-bcc8-07cd1ef006f6">|<img width="546" alt="ios_new" src="https://github.com/user-attachments/assets/f4df4f0e-7649-47f3-9c81-e38f8665d9a2">|
Reviewed By: javache
Differential Revision: D64664351
Pulled By: NickGerleman
fbshipit-source-id: b68f318a0fbd5ebed947a70d1e3fb0515b5fb409
Summary:
Fixes an [issue](https://github.com/facebook/react-native/issues/48168) where only iOS configurations with "Debug" in the name are configured to use the hermes debugger.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [FIXED] - Enable hermes debugger by configuration type instead of configuration name
Pull Request resolved: https://github.com/facebook/react-native/pull/48174
Test Plan:
Added new test scenarios that all pass:
```
ruby -Itest packages/react-native/scripts/cocoapods/__tests__/utils-test.rb
Loaded suite packages/react-native/scripts/cocoapods/__tests__/utils-test
Started
Finished in 0.336047 seconds.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
56 tests, 149 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
166.64 tests/s, 443.39 assertions/s
```
In a personal project with the following configurations:
```
project 'ReactNativeProject', {
'Local' => :debug,
'Development' => :release,
'Staging' => :release,
'Production' => :release,
}
```
I added the following to my Podfile:
```
installer.pods_project.targets.each do |target|
target.build_configurations.each do |config|
puts "#{config.name} is debug? #{config.type == :debug}"
end
end
```
To confirm that my logic is correct:
```
Local is debug? true
Development is debug? false
Staging is debug? false
Production is debug? false
```
Reviewed By: robhogan
Differential Revision: D66962860
Pulled By: cipolleschi
fbshipit-source-id: 7bd920e123c9064c8a1b5d45df546ff5d2a7d8be
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48113
Processing cookies can have a non-trivial impact on startup-time. It requires reading OkHttp's `PublicSuffixDatabase` but also allocating various WebKit components. Instead handle the cookiejar being set to non-CookieJarContainer instances gracefully, which allows a custom client builder to set `CookieJar.NO_COOKIES`.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D66787514
fbshipit-source-id: bf790691496f674ec743ba4791552b12e06eda29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48178
Changelog: [internal]
Adds a new mode for Fantom to run tests with dev-mode bytecode. Right now the modes were only dev (development with source code) or opt (optimized bytecode).
Reviewed By: rshest
Differential Revision: D66888986
fbshipit-source-id: 34b2566a65d138790e16f8fb5787fd9c2bcde536
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48179
Changelog: [internal]
Migrating this type to an enum, which is safer, because it prevents errors like:
```
// when it's actually 'dev'
if (mode === 'development') {
}
```
Reviewed By: rshest
Differential Revision: D66888985
fbshipit-source-id: 4f3f91fad6ca5256baa2123425b2bad11fe036f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48151
Changelog: [internal]
We have global setup step in Fantom to prewarm caches to properly attribute test running time, but this isn't necessary when running tests locally. Attribution isn't as important there. This disables the prewarming step so we can run individual tests as fast as we can.
Reviewed By: sammy-SC
Differential Revision: D66877990
fbshipit-source-id: 1f33c19a3c537c1c0e499fd7a6c405450cb9f86d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48150
Changelog: [internal]
We're starting to have some Fantom tests that run in optimized mode, but we're not currently prewarming for that case. This adds that capability to do proper attribution of run time for tests.
Reviewed By: javache
Differential Revision: D66877991
fbshipit-source-id: dccb80cd6a4f664de7df0661456bad78d960826d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48123
Changelog: [internal]
This verifies that the modes specified in the pragmas are applied correctly.
Reviewed By: andrewdacenko
Differential Revision: D66822377
fbshipit-source-id: 420f21f171c5d356ab91b49f7a33345386f6f0c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48012
Match the OkHttp version we use for NetworkingModule and FrescoModule, to unblock pulling in D66498305
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D66595222
fbshipit-source-id: 1c29b061866be5d8bcc87aaa0c8a1de846198e4e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48136
[Changelog] [Internal] - Remove unused code in AndroidTextInputShadowNode.h|cpp
A bit of code clean-up to simplify a planned refactoring of this class
Reviewed By: rshest
Differential Revision: D66862820
fbshipit-source-id: 88114d8711b572f105d804cdddc6c087c94e3f49
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48094
There were a few math inaccuracies in the algorithm for overlapping radii. After fixing there were also minor pixel differences on the unit tests but this is the most correct implementation.
Also, improved the algorithm's verbiage since stuff like "EdgeInset" is not really related and is misleading to what the algorithm is actually doing. (Edge Insets play no part in this)
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D66728227
fbshipit-source-id: 56a6d59504e784fc245ed6fe306402a15cfd9611
Summary:
X-link: https://github.com/facebook/yoga/pull/1763
Pull Request resolved: https://github.com/facebook/react-native/pull/48080
Small bug that I noticed while doing intrinsic sizing. We have the ownerHeight as the axis size despite bounding the length of the cross axis. This should therefore be the crossAxisOwnerSize, which might be the width in some cases
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D66736539
fbshipit-source-id: 528fc438b3327cd6f7890ea0ba408e4ce7b0f02c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48129
Continuation of https://github.com/facebook/react-native/pull/48106
* Every AnimatedNode subclasses now have an optional `config` arg as last arg in constructor. `Animation` base constructor already takes in config with debugID, since last PR.
* thread down debugID value to all the native configs
Changelog: [Internal] Allow setting debugID on all types of AnimatedNode and Animation
Reviewed By: yungsters
Differential Revision: D66834935
fbshipit-source-id: 18e5cbc3f701114ef945a237cb5944ef5eb6408e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48127
[Changelog] [Internal] - Allow to provide a custom TextLayoutManager for cxx platform
This change allows target platforms to pass a platform specific or app specific TextLayoutManager implementation
Reviewed By: zeyap
Differential Revision: D66802434
fbshipit-source-id: a64e28d357bf601c7234b43f86538f49e62c8435
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48100
This diff renames `shouldNotify` to `shouldNotifyLoadEvents` as it is named in the spec.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D66769660
fbshipit-source-id: 64282c08ab82101d51dedb583e0c34476ed90eeb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48124
Fixes https://github.com/facebook/react-native/issues/47592
The logic in HeadlessJsTaskService is broken. We should not check whether `getReactContext` is null or not.
Instead we should use the `enableBridgelessArchitecture` feature flag to understand if New Architecture was enabled or not.
The problem we were having is that `HeadlessJsTaskService` was attempting to load the New Architecture even if the user would have it turned off. The Service would then die attempting to load `libappmodules.so` which was correctly missing.
Changelog:
[Android] [Fixed] - Fix crash on HeadlessJsTaskService on old architecture
Reviewed By: javache
Differential Revision: D66826271
fbshipit-source-id: 2b8418e0b01b65014cdbfd0ec2f843420a15f9db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48146
The NoRetryPolicy class is `internal`. Having those `public` modifiers on methods has no effect
and can be safely removed.
Changelog:
[Internal] [Changed] -
Reviewed By: fabriziocucci
Differential Revision: D66875443
fbshipit-source-id: 64c63c7000617cf94c36ce3d25927d3a270ac370
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48132
Backs out D63573322 and D65645981, reverting the change that makes callbacks passed to `animation.start(<callback>)` scheduled for execution in a microtask.
This is being reverted becuase the latency introduced by the current macro and pending micro tasks can introduce visible latency artifacts that diminish the fidelity of animations.
Changelog:
[General][Changed] - Reverts #47503. (~~Callbacks passed to `animation.start(<callback>)` will be scheduled for execution in a microtask. Previously, there were certain scenarios in which the callback could be synchronously executed by `start`.~~)
Reviewed By: javache
Differential Revision: D66852804
fbshipit-source-id: 08434b9876813fe9e8b189b6b467198933843bf0
Summary:
Someone always has to merge in from Meta, so this is just noise.
Refactored some of this older code.
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/48148
Test Plan:
This PR, but this doesn't build a lot of confidence:
{F1973526183}
Reviewed By: rubennorte
Differential Revision: D66876722
Pulled By: blakef
fbshipit-source-id: 52e1f15577f8f057ceee9427af65df43f152bffa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48144
Changelog: [internal]
Adds package.json script to run Fantom tests:
```
yarn fantom
```
NOTE: At the moment, this only works on Meta's infra. We're working on making this available in OSS/Github CI.
Reviewed By: javache
Differential Revision: D66874962
fbshipit-source-id: d9746428b618a31ce0bf96c3233828cdba501dd6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48143
Changelog: [internal]
Just a small cleanup to move `jest/integration/*` to `packages/react-native-fantom`, so everything related to Fantom (config, runner, runtime, etc.) is in the same directory.
Reviewed By: javache
Differential Revision: D66874763
fbshipit-source-id: 8b87d7320c7704f7ce6cd58761508193784f5ce2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48142
Changelog: [internal]
This is the default export from the `react-native/fantom` package and it makes sense to be called that way. Also, this is similar to the `jest` global.
Reviewed By: javache
Differential Revision: D66874225
fbshipit-source-id: 8b43a637ebb42b5b1acb9ea5a6dbedd4c1a4f9e0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48141
Changelog: [internal]
This just aligns the file name with the common convention to name modules with the same name as their default export (if any).
Reviewed By: javache
Differential Revision: D66874227
fbshipit-source-id: 2a619b434c26a29f1774cba1c32ba711b1a7af46
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48140
Changelog: [internal]
These tests test an API that's part of `ReactNativeTester` (will be renamed as `Fantom`) so it makes sense that they're in the same test file as the tests for the rest of the API.
Reviewed By: javache
Differential Revision: D66874226
fbshipit-source-id: f17e14c83cb5ca95ac619c5398c49ad84a27cfa5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48125
Changelog: [internal]
This just moves the runtime modules for Fantom to its own package.
Reviewed By: javache
Differential Revision: D66825478
fbshipit-source-id: ac4dbc23b86895f09abc46345d497c1c53737ae2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48145
While writing the docs for 0.77, I found an edge case in the generation of the RCTThirdPartyComponentProvider:
* If the app has the `codegenConfig` field set in the `package.json`
* And it does not have the `ios.componentProvider` field is not provided
Codegen was generating the mapping for the react-native core components. That's not expected as, in that case, it should only generate components that are declared in the app or in libraries.
This change fixes this edge case.
## Changelog:
[Internal] - Exclude mapping generation of core component
Reviewed By: blakef
Differential Revision: D66875080
fbshipit-source-id: 65fe10381729ec7808efec70feacf2a55f0056e9
Summary:
This PR adds `pointerEvents` to the `TextProps` type.
### Motivation:
The `pointerEvents` property is already supported in `Text` components internally, but it was missing from the TypeScript definitions. By adding it to `TextProps`, developers can now use this property with full type safety and without TypeScript errors.
This is a type-only change and does not introduce any functional modifications.
## Changelog:
[GENERAL] [ADDED] - Added `pointerEvents` to `TextProps` type.
Pull Request resolved: https://github.com/facebook/react-native/pull/48081
Test Plan:
As this is a type-only update:
- Verified that the `pointerEvents` property is now recognized when used with `Text` components in TypeScript projects.
- Ensured there are no runtime changes or regressions by testing existing `Text` components for expected behavior.
Reviewed By: cipolleschi
Differential Revision: D66753454
Pulled By: javache
fbshipit-source-id: c8f21b11daa6001a309b1d29fd6259101d11f5d2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48062
We never need the full ShadowView representation of `parent` and this is significantly cheaper to construct and pass around.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D66656411
fbshipit-source-id: 0b20e04c6beb95c498350085ec06fd57d1c11237
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48106
This could make it easier to locate and debug AnimatedValue and driver from native - so far on the native side of animated, the only way to identify an Animation driver or AnimatedNode is integer IDs and the type, which made it difficult to debug when surface gets complicated
Here I only enabled it for AnimatedValue and TimingAnimation, because
* TimingAnimation is most commonly used
* all the animation drivers (frames, spring, decay) can only drive Value type of AnimatedNode on the native side, so it's the primitive component of AnimatedNode
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D66790298
fbshipit-source-id: ddd64a5728120f061aa902f25c93b1701617031b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47530
Adds the default implementation for `getStringData`/`getPropNameIdData`
for VMs that do not provide their own implementation
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D65638889
fbshipit-source-id: 0a97569433c09ffafbd08fec5d9c9fbf5639b778
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48109
[Changelog] [Internal] - Allow to provide a custom ImageManager for cxx platform
This change allows target platforms to pass a platform specific or app specific ImageManager implementation
Reviewed By: javache
Differential Revision: D66788794
fbshipit-source-id: d7e99cae5de0a4c60047763dce368271dd191b9c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48097
Changelog: [internal]
As per title, this allows us to specify both common and JS-only feature flags for tests in the docblock as pragmas (in the same pragma separated by spaces, or in different pragmas). E.g.:
```
/**
* fantom_flags commonTestFlag:true
* fantom_flags jsOnlyTestFlag:true
*/
```
The feature flags are overridden automatically for us before the tests start.
Reviewed By: javache
Differential Revision: D66760121
fbshipit-source-id: 7e227e0035a170dab81b1e6ce39600a01a748867
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48093
Changelog: [internal]
We're going to add support for specifying feature flags in Fantom tests in pragmas. E.g.:
```
/**
* fantom_flags commonTestFlag:true
*/
```
Users will be able to specify any feature flags in their tests, so we need a way to pass that information from the test file to the runner, and the runner has to be able to apply this dynamic configuration.
Because the API is statically typed in C++, we need to define a method for every possible feature flag configurable through this API. We could do it in userland, but we'd have to manually add a method every time there was a new feature flag we wanted to support.
Instead of doing that, this introduces a new abstraction in the feature flag system that codegens it for you.
The API is basically:
```
folly::dynamic values = folly::dynamic::object();
values["commonTestFlag"] = true;
ReactNativeFeatureFlags::override(
std::make_unique<ReactNativeFeatureFlagsDynamicProvider>(values));
EXPECT_EQ(ReactNativeFeatureFlags::commonTestFlag(), true);
```
Then we can use this abstraction in Fantom to pass all the configured flags as `folly::dynamic` through this API.
Reviewed By: javache
Differential Revision: D66760118
fbshipit-source-id: c32329e5ca76923c3e0b9c0eb1fe8c3268e1f57b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48089
Planning to make some changes here for perf, but converting to Kotlin first
Changelog: [Android][Removed] Made ReactCookieJarContainer internal.
Reviewed By: tdn120
Differential Revision: D66724567
fbshipit-source-id: bf96f8df8a5c901b47c371c7ed16b7a81de22ee7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48088
Planning to make some changes here for perf, but converting to Kotlin first
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D66724321
fbshipit-source-id: dec7f7123abdcd5792b3d589269b40ad42b3d307
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48105
LLVM-15 has a warning `-Wunused-variable` which we treat as an error because it's so often diagnostic of a code issue. Unused variables can compromise readability or, worse, performance.
This diff either (a) removes an unused variable and, possibly, it's associated code or (b) qualifies the variable with `[[maybe_unused]]`.
- If you approve of this diff, please use the "Accept & Ship" button :-)
Changelog: [Internal]
Reviewed By: palmje
Differential Revision: D66777665
fbshipit-source-id: fadf71fd37c2b95f87419acf9d5a7765fe031905
Summary:
GHA to build HermesC for windows are failing because the machines comes with a different CMake version already.
Let's try not to install Cmake and use the one provided by the machine.
## Changelog:
[Internal] -
Pull Request resolved: https://github.com/facebook/react-native/pull/48122
Test Plan: GHA {F1973187648}
Reviewed By: alanleedev
Differential Revision: D66825216
Pulled By: cipolleschi
fbshipit-source-id: 9a9376a5409e192195a6b6cc25b4d58cb47f15da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48092
Changelog: [internal]
This is just in preparation to expand the scope of that function to include configuration for feature flags.
Reviewed By: javache
Differential Revision: D66760119
fbshipit-source-id: e955e8f596697ac6a0a87013bec3fc3e09caf19d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48087
Changelog: [internal]
Now that we have Fantom tests for these unit tests that use mocks, we can remove the JS tests and the mocks :)
Reviewed By: sammy-SC
Differential Revision: D66599197
fbshipit-source-id: 33822588c2176ffe2f2631da56c671b299f8058d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48086
Changelog: [internal]
Just adding a bit of coverage for the `expect` API adding `toBeLessThan` and `toBeGreaterThan`.
Reviewed By: sammy-SC
Differential Revision: D66753268
fbshipit-source-id: 6a26f558f985ccbb5eb0daacecd93759841149e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48083
Changelog: [internal]
Just a small refactor to have a better code organization for the testing runtime infra.
Reviewed By: sammy-SC
Differential Revision: D66753269
fbshipit-source-id: e68727fe45fabe0be3528e21d5a60cef3045c252
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48063
Changelog: [internal]
This allows async functions to be passed to `runTask` (just a type change really) and adds tests for ReactNativeTester. Error handling isn't currently set up correctly, so those tests are disabled for now.
Reviewed By: sammy-SC
Differential Revision: D66698547
fbshipit-source-id: 41d1fccc80f90cdf764f6fa3d3d34365eeef8ec6
Summary:
Handling `long` values is not implemented in Writables. I added it on the native side.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [FIXED] - Support Long values in WritableMap and WritableArray
Pull Request resolved: https://github.com/facebook/react-native/pull/48017
Test Plan: Run https://github.com/WoLewicki/reproducer-react-native/tree/%40wolewicki/long-in-writeable-map and see it doesn't work without those changes.
Reviewed By: javache
Differential Revision: D66754194
Pulled By: cortinico
fbshipit-source-id: 7f8d4eb3c4069f890460525ddffdf9f4324550b0
Summary:
This action is no longer necessary and we can remove it
## Changelog:
[Internal] [Fixed] - Use `refs/pulls` namespace in trigger action
Pull Request resolved: https://github.com/facebook/react-native/pull/47923
Reviewed By: NickGerleman
Differential Revision: D66578573
Pulled By: cortinico
fbshipit-source-id: 87cdbc1544873a2669e82c7763c78d18ff7881fd
Summary:
Related PR in `react-native-screens`:
* https://github.com/software-mansion/react-native-screens/pull/2495
Additional context:
* [my detailed explanation of **one of the issues**](https://github.com/software-mansion/react-native-screens/pull/2495#issuecomment-2478915818)
* [Android Developer: ViewGroup.startViewTransition docs](https://developer.android.com/reference/android/view/ViewGroup#startViewTransition(android.view.View))
### Background
On Android view groups can be marked as "transitioning" with a `ViewGroup.startViewTransition` call. This effectively ensures, that in case a view group is marked with this call and its children are removed, they will be still drawn until `endViewTransition` is not called.
This mechanism is implemented in Android by [keeping track of "transitioning" children in auxiliary `mTransitioningViews` array](https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/view/ViewGroup.java#7178). Then when such "transitioning" child is removed, [it is removed from children array](https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/view/ViewGroup.java#5595) but it's [parent-child relationship is not cleared](https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/view/ViewGroup.java#5397) and it is still retained in the auxiliary array.
Having that established we can proceed with problem description.
### Problem
https://github.com/user-attachments/assets/d0356bf5-2f17-4b06-ba53-bfca659a1071
<details>
<summary>Full code</summary>
```javascript
import { NavigationContainer } from 'react-navigation/native';
import React from 'react';
import { createNativeStackNavigator } from 'react-navigation/native-stack';
import { enableScreens } from 'react-native-screens';
import {
StyleSheet,
Text,
View,
FlatList,
Button,
ViewProps,
Image,
FlatListProps,
findNodeHandle,
} from 'react-native';
enableScreens(true);
function Item({ children, ...props }: ViewProps) {
return (
<View style={styles.item} {...props}>
<Image source={require('../assets/trees.jpg')} style={styles.image} />
<Text style={styles.text}>{children}</Text>
</View>
);
}
function Home({ navigation }: any) {
return (
<View style={styles.container}>
<Button title="Go to List" onPress={() => navigation.navigate('List')} />
</View>
);
}
function ListScreenSimplified({secondVisible}: {secondVisible?: (visible: boolean) => void}) {
const containerRef = React.useRef<View>(null);
const innerViewRef = React.useRef<View>(null);
const childViewRef = React.useRef<View>(null);
React.useEffect(() => {
if (containerRef.current != null) {
const tag = findNodeHandle(containerRef.current);
console.log(`Container has tag [${tag}]`);
}
if (innerViewRef.current != null) {
const tag = findNodeHandle(innerViewRef.current);
console.log(`InnerView has tag [${tag}]`);
}
if (childViewRef.current != null) {
const tag = findNodeHandle(childViewRef.current);
console.log(`ChildView has tag [${tag}]`);
}
}, [containerRef.current, innerViewRef.current, childViewRef.current]);
return (
<View
ref={containerRef}
style={{ flex: 1, backgroundColor: 'slateblue', overflow: 'hidden' }}
removeClippedSubviews={false}>
<View ref={innerViewRef} removeClippedSubviews style={{ height: '100%' }}>
<View ref={childViewRef} style={{ backgroundColor: 'pink', width: '100%', height: 50 }} removeClippedSubviews={false}>
{secondVisible && (<Button title='Hide second' onPress={() => secondVisible(false)} />)}
</View>
</View>
</View>
);
}
function ParentFlatlist(props: Partial<FlatListProps<number>>) {
return (
<FlatList
data={Array.from({ length: 30 }).fill(0) as number[]}
renderItem={({ index }) => {
if (index === 10) {
return <NestedFlatlist key={index} />;
} else if (index === 15) {
return <ExtraNestedFlatlist key={index} />;
} else if (index === 20) {
return <NestedFlatlist key={index} horizontal />;
} else if (index === 25) {
return <ExtraNestedFlatlist key={index} horizontal />;
} else {
return <Item key={index}>List item {index + 1}</Item>;
}
}}
{...props}
/>
);
}
function NestedFlatlist(props: Partial<FlatListProps<number>>) {
return (
<FlatList
style={[styles.nestedList, props.style]}
data={Array.from({ length: 10 }).fill(0) as number[]}
renderItem={({ index }) => (
<Item key={'nested' + index}>Nested list item {index + 1}</Item>
)}
{...props}
/>
);
}
function ExtraNestedFlatlist(props: Partial<FlatListProps<number>>) {
return (
<FlatList
style={styles.nestedList}
data={Array.from({ length: 10 }).fill(0) as number[]}
renderItem={({ index }) =>
index === 4 ? (
<NestedFlatlist key={index} style={{ backgroundColor: '#d24729' }} />
) : (
<Item key={'nested' + index}>Nested list item {index + 1}</Item>
)
}
{...props}
/>
);
}
const Stack = createNativeStackNavigator();
export default function App(): React.JSX.Element {
return (
<NavigationContainer>
<Stack.Navigator screenOptions={{ animation: 'slide_from_right' }}>
<Stack.Screen name="Home" component={Home} />
<Stack.Screen name="List" component={ListScreenSimplified}/>
</Stack.Navigator>
</NavigationContainer>
);
}
export function AppSimple(): React.JSX.Element {
const [secondVisible, setSecondVisible] = React.useState(false);
return (
<View style={{ flex: 1, backgroundColor: 'lightsalmon' }}>
{!secondVisible && (
<View style={{ flex: 1, backgroundColor: 'lightblue' }} >
<Button title='Show second' onPress={() => setSecondVisible(true)} />
</View>
)}
{secondVisible && (
<ListScreenSimplified secondVisible={setSecondVisible} />
)}
</View>
);
}
const styles = StyleSheet.create({
container: {
flex: 1,
alignItems: 'center',
justifyContent: 'center',
},
nestedList: {
backgroundColor: '#FFA07A',
},
item: {
flexDirection: 'row',
alignItems: 'center',
padding: 10,
gap: 10,
},
text: {
fontSize: 24,
fontWeight: 'bold',
color: 'black',
},
image: {
width: 50,
height: 50,
},
});
```
</details>
Explanation (copied from [here](https://github.com/software-mansion/react-native-screens/pull/2495#issuecomment-2478915818)):
I've debugged this for a while now & I have good understanding of what's going on. This bug is caused by our usage of `startViewTransition` and its implications. We use it well, however React does not account for case that some view might be in transition. Error mechanism is as follows:
1. Let's have initially simple stack with two screens: "A, B". This is component rendered under "B":
```javascript
<View //<-- ContainerView (CV)
removeClippedSubviews={false}
style={{ flex: 1, backgroundColor: 'slateblue', overflow: 'hidden' }}>
<View removeClippedSubviews style={{ height: '100%' }}> // <--- IntermediateView (IV)
<View removeClippedSubviews={false} style={{ backgroundColor: 'pink', width: '100%', height: 50 }} /> // <--- ChildView (ChV)
</View>
</View>
```
2. We press the back button.
3. We're on Fabric, therefore subtree of B gets destroyed before B itself is unmounted -> in our commit hook we detect that the screen B will be unmounted & we mark every node under B as transitioning by calling `startViewTransition`.
4. React Mounting stage starts, view hierarchy is disassembled in bottom-up fashion (leafs first).
5. ReactViewGroupManager receives MountItem to detach ChV from IV.
6. A call to [`IV.removeView(ChV)` is made](https://github.com/facebook/react-native/blob/9c11d7ca68c5c62ab7bab9919161d8417e96b28b/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/view/ReactClippingViewManager.kt#L58-L73), which effectively removes ChV from `IV.children`, ***HOWEVER*** it does not clear `ChV.parent`, meaning that after the call, `ChV.parent == IV`. This happens, due to view being marked as in-transition by our call to `startViewTransition`. If the view is not marked as in-transition this parent-child relationship is removed.
7. IV has `removeClippedSubviews` enabled, therefore a [call to `IV.removeViewWithSubviewsClippingEnabled(ChV)` is made](https://github.com/facebook/react-native/blob/9c11d7ca68c5c62ab7bab9919161d8417e96b28b/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/view/ReactClippingViewManager.kt#L68). [This function](https://github.com/facebook/react-native/blob/9c11d7ca68c5c62ab7bab9919161d8417e96b28b/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/view/ReactViewGroup.java#L726-L744) does effectively two things:
1. if the ChV has parent (interpretation: it has not yet been detached from parent), we compute it's index in `IV.children` (Android.ViewGroup's state) and remove it from the array,
2. remove the ChV from `mAllChildren` array (this is state maintained by ReactViewGroup for purposes of implementing the "subview clipping" mechanism".
The crash happens in 7.1, because ChV has been removed from `IV.children` in step 6, but the parent-child relationship has not been broken up there. Under usual circumstances (this is my hypothesis now, yet unconfirmed) 7.1 does not execute, because `ChV.parent` is nulled in step no. 6.
### Rationale for `startViewTransition` usage
Transitions. On Fabric, when some subtree is unmounted, views in the subtree are unmounted in bottom-up order. This leads to uncomfortable situation, where our components (react-native-screens), who want to drive & manage transitions are notified that their children will be removed after the subtrees mounted in screen subviews are already disassembled. **If we start animation in this very moment we will have staggering effect of white flash** [(issue)](https://github.com/software-mansion/react-native-screens/issues/1685) (we animate just the screen with white background without it's children). This was not a problem on Paper, because the order of subtree disassembling was opposite - top-down. While we've managed to workaround this issue on Fabric using `MountingTransactionObserving` protocol on iOS and a commit hook on Android (we can inspect mutations in incoming transaction before it starts being applied) we still need to prevent view hierarchy from being disassembled in the middle of transition (on Paper this has also been less of an issue) - and this is where `startViewTransition` comes in. It allows us to draw views throughout transition after React Native removes them from HostTree model. On iOS we exchange subtree for its snapshot for transition time, however this approach isn't feasible on Android, because [snapshots do not capture shadows](https://stackoverflow.com/questions/42212600/android-screenshot-of-view-with-shadow).
### Possible solutions
[Android does not expose a method to verify whether a view is in transition](https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/view/ViewGroup.java#7162) (it has `package` visibility), therefore we need to retrieve this information with some workaround. I see two posibilities:
* first approach would be to override `startViewTransition` & `endViewTransition` in ReactViewGroup and keep the state on whether the view is transitioning there,
* second possible approach would be as follows: we can check for "transitioning" view by checking whether a view has parent but is not it's parent child (this **should** be reliable),
Having information on whether the view is in transition or not, we can prevent multiple removals of the same view in every call site (currently only in `removeViewAt` if `parent.removeClippingSubviews == true`).
Another option would be to do just as this PR does: having in mind this "transitioning" state we can pass a flag to `removeViewWithSubviewClippingEnabled` and prevent duplicated removal from parent if we already know that this has been requested.
I can also add override of this method:
```java
/*package*/ void removeViewWithSubviewClippingEnabled(View view) {
this.removeViewWithSubviewClippingEnabled(view, false);
}
```
to make this parameter optional.
## Changelog:
[ANDROID] [FIXED] - Handle removal of in-transition views.
Pull Request resolved: https://github.com/facebook/react-native/pull/47634
Test Plan: WIP WIP
Reviewed By: javache
Differential Revision: D66539065
Pulled By: tdn120
fbshipit-source-id: cf1add67000ebd1b5dfdb2048461a55deac10b16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48090
This alleviates a breaking change on `ReactModuleInfo` constructor.
While the ctor was deprecated, we realized that there are more than 250 usages in OSS.
We'll need to properly communicate this removal before we do it.
Changelog:
[Android] [Fixed] - Re-introduce the deprecated constructor on ReactModuleInfo
Reviewed By: cipolleschi
Differential Revision: D66755541
fbshipit-source-id: 3673d8f2af278d55491cea89f1594d368513e3d8
Summary:
Currently the class `ResponseUtil` is still in Java, I'm adding some unit tests so it is safer to migrate it to Kotlin.
## Changelog:
[INTERNAL] - `ResponseUtil` unit tests
Pull Request resolved: https://github.com/facebook/react-native/pull/48075
Test Plan:
```bash
yarn test-android
```
Reviewed By: cortinico
Differential Revision: D66727736
Pulled By: lunaleaps
fbshipit-source-id: 9c89c75905b4e0c9c4820a556245a07e135e0f17
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48076
JSC for Android does not implement `String.prototype.replaceAll`:
{F1971791988}
https://github.com/facebook/react-native/pull/47466 introduced a use of it into runtime code, breaking JSC compatibility.
This.. replaces it.. with `replace`. Since the argument is already a regex with a `g` modifier, `replaceAll` wasn't necessary anyway.
Changelog:
[ANDROID][FIXED] Fix JSC by avoiding use of unavailable `str.replaceAll()`
Reviewed By: javache
Differential Revision: D66712312
fbshipit-source-id: 534b6db6834a2fda46ae8457437de3caa24f4eb0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48053
Changelog: [Internal]
`getModuleInstanceFromClass:` is a delegate method intended to be implemented by the product layer to provide modules. if it is not implemented to return a module for a given key, `RCTTurboModuleManager` will simply call `new` on the TM class.
however, these two paths differentiate - for `getModuleInstanceFromClass:`, we will call `_attachBridgelessAPIsToModule:` which provides objects like surfacePresenter to the native module.
if we fallback to calling `new`, then this attachment does not happen, even if the app has already been migrated to bridgeless modules.
thus, the fix in the case is to lift the fallback into RCTInstance as well, and decorate the APIs onto the new fallback.
Reviewed By: cipolleschi
Differential Revision: D66675034
fbshipit-source-id: 1ab89a4006d05f744f5d42b5de786ccea4d4a55d
Summary:
X-link: https://github.com/facebook/yoga/pull/1762
Pull Request resolved: https://github.com/facebook/react-native/pull/48077
OCD strikes again. Grepped this time to make sure we didn't miss any cases for this specific param name
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D66715777
fbshipit-source-id: 3e881a15b3b2836a4a55b11d7ec621541b92a05d
Summary:
why: running `yarn test-e2e-local -t "RNTestProject" -p "Android" -h false -c $GITHUB_TOKEN` would actually build the app with Hermes even though it's specified as disabled.
This is because of the `if (argv.hermes == null)` condition whose body would not execute.
The condition was changed [recently](https://github.com/facebook/react-native/commit/f322dc7a84eb72370910f6933d0a4fa7780f49bc#diff-56f57bf0eac99b0fda1b2938aceb8d9b663db82c07cb405bd53a01c8689710ffR258).
Reason for `await` being used:
```
Error ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ scripts/release-testing/test-e2e-local.js:303:32
Cannot get argv.hermes because property hermes is missing in Promise [1]. [prop-missing]
scripts/release-testing/test-e2e-local.js
300│ 'reactNativeArchitectures=arm64-v8a',
301│ 'android/gradle.properties',
302│ );
303│ const hermesEnabled = (argv).hermes === true;
304│
305│ // Update gradle properties to set Hermes as false
306│ if (!hermesEnabled) {
flow-typed/npm/yargs_v17.x.x.js
[1] 80│ argv: Argv | Promise<Argv>;
```
## Changelog:
[INTERNAL] [FIXED] - fix `hermes` param handling in `test-e2e-local.js`
Pull Request resolved: https://github.com/facebook/react-native/pull/48068
Test Plan: tested locally
Reviewed By: cipolleschi
Differential Revision: D66704263
Pulled By: robhogan
fbshipit-source-id: f05f23b95e67bd20025e0b3448df0d284fcb62da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48071
Changelog: [Internal]
- Write fantom test for rn_rootThreshold given current implementation of IntersectionObserver
- Rename `rn_rootThreshold` to `rnRootThreshold`
- Rename `rn_intersectionRootRatio` to `rnRootIntersectionRatio`
- Rename `rootThresholds` on observer to `rnRootThresholds`
Reviewed By: rubennorte
Differential Revision: D66464509
fbshipit-source-id: 8ed66afa54bab99a28625ebe6f227d59d0bd7389
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48055
Address the test-case identified in D66557919, where Differentiator could emit updates for views referencing an incorrect parentTag.
The longer-term fix here is to avoid emitting any updates for nodes which are being reparented, but that requires bigger changes, including to the LayoutAnimation system. As a short-term patch, we're passing through an explicit `parentShadowViewForUpdate` which will be used as the current parent for update purposes.
{F1971278019}
Changelog: [Android][Fixed] Fix Fabric mutations sometimes triggering a `getViewState` crash when referencing an invalid parentTag.
Reviewed By: rubennorte
Differential Revision: D66654293
fbshipit-source-id: cd5b3e577ad1eede1b6dea834582ac6d750cbb81
Summary:
Make it clearer to the release crew to avoid using an outdated artifact
for testing a release.
{F1971030533}
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/48046
Test Plan:
```
yarn test-e2e-local -t "RNTester" -p "Android" -h true -c $GITHUB_TOKEN
```
Reviewed By: robhogan
Differential Revision: D66657082
Pulled By: blakef
fbshipit-source-id: 225128690c180bee7a3d28fdcc7f8c9885a37f0d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48066
Minor edits to this build spec to align with other packages in `ReactCommon/`.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D66700351
fbshipit-source-id: 47942c27d6154b78c165508447a3056f1354f5c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47930
This diff adds a list of props that will be used by the Android `ImagePrefetcher` to create an `ImageRequest`. This list is derived from all the props that `ReactImageView` uses to create its `ImageOptions` and `ImageRequest` objects.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D66453306
fbshipit-source-id: ca4f59784c81f2b94ed4b052f6fbe5e8c6b97a2a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48052
LLVM-15 has a warning `-Wunused-variable` which we treat as an error because it's so often diagnostic of a code issue. Unused variables can compromise readability or, worse, performance.
This diff either (a) removes an unused variable and, possibly, it's associated code or (b) qualifies the variable with `[[maybe_unused]]`.
#buildsonlynotests - Builds are sufficient
- If you approve of this diff, please use the "Accept & Ship" button :-)
Reviewed By: javache, wuyuoss
Differential Revision: D66143498
fbshipit-source-id: a461f115610258777bd1173f91cf4d4472e2fc5e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48057
FabricViewStateManager has been deprecated for a long time and it's unused, let's delete it
changelog: [Android][Breaking] Delete deprecated class FabricViewStateManager
Reviewed By: javache, cortinico
Differential Revision: D66403219
fbshipit-source-id: e8f893b6a240ca09c0e86821c0a15fa345ffd221
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48056
ComponentNameResolver is meant to be used only internaly, we reduce its visbility to internal
changelog: [Android][Breaking] Removed ComponentNameResolver from public API
Reviewed By: javache
Differential Revision: D66403218
fbshipit-source-id: bf08284400a6dc6446b771c894488ed3fb371e25
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47349
This is needed to be able to recurse into the literals and compare them.
I'm primarily unsure if there is a problem representing doubles/floats as numbers instead of strings though.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D65284058
fbshipit-source-id: b2de9ed5fb7f079a432c94aaea69027863879909
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47987
Store a tag value for whether the view is added or removed, to better track the state instead of checking view.getParent().
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D66383241
fbshipit-source-id: 16521eb4052e9473be058a00cfe29d7f198b7861
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47915
## Purpose of this noop-ing
If an fatal js error happens during js runtime init, the js thread continues executing and raises **yet another** fatal error.
This noop-ing was an **attempt** to prevent that second inactionable fatal from happening: That fatal is usually inactionable.
## Problems with this noop-ing
I don't think this is the right approach: There could be legitimate reasons to continue executing native -> js calls post first js fatal.
I don't think it does *much*: it doesn't noop native -> js calls executed on the runtime scheduler, which should be most of them.
## Changes
Instead of trying to prevent that fatal, just let it happen. Then, don't report the second fatal: D66193194 and D66392706.
## Safetly
The production impact is negligible: This codepath is executed only after early js errors. There shouldn't be any in production right now.
We've spent a lot of time making our javascript error handling pipeline's coverage compresive. So, after an early js fatal error happens, subsequent js fatals should get handled properly.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D66394278
fbshipit-source-id: ef342fc2eba9ae9f27b15a0f412fb69bd92aed43
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48020
Progress towards Performance panel display parity for User Timing events in Chrome DevTools.
- Support nullable `track` name in `ReactPerfLogger`, passing track name directly to `FuseboxTracer`.
- Update `FuseboxTracer` to register "Main" process and send V8-aligned `blink.user_timing`-categorised tracing events.
The previous track naming strategy continues to be used under Perfetto.
Changelog: [Internal]
**Better, but not perfect yet**
For now, this is probably the upper limit of how aligned we can be with Chrome on web, since our forked DevTools frontend is 6mo+ behind `main`. Notably, it does not include equivalent custom track handling today: https://github.com/ChromeDevTools/devtools-frontend/commit/4b4435feef14c5c0ac71d932940c6ea7613f8afe
{F1969750671}
> Importing an exact trace from Chrome into RNDT is unable to sub-group the "Timings" track.
Reviewed By: rubennorte
Differential Revision: D66579308
fbshipit-source-id: fa57151d2be477eaa15f62e5c19ee09b1a0ef43a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48048
Changelog: [Internal]
Some messages may contains multi line content, ie snapshot comparison, multiline strings comparison.
Fixing this by checking first code pointer in the stack and slicing from there.
Reviewed By: christophpurrer, rubennorte
Differential Revision: D66660107
fbshipit-source-id: 57cea02cf6aae3c24f351504c2e077b5a2de0761
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48004
Follows https://github.com/facebook/react-native/pull/47962 and depends on https://github.com/facebookexperimental/rn-chrome-devtools-frontend/pull/139.
Updates the modern debugger server to no longer respond to `FuseboxClient` messages — namely `FuseboxClient.setClientMetadata`. This method is replaced by `ReactNativeApplication.enable` for identifying the React Native DevTools frontend.
Changelog:
[General][Breaking] - The `FuseboxClient.setClientMetadata` CDP method is removed. Instead, use `ReactNativeApplication.enable`.
Reviewed By: rubennorte
Differential Revision: D66575324
fbshipit-source-id: f2b4cbacd857931832d89305510f5aaf51df483a
Summary:
Updates Fresco from 3.4.0 to 3.5.0. Picks up a few new features, including experimental support for XML-based drawable resource types
Changelog:
[Android][Changed] - Update Fresco to 3.5.0
Reviewed By: cortinico
Differential Revision: D66553841
fbshipit-source-id: d0e630c73ba73ea9bbf96f7d630471c5383145f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48039
This class was removed in D66127067 but was marked as DeprecatedInNewArchitecture and not Deprecated, which limited the signal we gave to developers to move away from this.
Restore for now to e
Changelog: [Android][Fixed] Reverted removal of TurboReactPackage
Reviewed By: rshest
Differential Revision: D66648209
fbshipit-source-id: 165f9390b4874e69353612b929d87b0c495588af
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48022
Changelog: [internal]
This adds support for Fantom options in tests to configure different aspects of the test execution.
For now, it only supports specifying the mode (dev or opt) so we can try things without having to change the runner (watch mode still works if you change mode :D).
Fantom options are specified as pragmas in the docblock of the test. E.g.:
```
/**
* flow strict-local
* format
* fantom_mode opt
*/
```
We expect this is mostly going to be used for one-time tests and that regular tests won't specify the mode (they'll just run in dev mode).
Maybe we can evolve this in the future to specify that you want a test to be executed in both modes, to ensure the behavior is consistent in dev/prod.
Reviewed By: rshest
Differential Revision: D66597626
fbshipit-source-id: b12325fc2235740cc2a3e0283d6a556091c1794c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48015
Changelog: [internal]
Right now, when we run individual Fantom tests, we compile Hermes and the RN Tester CLI as part of the test, which causes the first test to run to be very slow and the remaining tests in the same run to be very fast.
This is misleading because it makes it look like the test itself is slow, when it's actually paying a price for everyone.
Fortunately, Jest has an option to do a global setup before any tests in the project run (and it doesn't run if none of the tests in the project run, in multi-project setups), so we can use it to do the necessary warmup so it doesn't end up being attributed to individual tests.
Reviewed By: javache
Differential Revision: D66595406
fbshipit-source-id: 496aa2b248da661f7504c8445fed1edad0301803
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48014
Changelog: [internal]
Just a small refactor in preparation for a following change that will add more usages for these utilities. It also cleans up the runner file which is good too.
Reviewed By: javache
Differential Revision: D66595405
fbshipit-source-id: e734d76006ce937fadd1cb673035db85a3e838dd
Summary:
building RN tester with 0.77 rc-0 doesn't work now because of `java.io.IOException: No such file or directory` on line 48.
`buildDirectory` is a Gradle property representing a file
https://github.com/facebook/react-native/pull/47552 removes this file altogether so feel free to close if that one is the "right one"
## Changelog:
[ANDROID] [FIXED] - fix IOException in `BuildCodegenCLITask`
Pull Request resolved: https://github.com/facebook/react-native/pull/48008
Test Plan: After this change, building RN tester works.
Reviewed By: cortinico
Differential Revision: D66650038
Pulled By: robhogan
fbshipit-source-id: 11cd83493fa118c6b79d11c9113228dd3971a803
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48041
Changelog: [internal]
This adds a Fantom test for the LongTask API, testing it using public APIs :D
Reviewed By: javache
Differential Revision: D66601861
fbshipit-source-id: f3531e8b58ffa044dcb5cec2f462ae6a31c27790
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48040
Changelog: [internal]
We need more expectations for a new test we're writing. This just adds:
* `expect(received).toBeLessThanOrEqual(expected)`
* `expect(received).toBeGreaterThanOrEqual(expected)`
Reviewed By: sammy-SC
Differential Revision: D66601921
fbshipit-source-id: 0a73f7757117ed790b95796b259244c8259136b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48025
Changelog: [internal]
This migrates the existing tests we have for the current public API for host component refs to Fantom.
After this, the only remaining test to migrate before we can clean up the legacy mocks for Fabric, etc. is the one for IntersectionObserer.
Reviewed By: sammy-SC
Differential Revision: D66599070
fbshipit-source-id: 67da1cd3b360ac79aed6fe6ad2a8bd5273754174
Summary:
There are currently 2 warnings firing for every PR (e.g. look here https://github.com/facebook/react-native/pull/48013/files).
Those are annoying so I'm fixing them here.
## Changelog:
[INTERNAL] - Fix eslint warnings in react-native
Pull Request resolved: https://github.com/facebook/react-native/pull/48016
Test Plan: CI
Reviewed By: NickGerleman
Differential Revision: D66595842
Pulled By: cortinico
fbshipit-source-id: 0fd39629a97dbbe5d75a78c8eaa50241faf6bf1e
Summary:
A NPE can occur when a user touches the screen before the `SurfaceMountingManager` is initialized. Below is an example of the error log from our production service. This issue can also be reproduced using RNTester. To prevent invalid touch events during init time of rn app from causing an NPE, add a null check for SurfaceMountingManager before calling mark/sweepActiveTouchForTag.
```
Fatal Exception: java.lang.NullPointerException: Attempt to invoke virtual method 'void com.facebook.react.fabric.mounting.SurfaceMountingManager.markActiveTouchForTag(int)' on a null object reference
at com.facebook.react.fabric.FabricUIManager.markActiveTouchForTag(FabricUIManager.java)
at com.facebook.react.uimanager.JSTouchDispatcher.markActiveTouchForTag(JSTouchDispatcher.java)
at com.facebook.react.uimanager.JSTouchDispatcher.handleTouchEvent(JSTouchDispatcher.java)
at com.facebook.react.runtime.ReactSurfaceView.dispatchJSTouchEvent(ReactSurfaceView.java)
at com.facebook.react.ReactRootView.onInterceptTouchEvent(ReactRootView.java)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2870)
at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3352)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2963)
at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3352)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2963)
at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3352)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2963)
at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3352)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2963)
at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3352)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2963)
at com.android.internal.policy.DecorView.superDispatchTouchEvent(DecorView.java:794)
at com.android.internal.policy.PhoneWindow.superDispatchTouchEvent(PhoneWindow.java:1967)
at android.app.Activity.dispatchTouchEvent(Activity.java:4571)
at com.rainist.banksalad2.feature.common.BaseActivity.dispatchTouchEvent(BaseActivity.java)
at androidx.appcompat.view.WindowCallbackWrapper.dispatchTouchEvent(WindowCallbackWrapper.java:70)
at com.android.internal.policy.DecorView.dispatchTouchEvent(DecorView.java:752)
at android.view.View.dispatchPointerEvent(View.java:16498)
at android.view.ViewRootImpl$ViewPostImeInputStage.processPointerEvent(ViewRootImpl.java:8676)
at android.view.ViewRootImpl$ViewPostImeInputStage.onProcess(ViewRootImpl.java:8423)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:7752)
at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:7809)
at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:7775)
at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:7978)
at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:7783)
at android.view.ViewRootImpl$AsyncInputStage.apply(ViewRootImpl.java:8035)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:7756)
at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:7809)
at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:7775)
at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:7783)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:7756)
at android.view.ViewRootImpl.deliverInputEvent(ViewRootImpl.java:11343)
at android.view.ViewRootImpl.doProcessInputEvents(ViewRootImpl.java:11212)
at android.view.ViewRootImpl.enqueueInputEvent(ViewRootImpl.java:11168)
at android.view.ViewRootImpl$WindowInputEventReceiver.onInputEvent(ViewRootImpl.java:11477)
at android.view.InputEventReceiver.dispatchInputEvent(InputEventReceiver.java:337)
at android.os.MessageQueue.nativePollOnce(MessageQueue.java)
at android.os.MessageQueue.next(MessageQueue.java:335)
at android.os.Looper.loopOnce(Looper.java:187)
at android.os.Looper.loop(Looper.java:319)
at android.app.ActivityThread.main(ActivityThread.java:9063)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:588)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1103)
```
https://github.com/user-attachments/assets/e9c6ff84-c94d-4392-9042-8e635197202e
## Changelog:
[Android] [Fixed] - Avoid NPE when touch event is triggered before SurfaceManager is initiated
Pull Request resolved: https://github.com/facebook/react-native/pull/48007
Test Plan:
I checked the crashed being fixed on RNTester.
https://github.com/user-attachments/assets/71f7e359-707a-494c-ae34-fef8d432e612
Reviewed By: cortinico
Differential Revision: D66594576
Pulled By: javache
fbshipit-source-id: b1559d94866bdb021e0374f1953684849603033c
Summary:
fix typo in `inherithed`
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [CHANGED] - fix typo in utils.rb
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [CHANGED] - fix typo in utils.rb
Pull Request resolved: https://github.com/facebook/react-native/pull/48013
Test Plan: I did not spot any changes when switching it but in some specific build settings it could destroy some behaviors probably.
Reviewed By: cipolleschi
Differential Revision: D66595786
Pulled By: cortinico
fbshipit-source-id: d1607fd1127352533fb2977bdfcafec1edd1aef7
Summary:
https://github.com/facebook/react-native/pull/46385 introduced use of `Object.hasOwn` as an incidental detail of some `Animated` performance improvements.
Unfortunately, `Object.hasOwn` is not present in the version of JSC shipped with Android, nor the built in iOS JSC until iOS 15.4, which is greater than React Native's minimum version (13.4).
Instead:
- Use `obj.hasOwnProperty(prop)` for known objects that have the `Object` prototype.
- Otherwise, use `Object.hasOwn` where it is defined.
- Lastly, fall back to `Object.prototype.hasOwnProperty.call(obj, prop)`, which is compatible with passed `null`-prototype objects.
Fixes https://github.com/facebook/react-native/issues/47963
Intend to pick for RN 0.77.
## Changelog:
[GENERAL][FIXED] Replace Object.hasOwn usages to fix Animated on JSC
Pull Request resolved: https://github.com/facebook/react-native/pull/48035
Test Plan:
- Run `rn-tester` on Android with Hermes disabled.
- Verify the FlatList->Basic example redboxes before this change, and works after it.
Reviewed By: yungsters
Differential Revision: D66638379
Pulled By: robhogan
fbshipit-source-id: 51ac525851b41adea3bf3cc41349225138e1f2fe
Summary:
This Pull Request fixes a regression introduced in https://github.com/facebook/react-native/commit/7c7e9e6571c1f702213e9ffbb40921cd5a1a786b, which adds a `filename*` attribute to the `content-disposition` of a FormData part. However, as the [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition#directives) states, there is no `filename*` attribute for the `content-disposition` header in case of a form data.
The `filename*` attribute would break the parsing of form data in the request, such as in frameworks like `Next.js` which uses the web implementation of [`Request`](https://developer.mozilla.org/en-US/docs/Web/API/Request).
Fixes https://github.com/facebook/react-native/issues/44737
## 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] - Remove non compliant `filename*` attribute in a FormData `content-disposition` header
Pull Request resolved: https://github.com/facebook/react-native/pull/46543
Test Plan:
- Clone the `react-native` repo
- Create a simple JS file that will act as a node server and execute it
```javascript
const http = require('http');
const server = http.createServer(async function (r, res) {
const req = new Request(new URL(r.url, 'http://localhost:3000'), {
headers: r.headers,
method: r.method,
body: r,
duplex: 'half',
});
const fileData = await req.formData();
console.log(fileData);
res.writeHead(200);
res.end();
});
server.listen(3000);
```
- Go to `packages/rn-tester`
- Add a `useEffect` in `js/RNTesterAppShared.js`
```javascript
React.useEffect(() => {
const formData = new FormData();
formData.append('file', {
uri: 'https://www.gravatar.com/avatar',
name: '测试photo/1.jpg',
type: 'image/jpeg',
});
fetch('http://localhost:3000', {
method: 'POST',
body: formData,
}).then(res => console.log(res.ok));
});
```
- Run the app on iOS or Android
- The node server should output the file added to the FormData with an encoded name
Reviewed By: robhogan
Differential Revision: D66643317
Pulled By: yungsters
fbshipit-source-id: 0d531528005025bff303505363671e854c0a2b63
Summary:
This PR migrates `ReactSwitchManager` to Kotlin
Also it moves it's shadow node to a separate file (`ReactSwitchShadowNode.kt`)
## Changelog:
[ANDROID] [CHANGED] - Migrate `ReactSwitchManager` to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/48003
Test Plan: Make sure that `Switch` example in `RNTester` works correctly
Reviewed By: cortinico
Differential Revision: D66594606
Pulled By: javache
fbshipit-source-id: 774641c4cf57d6d5f770df1fed4fcafef2af7ceb
Summary:
solve the exception on android when `Appearance.setColorScheme` and activity recreate()
Fixes https://github.com/facebook/react-native/issues/47954
## Changelog:
[Android][Fixed] setColorScheme should be called on the UI thread
Pull Request resolved: https://github.com/facebook/react-native/pull/47955
Reviewed By: cortinico
Differential Revision: D66573373
Pulled By: javache
fbshipit-source-id: 97808e163e1c53bb94f4be7269d9cb9e212f2e95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47962
Updates `HostAgent` to respond equivalently if either `FuseboxClient.setClientMetadata` (outgoing) or `ReactNativeApplication.enable` (incoming) are sent by the CDP frontend.
This is a partial migration, to be followed by removing the `FuseboxClient.setClientMetadata` method later.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D66501027
fbshipit-source-id: 1ff669c24667f51d240311e75f95747efe577e2d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48006
Changelog: [internal]
This implements symbolication of error stack traces in Fantom tests. We just needed to ask Metro to generate source maps and use the `source-map` package to process the stack traces that we get back from the runtime.
Reviewed By: sammy-SC
Differential Revision: D66577818
fbshipit-source-id: 672c66c246ad8646646d5ed31cabca39eb4f7aca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48002
Demonstrates the issue identified in https://github.com/facebook/react-native/issues/47960 and a crash we've been seeing internally around `getViewState` referencing a view that does not exist.
When reparenting unflattened nodes, Differentiator may emit an `update` with a `parentShadowView` that does not exist on the native side yet, thereby crashing Android.
Landing the test-case first (with some test cleanup), so the diff for the actual fix is clearer.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D66557919
fbshipit-source-id: 5428c32e5f0200a8e98568cabeedb0c61aafbe23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47994
Changelog: [internal]
This adds a few hacks to improve errors messages in Fantom tests. Before, we were only logging the error message. After this, we log the message and the full (unsymbolicated for now) stack, including a pretty print of the exact location of the error.
For errors thrown from `expect` functions, the stack trace is modified to remove the "infra" lines from the stack.
The next step is symbolicating the errors using source maps generated by metro.
Reviewed By: javache
Differential Revision: D66555063
fbshipit-source-id: 17bd23cb30429a17e99f13f934c45e001120bbb3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47968
Updates the Inspector Proxy to report + log when a profiling build target (experimental) is registered. This notifies the developer that debugging is available for these app(s), which will not otherwise fetch development bundles from Metro.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D66501771
fbshipit-source-id: e06dee279158094ad5c70bf8e6a90e7c983de48a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47983
Changelog: [internal]
This mitigates some performance regressions caused by the migration from `ReactFabricHostComponent` to `ReactNativeElement` (enabling the DOM APIs).
Those regressions were caused by 2 main things:
1. By the use of a class hierarchy and having to call `super()`, which we transpile to a very complex code to ensure it's spec compliant.
2. By the use of private fields (`#viewConfig`) which are significantly slower than a regular field with the `_` naming convention (`_viewConfig`) processed by our custom transform.
This mitigates those problems by using the `_` convention and refactoring the class hierarchy to avoid the use of `super()` while preserving the Flow typing and most of the existing implementation.
Reviewed By: javache, andrewdacenko
Differential Revision: D66540756
fbshipit-source-id: db6aa18c12194b18e3a69e9979621d0feae6186a
Summary:
Removed `node-fetch` in favour of node builtin fetch to get rid of the deprecated `punycode` warning when using Node 22.
`react-native/community-cli-plugin` already requires Node >= 18 where it was made available by default (without `--experimental-fetch` flag).
This change is similar to the one made in https://github.com/facebook/react-native/pull/45227
## Changelog:
[GENERAL] [CHANGED] - Drop node-fetch in favor of Node's built-in fetch from undici in `react-native/community-cli-plugin`
Pull Request resolved: https://github.com/facebook/react-native/pull/47397
Test Plan: tests pass
Reviewed By: blakef
Differential Revision: D66512595
Pulled By: NickGerleman
fbshipit-source-id: c4e01baf388f9fae8cea7b4bfe25034bff28b461
Summary:
X-link: https://github.com/facebook/yoga/pull/1755
Pull Request resolved: https://github.com/facebook/react-native/pull/47975
I've been working with callsites here and its annoying if you switch these that you need to move these params around too. Let's just make them the same order
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D66519836
fbshipit-source-id: 2e98e671270a053c6e62372e2003f1ca67774ec9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47965
Changelog: [General] [Changed] - fix item disappearing with scroll in VirtualizedList
It was caused because the function `computeWindowedRenderLimits` collapsed the current window size to just 1 element. So, users start scroll current window increase from {left:0, right:5 } -> {left:0, right:6 } and after some edge cases the window collapsed to `{left:6, right:6 }` which cause to remove all elements and recreate them later. As a result users have a lot of lags and blank pages.
The diff fixes the collapsing window size to 1 element. Also fix other decreasing `left` position even if windowSize more than current amount of elements.
Reviewed By: NickGerleman
Differential Revision: D66334188
fbshipit-source-id: 2162d00d03d64ab6325c0492d87449051e68a4e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47723
Identity of `ImageRequest` is based on `ImageSource` and a subset of `ImageProps`. If any of those change, the request must be recreated and resubmitted.
Currently, the relevant subset of ImageProps is represented by a single `blurRadius` prop. This list will grow in the future. In order to simplify adding new props to the image request, we introduce the `ImageRequestParams` type that will wrap all the relevant props.
The alternative approach to pass `ImageProps` directly to `ImageManager` is worse because it would introduce dependency cycle between `ImageManager` and the `Image` component, and also it would require to store the props in State, which is bad.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D66172570
fbshipit-source-id: d6853bf8dcecd6e76ac90ccb2079d102a3015988
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47721
This diff splits Cxx ImageManger into Cxx and Android variants. They both are currently no-op, but the Android one will be used for image prefetching, just as `RCTImageManager.mm` for iOS.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D65753319
fbshipit-source-id: 774ff09b6b397facee7f645706dd97ba6d1177d7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47950
`addInArray` may reallocate `mAllChildren` so it's not correct to store this reference.
Changelog: [Internal]
Reviewed By: tdn120
Differential Revision: D66474532
fbshipit-source-id: 90ce2fcbf8ff236501ed47b2acc413e54ef8b82a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47913
CompositeBackgroundDrawable has some logic for inserting the layers that are not set through the constructor. This unit test makes sure they are being properly ordered.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D66381515
fbshipit-source-id: 514979a4a97fa159c1d1c3c923afe969eafc21c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47934
This property needs to be made public for later diffs in this stack.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D66338915
fbshipit-source-id: f4896f8404e3d7eed7255e0f923ab5eec9a1291e
Summary:
The React Native `<ScrollView>` has a peculiar `centerContent` prop. It solves a common need — keeping the image "centered" while it's not fully zoomed in (but then allowing full panning after it's sufficiently zoomed in).
This prop sort of works but it has a few wonky behaviors:
- If you start tapping immediately after pinch (and don't stop), the taps will not be recognized until a second after you stop tapping. I suspect this is because the existing `centerContent` implementation hijacks the `contentOffset` setter, but the calling UIKit code _does not know_ it's being hijacked, and so the calling UIKit code _thinks_ it needs to do a momentum animation. This (invisible) momentum animation causes the scroll view to keep eating the tap touches.
- While you're zooming in, once you cross the threshold where `contentOffset` hijacking stops adjusting values, there will be a sudden visual jump during the pinch. This is because the "real" `contentOffset` tracks the accumulated translation from the pinch gesture, and once it gets taken into account with no "correction", the new offset snaps into place.
- While not sufficiently pinched in, the vertical axis is completely rigid. It does not have the natural rubber banding.
The solution to all of these issues is described [here](https://petersteinberger.com/blog/2013/how-to-center-uiscrollview/). Instead of hijacking `contentOffset`, it is more reliable to track zooming, child view, and frame changes, and adjust `contentInsets` instead. This solves all three issues:
- UIKit isn't confused by the content offset changing from under it so it doesn't mistrigger a faux momentum animation.
- There is no sudden jump because it's the insets that are being adjusted.
- Rubber banding just works.
## 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] - Fixed centerContent losing taps and causing jitter
Pull Request resolved: https://github.com/facebook/react-native/pull/47591
Test Plan:
I'm extracting this from [a patch we're applying to Bluesky](https://github.com/bluesky-social/social-app/blob/2ef697fe3d7dec198544ed6834553f33b95790b3/patches/react-native%2B0.74.1.patch). I'll be honest — I have not tested this in isolation, and it likely requires some testing to get merged in. I do not, unfortuntately, have the capacity to do it myself so this is more of a "throw over the wall" kind of patch. Maybe it will be helpful to somebody else.
I've tested these in our real open source app (https://github.com/bluesky-social/social-app/pull/6298). You can reproduce it in any of the lightboxes in the feed or the profile.
### Before the fix
Observe the failing tap gestures, sudden jump while pinching, lack of rubber banding.
https://github.com/user-attachments/assets/c9883201-c9f0-4782-9b80-8e0a9f77c47c
### After the fix
Observe the natural iOS behavior.
https://github.com/user-attachments/assets/c025e1df-6963-40ba-9e28-d48bfa5e631d
Unfortunately I do not have the capacity to verify this fix in other scenarios outside of our app.
Reviewed By: sammy-SC
Differential Revision: D66093472
Pulled By: javache
fbshipit-source-id: 064f0415b8093ff55cb51bdebab2a46ee97f8fa9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47292
If we don't add the prop to the iterator style parser then since fabric is not parsing the prop we are not properly creating the stacking context for when a prop has a mix-blend-mode set
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D65166886
fbshipit-source-id: 7b5bce82e81bf0c566ccd4620852ae877ccbf376
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47293
We missed fabric check for the mix-blend-mode conditional on `drawChildren` adding it now
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D65167244
fbshipit-source-id: 1af5dc1979fb79c453ba0f27c0385a94dc539a55
Summary:
While trying to write some test cases for `ReactOkHttpNetworkFetcher`, I found that the cache control headers are not being sent over the network request correctly. These cache control headers are always being overwritten by the rest of the headers hence all the logic to set this custom cache control doesn't seem to be working as expected.
As per the [Request headers](https://github.com/square/okhttp/blob/2832a9e532ecbc6f1f84b3a07e8e64b75372789c/okhttp/src/main/kotlin/okhttp3/Request.kt#L256) docs, this seems to be the explanation:
> /** Removes all headers on this builder and adds [headers]. */
open fun headers(headers: Headers) = commonHeaders(headers)
With the new approach by setting the headers first, we ensure that the cache control headers don't get overwritten but they would get added on top of the passed headers.
Notice that currently it seems to be overwriting these headers even if there are not headers passed from the Image component (AKA null/empty).
See my reproduction example in the test plan.
## Changelog:
[ANDROID] [FIXED] - ReactOkHttpNetworkFetcher – cache control headers getting overwritten by the rest of the headers
Pull Request resolved: https://github.com/facebook/react-native/pull/47922
Test Plan:
By creating the following component, we log the request headers using `FLog` with the previous and the new approach. See the difference on the outputs below:
Component:
```tsx
<Image
source={{
uri: 'https://www.facebook.com/assets/fb_lite_messaging/E2EE-settings@3x.png?cacheBust=reload',
cache: 'reload',
headers: {
'some-header': 'some-header-value',
},
}}
/>
```
Setting the `headers` last (current approach):
```kt
val request =
Request.Builder()
.cacheControl(cacheControlBuilder.build())
.url(uri.toString())
.headers(headers)
.get()
.build()
FLog.w("RequestHeaders", request.headers.toString())
```
Output (notice that the Cache-Control header is not present):
```bash
RequestHeaders com.facebook.react.uiapp W some-header: some-header-value
```
<img width="561" alt="image" src="https://github.com/user-attachments/assets/797cd90a-2064-4772-99cc-5f9d39d73361">
---
New approach by setting the `headers` first:
```kt
val request =
Request.Builder()
.headers(headers)
.cacheControl(cacheControlBuilder.build())
.url(uri.toString())
.get()
.build()
FLog.w("RequestHeaders", request.headers.toString())
```
Output (Cache-Control is present now along with the passed headers):
```bash
RequestHeaders com.facebook.react.uiapp W some-header: some-header-value
Cache-Control: no-cache, no-store
```
<img width="556" alt="image" src="https://github.com/user-attachments/assets/1b9f7865-926e-496b-ad3a-36e19ae92188">
Reviewed By: rshest
Differential Revision: D66446820
Pulled By: javache
fbshipit-source-id: 2640ea4b0e678a7aa919b919b0b44bedc0da0af4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47895
X-link: https://github.com/facebook/yoga/pull/1750
These APIs were only added so that we could do TDD as we work on intrinsic sizing functionality. As of right now they do nothing. We are aiming on publishing a new version of Yoga soon so for the time being we are going to back these out so as not to confuse anyone with this new functionality. Ideally we get to a point where we have some temporary experimental header to stage these in but this is a bit time sensitive so just backing out for now
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D66332307
fbshipit-source-id: 1d596964e0c893091c541988506e8b80fa6d1957
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47896
X-link: https://github.com/facebook/yoga/pull/1752
These APIs were only added so that we could do TDD as we work on intrinsic sizing functionality. As of right now they do nothing. We are aiming on publishing a new version of Yoga soon so for the time being we are going to back these out so as not to confuse anyone with this new functionality. Ideally we get to a point where we have some temporary experimental header to stage these in but this is a bit time sensitive so just backing out for now
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D66332309
fbshipit-source-id: 793f77dad021fa5e57b52c36ae954307636bcbf0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47336
Before mix-blend-mode would not blend with the background color due to it not being a ViewGroup. This adds the mix-blend-mode logic to ReactRootView so blending works
Changelog:
[Android][Fixed] - Enable mix-blend-mode on ReactRootView so blending works with app background
Reviewed By: NickGerleman
Differential Revision: D65156543
fbshipit-source-id: b3628b667573d0b56c74214e40d21c656fda495a
Summary:
I was just going through the README file, and I felt that the word "repo" seems a bit informal. Thus I made the correction and made it "repository".
## Changelog:
[General] [Changed] - Fixed a typo in the README file.
Pull Request resolved: https://github.com/facebook/react-native/pull/47918
Test Plan: No specific Test Plan for these changes, as it is just a typo fix in README.md
Reviewed By: fkgozali
Differential Revision: D66414686
Pulled By: arushikesarwani94
fbshipit-source-id: 578530d2dcdf046a90bf5a5bc32ba68e8f496c81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47914
This was a bug in the original diff: D66193194.
If a fatal js error happens, we should only drop subsequent **fatal** js errors. It's fine to report soft errors.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D66392706
fbshipit-source-id: c51bae186184c54faa9bce065b81b442607e751b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47747
Deprecate NotThreadSafeViewHierarchyUpdateDebugListener as won't be available in new arch and will be deleted
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D66216730
fbshipit-source-id: 88f3346ad38b80a710d9df4ba08b63887048c8cd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47746
Remove DeprecatedInNewArchitecture annotation from ReactPropGroup since this annotation is not deprecated in new arch
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D66216727
fbshipit-source-id: 252bae58557b51c9fbfb1deab4edc7c50511a005
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47745
Remove DeprecatedInNewArchitecture for ReactPropHolder annotation
ReactProp is still used in new arch, we might remove this annotation in the future but it will be independent of new arch
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D66216729
fbshipit-source-id: 3f64858ab4fa60b09978b18b17200ae488e229ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47910
It seems there could be a race where a commit is being processed on the JS thread after the surface has been removed from the mounting manager. Since we don't actually need to retrieve the default paddings in these cases, there's no reason we need an enforced read of the SurfaceMountingManager.
## Changelog
[Internal]
Reviewed By: javache
Differential Revision: D66369969
fbshipit-source-id: 44ccdc9beafdbd0ac47457fb01c4114348c1a316
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47891
Various C++ utilities for handling callbacks and promises rely on the static LongLivedObjectCollection. Even if a host platform injects it's TurboModuleBinding with a custom LongLivedObjectCollection, there's no guarantee that the platform is not also using C++ TurboModules that use the static LongLivedObjectCollection. Clearing both collections solves issues for TurboModuleBindings with custom LongLivedObjectCollections that also have cross platform C++ TurboModules that use the static collection.
## Changelog
[Internal]
Reviewed By: javache
Differential Revision: D66324044
fbshipit-source-id: a5a973087c35fc00240e40ba757d49125473daf4
Summary:
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/47907
EnableDevSupport is set to false on lifecyle events like onPause and onHostDestroy, and set to true on events like onResume and onCreate.
In apps like AMA and Twilight, there is first a loginActivity, which then calls the mainActivity. After mainActivity is created, loginActivity is destroyed. This causes enableDevSupport to always be false because onDestroy for loginActivity is triggered after onCreate for mainActivity.
Reviewed By: RSNara, alanleedev
Differential Revision: D66124018
fbshipit-source-id: e40a5b24cf73000b0bfeaa1d8e3902718b281410
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47897
Changelog: [Internal]
In some situations, we want to provide multiple `CxxReactModules` from a single lambda. Currently, this is painful -- this change makes it less so.
Reviewed By: tdn120
Differential Revision: D66337573
fbshipit-source-id: ed57ad6ca2b98d4787aca7da3714c05c3d03b649
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47908
Changelog: [General][Added] - Add support for `rn_rootThreshold` in Intersection Observer
`rn_rootThreshold` is a custom IntersectionObserver option and not part of the IntersectionObserver spec. We are adding it because it covers a specific use-case for measuring viewability that is robust for `target`s that are larger than the viewport or specified `root`.
The threshold ratio is of the intersection area (of `root` and `target`) to the total area of the `root`.
{F1960832959}
Source - EX314979
`rn_rootThreshold` is an optional threshold and can be combined with the `thresholds` option. An intersection will fire if any specified thresholds is met.
Note: If you use specify a `rn_rootThreshold`, the default `threshold` is no longer applied
The main use case of `rn_rootThreshold` is being able to specify a level of viewability independent of `target` size. For example, a `target` that is larger than the `root` (commonly the viewport) will not trigger the IntersectionObserver for a `threshold` of `1`. Setting `rn_rootThreshold` of `1`, will trigger once the item takes full size of the `root`.';
Reviewed By: yungsters
Differential Revision: D66031119
fbshipit-source-id: 7bdc871dc5b4e6c0edc7d6e17a0a0cfd51c4fe81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47878
Make it clearer what we're checking, and provide a single point of code where we could potentially improve the logic.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D66302526
fbshipit-source-id: a0e6d1004aef25897e9633fe930915ba585c1cb5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47674
Small changes that can be done in Java and make a Kotlin conversion more seamless.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D66033963
fbshipit-source-id: 666302f132b98019f1013a335a2c59c7a4f31836
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47880
The previous diffs in this stack have aimed to make URL rewriting by inspector-proxy robust to any configuration of device->server, debugger->server and server->server connections.
Though rewriting was originally introduced to support Android emulator networking, we can now expand it to cover other use cases, like the device reaching the server over an internet address not reachable from the dev machine, or the debugger routing to the server through a tunnel on a different port, without needing CORS workarounds.
Changelog
[General][Fixed] dev-middleware: Rewrite URLs in the inspector proxy to cover all configurations, not just Android emulators.
Reviewed By: huntie
Differential Revision: D66247355
fbshipit-source-id: e9201ebc1f7f5fe2119c71cd4d7b4ca895645404
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47681
These were deprecated back in D49262824, so should be safe to remove now.
Changelog: [Android][Removed] Removed hasConstants constructor from ReactModuleInfo
Reviewed By: mdvacca
Differential Revision: D66127070
fbshipit-source-id: 3bd441c96597598470f16c7770c4dfa4ada563a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47680
This was deprecated in D50128456 so should be safe to remove now.
Changelog: [Android][Removed] Removed TurboReactPackage, which was replaced by BaseReactPackage
Reviewed By: mdvacca
Differential Revision: D66127067
fbshipit-source-id: a4090ab439cf99dc693622b8da2c0cffa247ad24
Summary:
Fixes the high contrast color when not specified. Previously, if we didn't specify highContrastLight or highContrastDark, it would create a UIColor with an alpha of 0, which is not what we expected. We should fall back to the dark or light color instead.
## Changelog:
[IOS] [FIXED] - Fabric: Fixes high contrast color when not specified
Pull Request resolved: https://github.com/facebook/react-native/pull/47418
Test Plan:
1. Enable color contrast in iPhone's settings.
2. Open PlatformColor example in RNTester. See dynamic colors
3. color shows correctly

Before:

Reviewed By: javache
Differential Revision: D66303078
Pulled By: cipolleschi
fbshipit-source-id: 63a0d2bc94eea438d4f69643d09825b74575188b
Summary:
Attempting to use the various bridging template and generated C++ Specs for native modules in a project compiling with MSVC does not build.
For the fromJs I had to add `std::move` - otherwise it could not cast.
The supportsFromJs and supportsToJs are changed to address an IntelliSense issue where the template specialization cannot have default members.
## Changelog:
[GENERAL] [FIXED] - Fix C++ bridging template compatibility with MSVC
Pull Request resolved: https://github.com/facebook/react-native/pull/47882
Test Plan: It continues to build on Android/iOS builds. And it also builds with MSVC for react-native-windows and other out of tree platforms that use MSVC.
Reviewed By: cipolleschi
Differential Revision: D66360833
Pulled By: javache
fbshipit-source-id: bf97db1cd247a383eb86cac31c601e8ab3400fd2
Summary:
E2E tests for Android RNTester in GHA are flaky and they prevent CI to be green on main.
Given that the Branch cut is happening on Monday and that I'll be away for a week, it's better to disable them.
I'm planning to work a bit on those today and more once I'm back
## Changelog:
[Internal] - Temporarily disable E2E tests for Android
Pull Request resolved: https://github.com/facebook/react-native/pull/47903
Test Plan: GHA
Reviewed By: javache
Differential Revision: D66359177
Pulled By: cipolleschi
fbshipit-source-id: a0064418af607953cf46445613796c18fb6e1389
Summary:
Saw a lot of PRs and push to convert existing Java code to Kotlin, and wanted to contribute to the cause. This is a starting point for me so I can understand more about the Java to Kotlin conversion process for ReactAndroid package.
## Changelog:
- Converted AndroidInfoHelpers to Kotlin class
- Converted AndroidInfoModule to Kotlin object and updated usage of it across the package
Pick one each for the category and type tags:
[ANDROID] [CHANGED] - Migrated systeminfo module code from Java to Kotlin
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/47616
Test Plan: Verified build on local dev environment.
Reviewed By: NickGerleman
Differential Revision: D66258996
Pulled By: javache
fbshipit-source-id: e0958c0be735f54cb20c7daeee1526059edaabcc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47484
Small change to types in the base class: all non-primitives return optional from ReadableArray, which matches the semantics in ReadableMap. We already rely on this in some cases, but the current nullability annotations were incorrect, and null values from the array would be passed through from `getMap` and `getArray`.
Changelog: [Android][Breaking] ReadableArray non-primitive getters are now correctly typed as optional
Reviewed By: Abbondanzo
Differential Revision: D65596278
fbshipit-source-id: 5574e9000b07de292bd0da5f1b071aac0eb331d6
Summary:
Changelog: [Internal]
the delegate of TMM is RCTInstance, but RCTInstance doesn't forward all of the APIs and we aren't protected by the compiler because of the optional in TMMDelegate
i found that this backwards compat API did not actually get set up correctly and was never working in the first place... this is why we should avoid optional
long term, TMMDelegate needs to be pushed down to the infra layer and not exist in product, cc blakef
Reviewed By: javache
Differential Revision: D66148789
fbshipit-source-id: 925a6d4ebb6ba6bfb0b1aec6710695e7551ba475
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47892
Update to match the method so it doesn't show as an error in the IDE.
Changelog:[Internal]
Reviewed By: jorge-cab
Differential Revision: D66326667
fbshipit-source-id: f81bdc7763862fc06440b27e417e0b53ad7774da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47889
## Context
When is the runtime ready?
- After the main bundle finishes executing **without** raising a fatal javascript error
## Changes
Let's decorate all errors reported while the runtime is not ready as "[runtime not ready]".
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D66316907
fbshipit-source-id: e48542af4f84d4cc3a6ce8f667dbaa10c30c19a8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47744
Remove DeprecatedInNewArchitecture for ReactProp annotation
ReactProp is still used in new arch, we might remove this annotation in the future but it will be independent of new arch
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D66216728
fbshipit-source-id: 86d9aeb2932cbf34c57a7a850da0ced5268447bf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47783
After the first javascript fatal, the runtime starts tearing down. And it becomes invalid. So, subsequent js fatals will most likely be just noise. Let's filter them out.
This impacts bridgeless mode: both the javascript and c++ pipeline.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D66193194
fbshipit-source-id: 61a731850f7ac4f00bfac24e3260673bf94ba8ed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47886
We were not scaling border radii properly when they overlap.
We were relying on Android's handling of the issue which is not compliant with the web algorithm leading to **visible gaps between layers when the radii overlapped**
We are now following web spec https://www.w3.org/TR/css-backgrounds-3/#corner-overlap
Changelog: [Android] [Added] Add overlapping radii resolution logic preventing incorrect rendering
Reviewed By: NickGerleman
Differential Revision: D66269809
fbshipit-source-id: 4ab7025dc1e41be6205ff6b828617e1e222536a9
Summary:
The `onLayout` handler of the `KeyboardAvoidingView` view is async due to the `await AccessibilityInfo.prefersCrossFadeTransitions` in `_relativeKeyboardHeight`.
A connected `onLayout` handler will be unable to access the event. Call `persist()` on the event so that it can be accessed asynchronously.
## Changelog:
[GENERAL] [FIXED] - Accessing KeyboardAvoidingEvent event in onLayout handler
Pull Request resolved: https://github.com/facebook/react-native/pull/47798
Test Plan:
The following should not produce an error:
```
import * as React from 'react';
import {
KeyboardAvoidingView,
SafeAreaView,
TextInput
} from 'react-native';
export default function() {
return (
<SafeAreaView>
<KeyboardAvoidingView onLayout={(event) => console.log(event)} behavior="padding">
<TextInput />
</KeyboardAvoidingView>
</SafeAreaView>
);
}
```
Reviewed By: cipolleschi
Differential Revision: D66306085
Pulled By: dmytrorykun
fbshipit-source-id: 9ccf00db79947670ddc7de74a47cc6dc27455fc0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47876
Currently, if a device is connected to the bundler via, say, `http://10.0.2.2:8081` (Android default), and a debugger is opened on `http://localhost:8081`, we rewrite hostnames `10.0.2.2.`<->`localhost` so that URLs are correct relative to each.
However, if the debugger is on a different port or protocol, this breaks down - because we only rewrite hostnames.
This fixes that by using the debugger's connecting `Host` header and `encrypted` state to derive the base URL of the server relative to the frontend. We then update the rewriting logic to use this actual full origin (protocol + host) in place of the device-relative origin.
Changelog:
[General][Fixed] dev-middleware: Fix URL rewriting where device and debugger reach the server on different ports/protocols.
Reviewed By: huntie
Differential Revision: D66077627
fbshipit-source-id: 01f6565149caa34b1e9e50dd58deb0122485657c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47872
Largely a refactoring to the way we currently rewrite `url`/`urlRegex` in `Debugger.setBreakpointByURL` CDP requests (debugger->target).
Rewriting regexes is fragile, it only really works if we can assume `'localhost'` appears literally and that ports and protocols don't need changing. The intention here is to freeze the current behaviour so as not to break anyone relying on it (if anyone is), and decouple it from more robust rewriting we want to generalise.
Also adds simple regex escaping to host names (always IPv4 addresses) we inject into regex patterns, since the previous approach could've led to false matches in unlikely edge cases.
Changelog:
[General][Fixed] dev-middleware: Regex-escape IP addresses in urlRegex replacements
Reviewed By: huntie
Differential Revision: D66238782
fbshipit-source-id: 4cd0029081d68c193e36d3713057ffdc7ef0656f
Summary:
currently running jest test, it shows an error:
```
ReferenceError: You are trying to `import` a file after the Jest environment has been torn down. From __tests__/App.test.tsx.
at getState (node_modules/react-native/Libraries/Utilities/Appearance.js:18:26)
at addChangeListener (node_modules/react-native/Libraries/Utilities/Appearance.js:71:19)
at subscribe (node_modules/react-native/Libraries/Utilities/useColorScheme.js:10:66)
at subscribeToStore (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:6232:10)
at commitHookEffectListMount (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:13038:26)
at commitPassiveMountOnFiber (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:14461:11)
at commitPassiveMountEffects_complete (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:14421:9)
at commitPassiveMountEffects_begin (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:14408:7)
at commitPassiveMountEffects (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:14396:3)
at flushPassiveEffectsImpl (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:16287:3)
at flushPassiveEffects (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:16236:14)
at node_modules/react-test-renderer/cjs/react-test-renderer.development.js:16051:9
at workLoop (node_modules/scheduler/cjs/scheduler.development.js:266:34)
at flushWork (node_modules/scheduler/cjs/scheduler.development.js:239:14)
at Immediate.performWorkUntilDeadline [as _onImmediate] (node_modules/scheduler/cjs/scheduler.development.js:533:21)
```
it is a regression from https://github.com/facebook/react-native/issues/46123 that to have a lazy require.
this pr tries to mock `useColorScheme` to return `light`. i think we don't necessarily test the color scheme changes in jest runtime. originally `useColorScheme` also returns `light` because of [this statement](https://github.com/facebook/react-native/blob/9a60038a40e16925ea1adeb3e3c937c22a615485/packages/react-native/Libraries/Utilities/Appearance.js#L77-L83)
## Changelog:
[GENERAL] [FIXED] - Fixed jest error from Appearance.js
Pull Request resolved: https://github.com/facebook/react-native/pull/47629
Test Plan:
```sh
$ npx react-native-community/cli init RN0762 --pm bun --version 0.76.2
$ cd RN0762
$ bun test run
```
Reviewed By: cipolleschi
Differential Revision: D66297456
Pulled By: huntie
fbshipit-source-id: 80d1460532e76bd1815c66964547b50d7f7b3558
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47874
We should be searching for the .bat file on Windows to remain compatible with some user setups.
Changelog: [Android][Fixed] look for sdkmanager.bat
Reviewed By: cipolleschi
Differential Revision: D66295240
fbshipit-source-id: 6b79a9aa40f77ed9c5b3d6ad92b1a62e78159223
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47875
The old architecture looks broken because in the OnLoad.cpp file we try to include the autolinking.h header which is only generated when the New Architecture is enabled.
This fix guards the include and the usage of the function provided by the autolinking so that the old architecture should work as well.
## Changelog
[Internal] - Include autolinkin.h in OnLoad.cpp only if it exists
Reviewed By: blakef
Differential Revision: D66295318
fbshipit-source-id: 18461e6b70ac92af57b805bef51c0df49db02283
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47568
Resolves https://github.com/facebook/hermes/issues/1549.
Changelog:
[General][Fixed] - When using Babel with plain JavaScript files, support for additional user syntax plugins should be fixed (now uses Babel's parser instead of hermes-parser). There is no change for JS files annotated with `flow`, where extended JS syntax remains unsupported.
Reviewed By: blakef
Differential Revision: D65816797
fbshipit-source-id: 9f05e86019548ac8727ee65c2e2c417d78a406d8
Summary:
Fixes https://github.com/facebook/react-native/issues/47725
Calling Appearance.setColorScheme(null) or Appearance.setColorScheme(undefined) no longer resets the color scheme useColorScheme returns like on previous rn versions.
## 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] - Fix `Appearance.setColorScheme(null)` not resetting color scheme value
Pull Request resolved: https://github.com/facebook/react-native/pull/47739
Test Plan: Repo with a patch ready to test: https://github.com/sangonz193/react-native-color-scheme-patch
Reviewed By: yungsters
Differential Revision: D66230236
Pulled By: cipolleschi
fbshipit-source-id: cc668acb1fde6d30f2706fc0ab7dee5cea1c3b14
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47871
Changelog: [internal]
No need to keep going back to save test files when we change C++ files and need to re-run tests :)
Reviewed By: javache
Differential Revision: D66293212
fbshipit-source-id: dc232e1d3f7f8ae1578e894ce14bd21ccf3c8ade
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47870
Changelog: [internal]
This flag allows us to run optimized mode by using the right buck modes for the Fantom CLI, using minified + dev in Metro and building bytecode using Buck as well.
It's disabled by default but in the future we can enable it based on the configuration in the test file (e.g.: if it's a benchmark) or we can run tests in both modes by default to catch problems caused by the differences between environments.
Reviewed By: rshest
Differential Revision: D66292709
fbshipit-source-id: d25294b739ff6a67507990241784b838d5b30dcd
Summary:
### Problem
The calculated width for a multiline text is based on the longest line. However it does not account for text that wraps.
**Example** if numberOfLines=1 and the text wraps
```
+---------------------------+
This is a long text that
will wrap
+---------------------------+
```
The TextView will render
```
+---------------------------+
This is a long text t...
+---------------------------+
```
because the `calculatedWidth` took the width of the first line.
Also see https://github.com/facebook/react-native/pull/41770#issuecomment-2453611554 for additional context.
### Solution
If the text wraps, take the whole width.
```
+---------------------------+
This is a long text that w...
+---------------------------+
```
Fixes https://github.com/facebook/react-native/issues/39722
Fixes https://github.com/facebook/yoga/issues/1730
## Changelog:
[GENERAL] [FIXED] - Fix text not taking full width
Pull Request resolved: https://github.com/facebook/react-native/pull/47435
Test Plan:
```tsx
<Text
numberOfLines={1}
style={{
backgroundColor: 'red',
alignSelf: 'flex-start',
color: 'white',
fontSize: 34,
}}>
{'This is a long text that will wrap.'}
</Text>
<Text
numberOfLines={3}
style={{
backgroundColor: 'red',
alignSelf: 'flex-start',
color: 'white',
fontSize: 34,
}}>
{
'1\n\ntest\nThis is a long text that will wrap.This is a long text that will wrap.This is a long text that will wrap.\n'
}
</Text>
<Text
numberOfLines={3}
style={{
backgroundColor: 'red',
alignSelf: 'flex-start',
color: 'white',
fontSize: 34,
}}>
{
'1\n\nThis is a long text that will wrap.This is a long text that will wrap.This is a long text that will wrap.\n'
}
</Text>
```
1. Verify that the first and third text take full width
2. Verify that the second text does not take full width
| Before | After |
|:------:|:-----:|
| <img width="480" alt="Screenshot 2024-11-05 at 9 00 24 PM" src="https://github.com/user-attachments/assets/b8d765c0-f4b1-42c6-afc7-75862c52612a"> | <img width="480" alt="Screenshot 2024-11-05 at 9 01 49 PM" src="https://github.com/user-attachments/assets/f1534c14-a56a-4d44-8edc-4d9f75166cb2"> |
Reviewed By: NickGerleman
Differential Revision: D65521732
Pulled By: realsoelynn
fbshipit-source-id: 0bb0bb306445e73e8b24ff4c02921739d15ee07e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47754
The `./resolveAssetSource` processor was added to the `defaultSource` prop in the `RCTImageView` static view config in D65819218.
To match this in native view config, we're adding the `customType = "ImageSource"` hint to the view config infra, so it knows to assign correct processor to the native view config in runtime.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D66228921
fbshipit-source-id: d0e0cd9e2f5cc0ba5b3a7002f7ade3f45305a2ac
Summary:
RNTester jobs are failing because we bumped folly to the recent version but we didn't update the podfile.lock
## Changelog:
[Internal] - Bump Podfile.lock to new Folly version
Pull Request resolved: https://github.com/facebook/react-native/pull/47868
Test Plan: GHA
Reviewed By: robhogan
Differential Revision: D66292931
Pulled By: cipolleschi
fbshipit-source-id: 19cbe1321d2891135aa9777823e9dff2916b16dc
Summary:
CI is failing to build HermesC on windows due to a version mismatch of the CMake already installed
## Changelog:
[Internal] - Fix Windows CI for HermesC
Pull Request resolved: https://github.com/facebook/react-native/pull/47867
Test Plan: GHA
Reviewed By: robhogan
Differential Revision: D66292617
Pulled By: cipolleschi
fbshipit-source-id: 5e8f4f45e33fbdd9ff163b4e8a09cb98d4366dc7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47733
In https://github.com/facebook/yoga/pull/1729 I moved the cleanup of `display: contents` nodes to happen before all the early returns, but that change also made it be called **before** `cloneChildrenIfNeeded`. It actually needs to be called after `cloneChildrenIfNeeded` to make sure that children of `display: contents` nodes are properly owned.
It also needs to be called in every short-path, so it's being called in four places in this PR. Please let me know whether it's ok or not.
X-link: https://github.com/facebook/yoga/pull/1743
Reviewed By: NickGerleman
Differential Revision: D65953902
Pulled By: zeyap
fbshipit-source-id: 0b18a5651f19c23564f5b3aa2a50833426e9ca5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47732
This pull request addresses the issue where combining align-content and align-items properties resulted in incorrect layout behavior in Yoga version 3.1.0, as reported in [Issue https://github.com/facebook/yoga/issues/1739](https://github.com/facebook/yoga/issues/1739).
# Changes Made:
Alignment Logic Update: Modified the alignment calculations to ensure that the combination of align-content and align-items properties produces the expected layout, consistent with CSS Flexbox standards and previous Yoga versions.
Test Cases Added: Introduced new test cases to cover scenarios involving various combinations of align-content and align-items properties to prevent future regressions.
# Testing:
All existing tests pass successfully.
New test cases confirm that the layout behaves as expected when align-content and align-items are used together.
# Impact:
This fix ensures that layouts using both align-content and align-items properties render correctly, aligning with the behavior observed in Yoga version 1.19.0 and standard web browsers.
X-link: https://github.com/facebook/yoga/pull/1742
Reviewed By: joevilches
Differential Revision: D65953882
Pulled By: zeyap
fbshipit-source-id: 7e12a21b1d442b35c3f3536cad32dc4b82130d15
Summary:
- Current implementation does not follow CSS spec for rectangle boxes with corner angles. It is using non spec compliant algorithm to calculate start and end points. This PR follows the spec compliant algorithm to implement and makes sure Web, iOS and Android gradients are identical with corner angles.
- Also, currently it is using `CAGradientLayer` which does not support spec compliant start and end points i.e. start and end point can be outside of rectangle bounds. This leads to inconsistent gradients on iOS for corner angles compared to web and android. So this PR replaces it with `CGGradient`.
- I have also moved some files to make it easier to add more background image types in future.
## Changelog:
[GENERAL] [FIXED] - Linear gradient start and end point algorithm.
<!-- 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/47003
Test Plan:
- Added multiple gradient example which should be identical in all platforms (Web, iOS and Android) and tested thoroughly on all platforms. I think some visual test cases can help here.
- I have referred to [blink's](https://github.com/chromium/chromium/blob/main/third_party/blink/renderer/core/css/css_gradient_value.cc) implementation.
## Aside
Took a while to understand the [spec](https://www.w3.org/TR/css-images-3/#corner-gradient-example), but felt great after getting it. Gradients should be 100% identical on all platforms now. Sorry i missed testing cornered angles + rectangles earlier and I found out it is inconsistent on platforms just this weekend 😅
<img width="1389" alt="Screenshot 2024-10-14 at 12 24 45 AM" src="https://github.com/user-attachments/assets/2f61eb87-502b-4b8c-88f3-d8a3cca9a7a3">
Reviewed By: joevilches
Differential Revision: D64497127
Pulled By: jorge-cab
fbshipit-source-id: 2647176ae2ee74b6c71f9061465b07dccdabcfc1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47735
We are trying to remove or minimize private header usage in YogaLayoutableShadowNode.cpp and YogaLayoutableShadowNode.h. There are a few "trivial" ones, meaning some private call maps 1:1 to an existing public API, so I just opt to use that instead
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D66131948
fbshipit-source-id: 7068021513703d1c142d3c298f4804e4e8b81ee2
Summary:
This PR fixes the code for generating EventEmitter C++ code in case nested objects in arrays are used.
```typescript
export interface NativeProps extends ViewProps {
onEvent: DirectEventHandler<
Readonly<{
payloadArray: Readonly<
{
obj: Readonly<{ str: string }>
}[]
>
}>
>;
}
export default codegenNativeComponent<NativeProps>('SomeComponent');
```
In this case the generated `EventEmitters.cpp` code would contain:
```c
obj.setProperty(runtime, "str", payloadArrayValue,obj.str);
```
while
```c
obj.setProperty(runtime, "str", payloadArrayValue.obj.str);
```
is expected.
## 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] - Codegen: Support nested objects in arrays
Pull Request resolved: https://github.com/facebook/react-native/pull/47514
Test Plan: Tested with the reproduction case above to verify correct output.
Reviewed By: javache
Differential Revision: D65848670
Pulled By: elicwhite
fbshipit-source-id: 0021e87bc7213fff615465cab8554cc1a2159522
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47737
We may see an NSRangeException when setting new AttributedString content, where setting the AttributedString itself changes selection (before we mutate it later).
It seems like the selection here is not in a good state yet in regards to the AttributedString backing exposed (since we are reading it while modifying it). So let's fold the logic for updating typing attributes into the collection of ignored work from non-user-selection updates, since programatically setting an AttributedString will already trigger updating typing attributes.
I also added a nil check here, which is unrelated to the crash, but it seems like we should have it for safety...
Changelog:
[iOS][Fixed] - Fix possible NSRangeException when updating typing attributes in response to new text content
Reviewed By: cipolleschi
Differential Revision: D66202986
fbshipit-source-id: fded492b5022c5fef5b9563f93a57549d06a7020
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47738
- updating targetSdk to 35 for RN Android and helloworld
- **Note:** `tagetSdk` of RN Android does not have effect on the app's targetSdk. App can set `targetSdk` regardless of what RN targetSdk is. Updating the targetSdk just signals that RN Android has been tested with targetSdk 35 and apps can choose to support lower targetSdk as needed.
Changelog:
[Android][Changed] updating targetSdk to 35 (apps can still choose their own targetSdk regardless of RN version)
Reviewed By: NickGerleman
Differential Revision: D66209381
fbshipit-source-id: 2f26e8f605a383ff662e4b1d65611f186a7d7979
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47734
- With forced edge-to-edge on Android 15 targetSdk 35, `HermesBadge` overlaps with the top status bar.
- Move the location of the HermesBadge to align with bottom of the header so we can avoid UI overlap with minimal changes to the template.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D66183918
fbshipit-source-id: 6e9eff337660a133349a2813e9ee033a8d2b749e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47707
NewAppScreen should be removed from public API test
Changelog: [Internal]
Reviewed By: cipolleschi, blakef
Differential Revision: D66165484
fbshipit-source-id: 2b72a874e443447a2b444921f25cec729bcb89c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47761
When breaking the last dependency, we created the `RCTApDependencyProvider` in the Codegen pod.
This is not an issue per sè. The problem comes in with the new template in Swift: ReactCodegen contains some headers with some C++ code that Swift can't really process.
That's why most libraries started failing in jobs like [this one](https://github.com/facebook/react-native/actions/runs/11906196751/job/33177904733): the template app was not able to load the `ReactCodegen` pod in the Swift app delegate.
Given that the app delegate only have to actually load the RCTAppDependencyProvider, I extracted that class in its own pod: ReactAppDependencyProvider.
The name of the pod does not follow the React-RCTXXX structure because that will create issues with the import statements and the `use_frameworks!` use case.
> [!NOTE]
> We need to update the template and change the `import ReactCodegen` to `import ReactAppDependencyProvider`
## Changelog:
[iOS][Added] - Extract RCTAppDependencyProvider in the ReactAppDependencyProvider pod
Reviewed By: blakef
Differential Revision: D66241941
fbshipit-source-id: 6b888109c65d9560fff322ec84a16da78fbcd64b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47760
Changelog: [internal]
(this is internal because this API isn't enabled in OSS yet)
This fixes 2 bugs in `MutationObserver`:
1. Incorrectly reporting updates for the same node multiple times, if changes are observable by different targets in the same observer.
2. Incorrectly ignoring observations of subsequent targets in a given observer.
These were caught when migrating the unit tests for `MutationObserver` that were mocking Fabric to a Fantom integration test that uses the whole C++ infra.
Reviewed By: sammy-SC
Differential Revision: D66232571
fbshipit-source-id: b6e967ca4deaa1a69d35f14d4f921103fec2bbaf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47759
Changelog: [internal]
These interfaces should be available in the global scope, so this exposes them in their setup modules.
Reviewed By: javache
Differential Revision: D66232574
fbshipit-source-id: 191c579ffce3fb8b4b454b5c5725661ff160a46f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47758
Changelog: [internal]
This helps with debugging when adding logs in native code. By default they're logged to stderr and not shown in the Jest output, but we can opt into getting them with this new flag.
Reviewed By: sammy-SC
Differential Revision: D66232572
fbshipit-source-id: d507fa4438ae46988fafc92123d0954ab3d27631
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47673
Update shared monorepo build script:
- Refactor entry point discovery and file iteration
- Add support for "exports" subpath patterns (skip considering as entry point with warning)
This is required for the incoming migration of `react-native-codegen` to this build setup (D51465053).
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D66121262
fbshipit-source-id: 0deb2c2b26de442ee348ef9de54a1fa144368b6f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47685
Currently, we assume any URL with a hostname of `10.0.2.2` or `10.0.3.2` (device-relative) is eligible for rewriting to `localhost` (frontend-relative), because we assume the device is an Android emulator. We rewrite these URLs between device and dev machine so that the rewritten URLs are reachable from the dev machine.
This diff narrows this logic so that we'll only rewrite URLs where the hostname matches the pre-existing list *and* this matches the host the device is actually connected on, according to its headers from the original connection.
The main motivation for this change is to unblock removing assumptions about device-reachable vs server-reachable hosts. Later in the stack we'll drop the hardcoded listing of `10.0.2.2` etc in favour of identifying URLs that target the dev server, from whatever network.
There's also an edge case fix here that `10.0.2.2` etc might actually refer to a remote LAN server, and not be an Android emulator's alias for for an emulator host.
Changelog:
[General][Fixed] RN DevTools: Don't assume 10.0.2.2 is an alias for localhost unless it's used to establish a connection to the server
Reviewed By: huntie
Differential Revision: D66058704
fbshipit-source-id: bad28717b0c9b1ca43e2ea3391cef13f87892e6c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47719
There is a subset of `ImageProps` that are used by Android but not used by iOS. They were missing in the `ImageProps.h`. It was fine when they were only consumed by the Android mounting layer. But it becomes a problem if we want to write some shared C++ code based on those props.
This diff adds those props to the corresponding C++ type.
This should have no practical effect for both platforms.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D65426569
fbshipit-source-id: dc1c9fe4a6e0e62e62f84b9b249e1c7d253290f5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47608
This is a codemod. It was automatically generated and will be landed once it is approved and tests are passing in sandcastle.
You have been added as a reviewer by Sentinel or Butterfly.
Autodiff project: fileops2
Autodiff partition: xplat.js.react-native-github.packages.react-native.ReactCommon.cxxreact
Autodiff bookmark: ad.fileops2.xplat.js.react-native-github.packages.react-native.ReactCommon.cxxreact
This updates `open`, `close`, `read`, `write`, and `pipe` call sites to use
`folly::fileops` qualified name lookup.
This is the 2nd phase in a 3-phase change to remove folly's global definitions
of the posix functions that conflict with windows CRT.
The 1st phase created namespaces for folly's posix functions. The 2nd phase
updates callsites to use the qualified name of folly's `open`, `close`,
`read`, `write`, and `pipe` functions. The 3rd and final phase will remove
folly's globally defined posix functions and have windows CRT define them
again.
**What is the reason for this change?**
Folly's global definitions of posix functions on Windows causes `#include`
order issues if folly is not included first.
For example, when `gtest/gtest.h` is included before folly, gtest includes
`windows.h` and that declares `open`, `read`, and `chdir`, which creates
ambiguous references to folly's `open`, `read`, and `chdir`.
Another example is where posix functions go undeclared when
`folly/portability/windows.h` is included without other portability headers
(e.g., `folly/portability/unistd.h`). `folly/portability/windows.h` includes
`windows.h` in a way that only underscore versions of the posix functions are
available (e.g., `_open`, `_close`).
These issues create friction for windows development.
**Background: What is the purpose of `folly::portability::{fcntl,stdlib,sysstat,unistd}`?**
It is a portability layer to make posix functions available and behave
consistently across platforms. Some posix functions don't exist on windows
(e.g., `sysconf`). Some other posix functions, folly changes to adapt behavior
across platforms. For example, on windows folly defines `open`, `read`,
`write`, and `close` functions to work with sockets. Folly makes these
functions available in the global scope for convenience.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D65855147
fbshipit-source-id: b06863330ca213b9d1bffe0ee85e0fbf1bc8a845
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47713
`defaultSource` is defined as a single `ImageSource` in docs (https://reactnative.dev/docs/next/image#defaultsource) but its type is a vector of `ImageSource`s in `ImageProps.h`.
This diff changes its C++ type to just `ImageSource`.
Technically, this is a breaking change, however I don't think folks should directly access `ImageProps` outside of `RCTImageComponentView.mm`
Moreover, this prop is actually not implemented in Fabric, so this change should have no practical effect.
Changelog: [Internal]
Facebook
T208171435 - [RN][Fabric][iOS] Implement defaultSource support for Image
Reviewed By: javache
Differential Revision: D65821570
fbshipit-source-id: 38139b0f8d6da495e82c4ef72c19af3db254ba6c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47637
Changelog: [Internal]
RSNRS does not support off JS thread layout due to current fiber tree corruption when syncing happens on more than one shadow tree at the same time. This diff guarantees that RSNRS will only be enabled on the JS thread, avoiding any state corruption.
Reviewed By: sammy-SC
Differential Revision: D64500893
fbshipit-source-id: aa20f54a0fcfa47534ae099e95307a692bd9fd0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47736
This has been 100% enabled in production across all the apps for more than a month, after an experiment a long time ago, and we kinda depend on it now for correct border drawing in some cases. Let's clean it up!
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D66208418
fbshipit-source-id: 582a38bd84a2d085ba5c4aac4cd478680dd206cc
Summary:
X-link: https://github.com/facebook/yoga/pull/1746
Chrome made some changes for how overflowed row-reverse containers are laid out which was causing some issues on CI. I updated them here and skipped the new failing tests which we would want to followup on.
For LTR, the differences are seen below
|Before|After|
|--|
|{F1962694149} | {F1962694151}|
The extra space is now extending past the flex start edge vs flex end. RTL is the opposite. NickGerleman had deviated from the spec back in the day to match Chrome and it seems they made the adjustment recently. T208209388 is tracking the followup to align with the spec again. Basically, there is a notion of fallback alignment when certain justification/alignment values cannot actually apply. Right now we are falling back to flex start in all cases but we should fallback to start sometimes.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D66138361
fbshipit-source-id: c46d2e9b0cd297069b9cc544e3bded995e4867a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47689
We were seeing some segfaults from trying to access `display_` in Yoga's `replaceChild` function. Some memory debugging helped identify this was a use-after-free error and NickGerleman suggested we try swapping these lines. Logic being the shared_ptr of YogaLayoutableShadowNode is replaced right before we go and replace its yoga node in the yoga tree. If this is the last shared_ptr holding this node we will delete this object and thus the yoga node with it. We do not need to do this first, so let's swap the lines.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D66142356
fbshipit-source-id: 8fd835346edc91e045ed2ee8945a95af21c47556
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47618
Its not optimal to reconstruct CompositeBackgroundDrawable everytime we add a layer to it.
With this change I'm adding an optimization to modify the underlying `LayerDrawable` in place instead of reconstructing everything. `LayerDrawable` has a pretty constrained API and some weirdish behaviors.
- `addLayer` - This API doesnt set the callback for the recently added layer so after adding the layer we also need to manually set the callback
- Mutating `LayerDrawable` in-place is not straightforward, I had to add a function that will figure out where each layer should be inserted
- `LayerDrawable` doesn't allow deleting an element which means that for this case in particular we do need to re-create `CompositeBackgroundDrawable`
- Newer Android versions allow `null` on `LayerDrawable` layers, but older versions do not, this implementation is mostly done this way to accommodate older versions. But also, even though newer versions can have `null` set on a layer `LayerDrawable` still doesn't handle it well and we get some bugs when removing and inserting a layer which the current implementation handles by not relying on null
This is all feature flagged. since it will only be enabled with the new drawables
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D65907786
fbshipit-source-id: c18b898ddfe58faa5b90714945ffcc82d471051d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46818
Before we were using lists which meant `CompositeBackgroundDrawable` had a `LayerDrawable` of variable length.
This meant that our layers were not consistent and made it hard to optimize `CompositeBackgroundDrawable` to not create a new instance every time we set a new Layer.
With this change `CompositeBackgroundDrawable` has a consistent amount of layers which will allow us to more easily mutate it and land the optimization present on D63287222
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D63798842
fbshipit-source-id: bf0b9ee91ff2083b89ca90ace4de00c71bf3153c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47710
There is Android code that supports remapping `defaultSrc` -> `defaultSource` for `ImageNativeComponent`.
The docs reference this prop as `defaultSource`: https://reactnative.dev/docs/next/image#defaultsource
It is not referenced as `defaultSrc` anywhere. Let's unify it as `defaultSource` across both platforms.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D65819218
fbshipit-source-id: 0f468e2327ad07285a45e4c9f5e33d74da411c74
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47676
`getModule` is used by all modern ReactPackage base-classes to allow lazy loading of specific module and should be considered stable at this point.
Changelog: [Android][Added] Marked ReactPackage#getModule as stable.
Reviewed By: mdvacca
Differential Revision: D66127068
fbshipit-source-id: de447794435d267619430e3c0cbc65c6e1c614ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47669
When investigating [#47476](https://github.com/facebook/react-native/issues/47476), I found that the `secureTextInput` prop was not changing in the Mounting layer when changing it in JS.
I track down the problem to the `UIManager::cloneNode` method.
When we clone the node, we first merge the patch that arrives from React into the props controlled by setNativeProps, ignoring the patch's props that are controlled by React.
But then, we forgot to merge back the React's controlled property into the final props, effectively losing them.
This change adds an extra merging step, merging the props controlled with setNativeProps back into the patch of props controlled by React, and then using this new set of props as source of truth.
## Changelog:
[General][Fixed] - do not discard props in the patch when they are not null while using `useNativeProps`
Reviewed By: sammy-SC
Differential Revision: D65948574
fbshipit-source-id: db4f2b793f4a6348456933c95a151012252b8ebc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47704
Now that we have a min requirement of Node 18.18 on `main`, drop dependency on this polyfill.
Changelog: [Internal]
Reviewed By: vzaidman
Differential Revision: D66162328
fbshipit-source-id: e8ab6669fe14ed177eccf4b861c01df4fb0d405a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47718
We have a test in the OSS E2E CI pipeline that is a bit flaky and fails often on Android.
I don't have time to investigate that properly right now, so I'm disabling it to improve the situation on the main branch for the time being.
We are planning to invest more resources in H1 2025 to improve the E2E testing in OSS, so I'll get back to it soon.
## Changelog
[Internal] - Disabling part of the FlatList E2E test in Maestro
Reviewed By: javache
Differential Revision: D66169183
fbshipit-source-id: 5b2b0c45e124a642b626b014b91fa61d17226f9b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47700
Changelog: [internal]
Add support for the string parameter for `toThrow` to assert for specific error messages.
Reviewed By: sammy-SC
Differential Revision: D66118001
fbshipit-source-id: 8c04cd20d4ad17163ec0c7bf943c429507a97985
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47699
Changelog: [internal]
Implements a `jest.fn()` and a subset of methods in `expect` using them (`.toHaveBeenCalled()` and `.toHaveBeenCalledTimes()`).
Reviewed By: sammy-SC
Differential Revision: D66118002
fbshipit-source-id: 5422307d68967d7d8b4c4d5155a45926f8fc8cae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47706
changelog: [internal]
The changelog in D65909191 already has the details. The fix is behind a feature flag. Let's enable it in OSS to stop the bleeding.
Reviewed By: cipolleschi
Differential Revision: D66163663
fbshipit-source-id: 84a3dfb823fdd286e919ebf22b07054b4399662a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47678
No longer referenced and removed from public exports in D49752133
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D66127071
fbshipit-source-id: 90284b26051902243b530658e5795dad31331695
Summary:
In its current for the `podspec_source_build_from_local_source_dir` makes an assumption in the existence of the `artifacts_dir` ("Pods/hermes-engine-artifacts"). This is okay in the case where the `pod install` command is first ran without sitting the `REACT_NATIVE_OVERRIDE_HERMES_DIR` because of
https://github.com/kraenhansen/react-native/blob/1948076b81bbf08794aae8c8d936cf00ec7fe7b3/packages/react-native/sdks/hermes-engine/hermes-utils.rb#L227
In a clean checkout however, this results in an error when archiving the Hermes directory due to the missing parent directory of the archive's destination.
This PR suggests adding a check for and optional creation of the existence of the archive directory before usage.
An alternative that I considered was ensuring the existence inside of the `artifacts_dir` function:
https://github.com/kraenhansen/react-native/blob/1948076b81bbf08794aae8c8d936cf00ec7fe7b3/packages/react-native/sdks/hermes-engine/hermes-utils.rb#L198-L200
But there's only one other call site, which already does the `mkdir -p`.
## 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] - Ensure artifacts directory exists when building Hermes from local source
Pull Request resolved: https://github.com/facebook/react-native/pull/47698
Test Plan:
I verified the fix by:
- Doing a local git clone of the `hermes` repository.
- Ensure no `Pods` directory exists.
- `export REACT_NATIVE_OVERRIDE_HERMES_DIR=/your/local/path/to/hermes` pointing to the local `hermes` repository.
- Run `pod install`
Reviewed By: cipolleschi
Differential Revision: D66162175
Pulled By: dmytrorykun
fbshipit-source-id: 322633e217063e7ca199b9a9602e279df5fbdb70
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47670
Now that we have `babel-plugin-syntax-hermes-parser` in `react-native/babel-preset` (since D63535216), it's no longer necessary to use `hermes-parser` directly in Metro in order to use newer Flow syntax.
Babel with `babel-plugin-syntax-hermes-parser` is generally preferable, because it intelligently falls back to parsing with Babel for any non-`flow` files.
See https://github.com/facebook/hermes/issues/1549 for context.
Changelog:
[General][Fixed] metro-config: Don't use `hermes-parser` by default, prefer `babel-plugin-syntax-hermes-parser`, which supports other syntax plugins.
Reviewed By: huntie
Differential Revision: D66002056
fbshipit-source-id: cf48acec347e2c0791872f8ca4b53f5f8af1c783
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47690
Creates a feature flag to evalute the impact of disabling `InteractionManager` in `Batchinator` and synchronously invoking callbacks after the timeout.
This also deletes the `dispose` arguments in `Batchinator` that were unused.
Changelog:
[Internal]
Reviewed By: bvanderhoof
Differential Revision: D66139643
fbshipit-source-id: d17bab0cd25c0c69779686cb435c063f707255e4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47684
jsBundleLoader parameter was added into DefaultReactHost.getDefaultReactHost but we decided to revert this change.
We want to keep DefaultReactHost.getDefaultReactHost as simple as possible and we don't want to include this change in 0.77
changelog: [Android][Breaking] Remove jsBundleLoader from DefaultReactHost.getDefaultReactHost()
Reviewed By: shwanton
Differential Revision: D66131197
fbshipit-source-id: 7451bb55d7953d3282b23d23ad15e91bae71ff24
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47598
## Changes
Now:
- in bridgeless, NativeModules.foo will also return turbo modules. And, global.__turboModuleProxy no longer exists.
- in bridge, nothing changes.
| **JS API** | **Bridge** | ***[Before]* Bridgeless** | ***[Before]* Bridgeless w/ Interop**| ***[After]* Bridgeless**
| global.__turboModuleProxy | turbo modules | turbo modules | turbo modules |**deleted**
| global.nativeModuleProxy | legacy modules | error | legacy modules | turbo + legacy modules
## Justification
This reduces the cost for adopting the new architecture:
- Prior, you had to migrate the module itself, **and** all its callsites: NativeModules.foo -> NativeFoo
- Now, you have to migrate the module itself **only**.
This simplifies the interop layer logic in bridgeless: all modules come from the same thing.
Changelog: [General][Breaking] Bridgeless: Make NativeModules.foo load turbomodules (unset turboModuleProxy in bridgeless).
Reviewed By: javache
Differential Revision: D65896934
fbshipit-source-id: 10883c292b78759fceac5bd984e0cdf8a679fc67
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47653
## Context
Currently, when `nativeSourceCodeFetching == false`, `inspector-proxy` attempts to pre-fetch source maps, given the URL from a `Debugger.scriptParsed` event, and embeds them into `Debugger.scriptParsed`'s `sourceMapURL` using a data URI.
This was originally to support frontends that did not perform HTTP requests or were blocked (eg by CORS), but we're retaining it for the moment because it's more performant than lazy loading the source map.
Similarly, we perform middleware->server fetches to respond to `Debugger.getScriptSource` events.
To make these fetches for URLs that target `10.0.2.2` (ie, addressable from within an Android emulator) (etc), we rewrite `10.0.2.2`->`localhost` and perform a `fetch` from the Node process running dev-middleware.
## The problem
Consider a setup where:
- Metro is running on a remote server, listening on `8081`.
- Dev machine tunnels `localhost:8082` -> remote `8081`.
- An app is running on an Android emulator on the dev machine, with bundle URL configured to `10.0.2.2:8082`.
In this case, we'll rewrite `10.0.2.2:8082` to `localhost:8082`, which *is* reachable and correct from the dev machine, but *not* from the machine where Metro is running, so the `fetch` of a source map from the inspector proxy will fail.
## Motivation
This might seem like a niche case, but it's part of fixing a series of unsafe assumptions that currently prevent us from running DevTools on an arbitrary port.
## This fix
Preserve the current behaviour (simple `10.0.2.2`<=>`localhost`) for URLs sent to the frontend, but construct a separate, server-relative URL, using the configured `serverBaseUrl`, for `fetch` calls within dev-middleware.
Changelog:
[General][Fixed] RN DevTools: Fix fetching sources and source maps when the dev-server is remote and not tunnelled via the same port+protocol.
Reviewed By: huntie
Differential Revision: D65993910
fbshipit-source-id: a0cdcf1644e97a2af3d8583f2da2aaa51276f68c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47675
Use `request` over `fetch` in `dev-middleware`'s tests.
This is required by the next diff in the stack to spoof the `Host` header for testing purposes, which isn't permitted by the `fetch` spec.
The return type is a bit different (eg `statusCode` vs `status`, no `ok` prop), but the modifications needed are pretty straightforward.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D66005427
fbshipit-source-id: f311b0188d6d0ec220a037774fca78df5373163a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47628
`serverBaseUrl` is currently documented as:
> The base URL to the dev server, as addressible from the local developer machine
This is problematic in general because `dev-middleware` on a server doesn't necessarily know about where clients might be reaching it from, how tunnels or port-forwards are set up, etc., and this can change over the lifetime of the server and vary between clients.
Indeed, our own use of `serverBaseUrl` from both `community-cli-plugin` and internally simply sets it to the host and port the dev server is listening on - ie it's the address of the dev server accessible *from the server*.
This PR changes the docs, redefining `serverBaseUrl`, to match the way we currently specify it.
One usage where we *do* want the previously documented behaviour is in responses to `/json/list` (`getPageDescriptions`) where the URLs in the response should be reachable by a browser requesting `/json/list`.
Here, we use the request (host header, etc.) to attempt to get working base URL.
History:
It should be mentioned that this is the latest in a series of changes like this:
- https://github.com/facebook/react-native/pull/39394
- https://github.com/facebook/react-native/pull/39456
Learning from those:
- This change does *not* break Android emulators, which routes `10.0.2.2` to localhost, or other routed devices, because `/open-debugger` still uses server-relative URLs, and now formally delegates to `BrowserLauncher` to decide what to do with those URLs (internally, VSCode / `xdg-open` handles port forwarding)
- Middleware configuration is no longer required to specify how it is reachable from clients.
This sets up some subsequent changes for more robust handling of tunnelled connections.
Changelog:
[General][Breaking] dev-middleware: Frameworks should specify `serverBaseUrl` relative to the middleware host.
Reviewed By: huntie
Differential Revision: D65974487
fbshipit-source-id: 1face8fc7715df387f75b329e80932d8543ee419
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47652
## Background
When the `nativeSourceCodeFetching` capability is disabled, `inspector-proxy` rewrites URLs exchanged over CDP between device and frontend so that URLs are addressable from CDT - in particular, when using an Android emulator `10.0.2.2` (host's address from within the emulator) is rewritten to and from `localhost` (the equivalent address reachable from the host).
Previously - before we implemented `Network.loadNetworkResource`, or on old frontends that don't attempt to use that method - this worked reasonably well. A `fetch` from CDT to Metro would succeed on the rewritten URL.
## Problem
Since we implemented `Network.loadNetworkResource`, but disabled the `nativeSourceCodeFetching` capability, source fetching is broken under Android emulators. We're rewriting URLs to be frontend-relative, but then attempting to fetch them through the device, because as far as CDT is aware, `Network.loadNetworkResource` should still be tried first.
When `Network.loadNetworkResource` responds with a CDP *error*, CDT falls back to a local fetch (which would work), but when it responds with a CDP *result* of `success: false`, there is no fallback.
## Fix
This diff adds an interception guarded behind `nativeSourceCodeFetching == false`, which rejects any calls to `Network.loadNetworkResource` with a CDP error. This restores the previous behaviour from before `Network.loadNetworkResource` was implemented at all.
NOTE: An alternative approach would be to rewrite URLs back to device-relative for `Network.loadNetworkResource`, but IMO it's more correct for the frontend to respect that the device is asserting that it doesn't have that capability, and not to try to use it.
Changelog:
[Android][Fixed] RN DevTools: Fix source loading when using an Android emulator connecting to a dev server on the host.
Reviewed By: huntie
Differential Revision: D66074731
fbshipit-source-id: f2050c014cd5cfa546bff5e9d0412413a5daff35
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47623
Changelog:
[iOS][Fixed] - "Reconnect DevTools" button not working sometimes
Hotfix for "Reconnect DevTools" button not working:
* T206141946 / [WP: Reconnecting dev tools does not work after restarting the app](https://fb.workplace.com/groups/rn.debugger.feedback/posts/1107620434125533)
* T206754760 / [WP: Can't launch DevTools from Metro sometimes](https://fb.workplace.com/groups/rn.debugger.feedback/posts/1112235073664069/)
Basically, this dialog will keep reappearing like a bad dream:
{F1960030622}
# Repro
Part 1 (Fixed in base stack D65973309)
1. Do NOT have Metro ready.
1. Build and run RNTester/FB Wilde
1. They should be using the local bundled version. App may prompt you to start Metro.
1. Start Metro
1. Go to the device Dev Menu (rage shake) and select Reload
1. Press `r` or `d` in Metro
Expected: Reload and Dev Menu work accordingly
Actual: Metro fails with `No apps connected`:
{F1960039703}
Part 2 (Fixed in this diff)
1. Open React Native DevTools via Metro `j` key or Dev Menu (rage shake)
1. Kill Metro
1. The RN DevTools should show the "disconnected" dialog
1. Start Metro
1. Click "Reconnect DevTools" in RN DevTools
Expected: reconnects
Actual: dialog reappears with an error in Metro:
{F1960043097}
Interestingly, the `r` and `d` keys from Metro works.
# Root cause(s)
Part 1: See D65973309
Part 2:
The error indicates the target/device failed to call `/inspector/device` to register itself. The subsequent calls to `/json/list` returns empty and `/open-debugger` throws.
1. But because `r` & `d` (heh) works, we can observe that there is some kind of auto-reconnect mechanism:
https://www.internalfb.com/code/fbsource/[cfe1706a60b2]/xplat/js/react-native-github/packages/react-native/Libraries/WebSocket/RCTReconnectingWebSocket.m?lines=77-82
1. We do have auto-reconnect for `j` too:
https://www.internalfb.com/code/fbsource/[cfe1706a60b2]/xplat/js/react-native-github/packages/react-native/ReactCommon/jsinspector-modern/InspectorPackagerConnection.cpp?lines=246-254
But unfortunately it only tries once. A long-term fix would be calling reconnect recursively like the Objective-C impl above, e.g.
Edit: the long-term fix ! See V3
```
delegate_->scheduleCallback(
[weakSelf = weak_from_this()] {
auto strongSelf = weakSelf.lock();
if (strongSelf && !strongSelf->closed_) {
strongSelf->reconnectPending_ = false;
strongSelf->connect();
// Keep trying. Never. Give. Up.
if (!strongSelf->isConnected()) {
strongSelf->reconnect();
}
}
},
RECONNECT_DELAY);
```
Edit: I snuck in some time during React Native London Conf and got the long-term fix going! ✌️
{gif:7iyrns4l}
~~It appears that the current impl of `isConnected()` is not a true reflection of the web socket state. My time box for this task ran out, so we'll do a hot fix for the short-term: since we know `r` & `d` reliably reconnects, we'll piggy-back on its lifecycle to attempt reconnection. This works. I'm going on PTO for the year, so the follow-up task is up for grabs here: T207775935.~~
# PS
1. If you start the app with Metro running in step 1, this bug is not present. This is the reason why FB Wilde/Marketplace/Quantum engineers run into this more often (because its custom menu changes the JS URL after start up)
2. This auto-reconnect does not mean the RN DevTools frontend will dismiss the dialog automatically. This is only about the `Metro <> Device` in `Frontend <> Metro <> Device`.
1. Current impl in Metro/Inspector Proxy means that whenever the `Metro <> Device` connection is terminated, the `Frontend <> Metro` connection is killed.
1. This diff helps restore the `Metro <> Device` connection.
1. The `Frontend <> Metro` connection does not currently get reconnected. We can make the Frontend do so, with consideration of preserving logs/states, etc.
Reviewed By: robhogan
Differential Revision: D65952134
fbshipit-source-id: 3abd16f6a7b7ed50e8acdb7c753cc4fbd3317236
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47651
## This Change:
This change uses in the App's AppDelegate the newly generated `RCTAppDependencyProvider`, passing it to the `RCTAppDelegate`.
This change needs to be applied also to the template, when this stack lands.
## Context
React Native has a last temporal dependency on Codegen in the React-RCTAppDelegate pod.
The RCTAppDelegate has the responsibility to provide various dependencies to react native, like third party components and various modules. ReactCodegen is generated when the user create the project, while React-RCTAppDelegate eists in React Native itself.
This dependency means that we cannot prepare prebuilt for iOS for React Native because when we would have to create prebuilds, we would need the React Codegen, but we can't create a React codegen package that will fit all the apps, because React Codegen can contains App Specific modules and components and apps might have different dependencies.
## Changelog:
[iOS][Added] - Pass the `RCTAppDependencyProvider` to the `RCTAppDelegate`
Reviewed By: dmytrorykun
Differential Revision: D66074475
fbshipit-source-id: 93bf500fe37f115352ebd49d3d56955cbaeeea72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47650
## This Change:
This change generates the `RCTAppDependencyProvider` for the apps, so that the amount of changes required by the users is minimal.
## Context
React Native has a last temporal dependency on Codegen in the React-RCTAppDelegate pod.
The RCTAppDelegate has the responsibility to provide various dependencies to react native, like third party components and various modules. ReactCodegen is generated when the user create the project, while React-RCTAppDelegate eists in React Native itself.
This dependency means that we cannot prepare prebuilt for iOS for React Native because when we would have to create prebuilds, we would need the React Codegen, but we can't create a React codegen package that will fit all the apps, because React Codegen can contains App Specific modules and components and apps might have different dependencies.
## Changelog:
[iOS][Added] - Introduce the RCTAppDependencyProvider to minimize the changes required y the users
Reviewed By: dmytrorykun
Differential Revision: D66074456
fbshipit-source-id: 073022e66da53eca6bf948aeda01f17ad85793ff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47649
## This Change:
This change uses the `RCTDependencyProvider` protocol created before, breaking the dependency between the RCTAppDelegate and codegen.
## Context
React Native has a last temporal dependency on Codegen in the React-RCTAppDelegate pod.
The RCTAppDelegate has the responsibility to provide various dependencies to react native, like third party components and various modules. ReactCodegen is generated when the user create the project, while React-RCTAppDelegate eists in React Native itself.
This dependency means that we cannot prepare prebuilt for iOS for React Native because when we would have to create prebuilds, we would need the React Codegen, but we can't create a React codegen package that will fit all the apps, because React Codegen can contains App Specific modules and components and apps might have different dependencies.
## Changelog:
[iOS][Breaking] - Use the RCTDependencyProvider in the RCTAppDelegate, breaking the dependency with Codegen
Reviewed By: dmytrorykun
Differential Revision: D66074438
fbshipit-source-id: 33234411a3840598b9bd16b0b71a15f75fd3c6a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47648
React Native has a last temporal dependency on Codegen in the React-RCTAppDelegate pod.
The RCTAppDelegate has the responsibility to provide various dependencies to react native, like third party components and various modules. ReactCodegen is generated when the user create the project, while React-RCTAppDelegate eists in React Native itself.
This dependency means that we cannot prepare prebuilt for iOS for React Native because when we would have to create prebuilds, we would need the React Codegen, but we can't create a React codegen package that will fit all the apps, because React Codegen can contains App Specific modules and components and apps might have different dependencies.
This change introduces the RCTDependencyProvider protocol to invert this dependency.
## Changelog:
[iOS][Added] - Add RCTDependencyProvider protocol
Reviewed By: dmytrorykun
Differential Revision: D66074409
fbshipit-source-id: 0d3d3f707bcb44c1f34ebeb3ae019f7ea074f60f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47659
Fixes https://github.com/facebook/react-native/issues/47647
There's no convenient way to access the current react context when using the new architecture. Exposing `getCurrentReactContext` allows for users to migrate without forcing the check downstream.
Changelog: [Android][Added] ReactDelegate and ReactActivityDelegate#getCurrentReactContext can be used to access the current context
Reviewed By: rshest
Differential Revision: D66094540
fbshipit-source-id: 2e504f0db3eb04e0fff5a667afed875214ba54a2
Summary:
### Problem
Setting the `tintColor` prop in ActionSheetIOS also changes the tint of disabled entries. This could make them visually indistinguishable from enabled items. The degree to which they are indistinguishable depends on the tint color.
### Solution
This new prop `disabledButtonTintColor` allows customization of disabled items' tint color.
Related PR: https://github.com/facebook/react-native/pull/31972
## Changelog:
[IOS] [ADDED] - added `disabledButtonTintColor` prop to ActionSheetIOS
Pull Request resolved: https://github.com/facebook/react-native/pull/46883
Test Plan:
Tested in RNTester project.
<table>
<tr>
<td align="center">
<strong>Before</strong>
</td>
<td align="center">
<strong>After</strong>
</td>
</tr>
<tr>
<td>
<img src="https://github.com/user-attachments/assets/5ab251d9-3128-45e0-bb1f-907376422df0" alt="Screenshot Before" width="300"/>
</td>
<td>
<img src="https://github.com/user-attachments/assets/96f76a08-bb8d-497a-9c89-dca0e0bdbcbb" alt="Screenshot After" width="300"/>
</td>
</tr>
<tr>
<td align="center">
<strong>Before</strong>
</td>
<td align="center">
<strong>After</strong>
</td>
</tr>
</table>
Reviewed By: lunaleaps
Differential Revision: D65757069
Pulled By: cipolleschi
fbshipit-source-id: 1f51ed6927bfb4fe4e21018c541303dff44b2217
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47658
Changelog: [internal]
AppRegistry logs are showing up again in Fantom because we changed the order and now they're not necessarily showing up last.
This fixes that by filtering them out in any position.
Reviewed By: sammy-SC
Differential Revision: D66094274
fbshipit-source-id: bd37394252ee6309f7093567f9a2b73b641938ce
Summary:
in `prefetchImageWithMetadata`'s implementation in ObjC, the method's `queryRootName` is treated as being nullable. The image spec for it in JS (and the Codegened ObjC header that gets built on top of it) treat the field as not nullable. This change makes the field nullable in the spec to match up what we have in the implementation.
I also noticed that the method is not defined in the [Image props](https://reactnative.dev/docs/image) on the RN website, so perhaps we should add this there as well.
bypass-github-export-checks
## Changelog:
[IOS] [CHANGED] - make `prefetchImageWithMetadata`'s `queryRootName` nullable in the spec
Pull Request resolved: https://github.com/facebook/react-native/pull/47532
Test Plan:
yarn test:
<img width="1576" alt="Screenshot 2024-11-09 at 00 36 30" src="https://github.com/user-attachments/assets/4162ff79-1388-4f6f-9576-256fd9011fcf">
It has no iOS specific tests, so nothing to run on that side
Reviewed By: javache
Differential Revision: D65761208
Pulled By: cipolleschi
fbshipit-source-id: d050950486e9f804b65dab047d93761a610a71e7
Summary:
Currently in iOS, when focusing the multiline text input, the cursor is not automatically scrolled into view if it is out of view. This PR adds the small util to scroll the cursor into view when the text input focuses. This doesn't happen in Android due to [this](https://github.com/facebook/react-native/blob/defb0bd137711d3e76514d9202005a221a345871/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactEditText.java#L360)
Original issue: https://github.com/Expensify/App/issues/48122
Original proposal: https://github.com/Expensify/App/issues/48122#issuecomment-2320769418
## 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] [ADDED] - Scroll the cursor into view when text input is focused
Pull Request resolved: https://github.com/facebook/react-native/pull/46411
Test Plan:
Code to reproduce in rn-tester
```
const TextInputWithFocusButton = () => {
const inputToFocusRef = React.useRef<React.ElementRef<typeof TextInput> | null>(null);
return (
<View>
<ExampleTextInput
ref={inputToFocusRef}
placeholder="height increases with content"
defaultValue="React Native enables you to build world-class application experiences on native platforms using a consistent developer experience based on JavaScript and React. The focus of React Native is on developer efficiency across all the platforms you care about - learn once, write anywhere. Facebook uses React Native in multiple production apps and will continue investing in React Native."
multiline={true}
enablesReturnKeyAutomatically={true}
returnKeyType="go"
style={[styles.multiline, styles.multilineExpandable]}
/>
<Button title="Focus" onPress={() => {
inputToFocusRef.current?.focus();
}} />
</View>
);
};
```
Steps:
- Move the cursor of the input to end of the input text
- Scroll up the input
- Blur the input
- Click on `Focus` button to re-focus the input
Note that before this fix, the cursor is not scrolled into view
- In iOS
<table>
<tr>
<th>Before</th>
<th>After</th>
</tr>
<tr>
<td>
https://github.com/user-attachments/assets/de589cbf-158c-4e28-81d6-8412bf05ab23
</td>
<td>
https://github.com/user-attachments/assets/81c571f9-653b-49a5-9ecb-6eeaa2c54ec7
</td>
</tr>
</table>
Reviewed By: sammy-SC
Differential Revision: D62847985
Pulled By: cipolleschi
fbshipit-source-id: c0367a7fc0a7a16b30c4538e59f42d971d959357
Summary:
This pull request addresses a CMake configuration issue where an invalid escape character in file paths caused the build process to fail. Specifically, it resolves the issue in the React Native CMake configuration file where the path separator was incorrectly handled, leading to an error in the build system.
the issue is in [This Issue](https://github.com/expo/expo/issues/32955) and [This](https://github.com/expo/expo/issues/32957)
## 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
-->
[INTERNAL] [FIXED] - Corrected invalid escape character in CMake path handling
Pull Request resolved: https://github.com/facebook/react-native/pull/47641
Test Plan:
To test the changes, I performed the following steps:
1. Cloned the repository and checked out the `fix-cmake-invalid-escape-character` branch.
2. Ran the CMake build on a Windows environment where the issue was previously occurring.
3. Verified that the build process completed successfully without the "invalid character escape" error.
4. Ensured that the path handling now works correctly in CMake on Windows platforms.
Reviewed By: rshest
Differential Revision: D66073896
Pulled By: cipolleschi
fbshipit-source-id: bd2a71bb00ce5c5509ed403842c995c32f58f91d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47646
changelog: [internal]
In order to control scheduling of tests, test setup must be separated from test running. This is because of how internal scheduling of React Native is restricted until bundle is loaded via BufferedRuntimeExecutor. This is the reason for executing tests by calling global function `$$RunTests$$`. This is not a pretty solution but it is hidden within testing infrastructure and users of our test infra are not exposed to this.
There is a new method exposed to JavaScript: flushMessageQueue. This will flush everything that is inside of message queue. This is the queue where tasks are queued whenever RuntimeScheduler enqueues something by calling `runtimeExecutor_`.
Reviewed By: christophpurrer
Differential Revision: D65951894
fbshipit-source-id: 2e8e0c10fbeb998f4a51ee6d01ef229eb5f70448
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47604
## Changelog:
[iOS] [Fixed] - Fixed use of view commands from layout effects
Mounting of views is delayed by runtime scheduler to allow React to run layout effects. Execution of view commands must by queued together with mounting of views, otherwise it might be executed before views are mounted. When this happens, view commands are ignored.
So before, if view command was executed from layout effect (or ref function), it would get dispatched to the UI thread as quickly as possible. But mounting of views would be delayed. To fix this, both mounting of views and view commands are put on the same queue inside of RuntimeScheduler.
## What about Android?
Android employs a [retry mechanism](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/fabric/mounting/MountItemDispatcher.java#L211) that was needed for react tag based view commands. In paper, one could send a view command to a react tag which was completely disconnected from whether a view exists or not.
iOS was built with ref commands in mind, so it doesn't have this mechanism.
Fixes: https://github.com/facebook/react-native/issues/47576
Reviewed By: javache, cipolleschi
Differential Revision: D65909191
fbshipit-source-id: 9d2a444879bee62a7b8b7d31edde450e18339b89
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47636
We're cleaning up key spreads across WWW/Fbsource. Flow's `ban_spread_key_props` option allows us to fix existing spreads and prevent new ones from being added in code covered by Flow.
Here we fix spreads within xplat/js.
Also based on a unit test keeping config in sync, I've added the option to metro and RN OSS as well.
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D64427942
fbshipit-source-id: db8f4aa428ce1994304b5d814b9d241d26e8d522
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47638
This diff exposes exceptionHandler as a parameter of DefaultReactHost, this is necessary becuase apps using getDefaultReactHost are not able to set an exceptionHandler
We need to revisit this API as a follow up
changelog: [Android][Added] Add exceptionHandler as a parameter of DefaultReactHost.getDefaultReactHost() method
Reviewed By: alanleedev
Differential Revision: D66011047
fbshipit-source-id: 3f36aa0d064a0b1b47e9f71df55bbe466950048a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47605
changelog: [internal]
use a pointer to RuntimeScheduler instead of getting a reference to it from context container each time.
Reviewed By: javache, cipolleschi
Differential Revision: D65909100
fbshipit-source-id: c53c9b573777803f7f3077656af1dae0db7eee88
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47557
Changelog: [internal]
Not published as a bugfix because this API isn't enabled in OSS yet.
Reviewed By: sammy-SC
Differential Revision: D65769326
fbshipit-source-id: 165d58304d8214c583fbc162d8888095e9f068aa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47612
Changelog: [internal]
Just using babel-register so we can use Flow types in the code for the RN integration tests runner.
Reviewed By: sammy-SC
Differential Revision: D65948801
fbshipit-source-id: 6c54b0463fe4b71c818ff1c4faa973cc8b13b5d2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47615
Changelog: [internal]
Fixes `.not` not being applied in some cases, and no logging the "not" label in case of error, and `.toBe` being flipped.
Reviewed By: javache
Differential Revision: D65952221
fbshipit-source-id: 030c0597b661d34e6324d69e5676375150a74f2e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47624
Changelog:
[iOS][Fixed] - fix `r` & `d` not working from Metro sometimes
While investigating these bugs, I've come across some cases where `r` (Reload) & `d` (Open Dev Menu) not working in Metro.
* T206141946 / [WP: Reconnecting dev tools does not work after restarting the app](https://fb.workplace.com/groups/rn.debugger.feedback/posts/1107620434125533)
* T206754760 / [WP: Can't launch DevTools from Metro sometimes](https://fb.workplace.com/groups/rn.debugger.feedback/posts/1112235073664069/)
This is because when we
1. Start app without Metro
1. Start Metro
1. Reload from Dev Menu (rage shake)
`RCTPackagerConnection` did not get notified about the change in bundle URL. It'd stay "listening" to the commands from the local bundle instead of Metro
.
Reviewed By: robhogan
Differential Revision: D65973309
fbshipit-source-id: a67a58b405bb78dfe56b814f2ec0bbee9e530e46
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47596
Improves the Flow type of `usePressability` so that if the `config` argument is non-nullable, the return value is non-nullable. This helps reduce unnecessary null checks.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D65908791
fbshipit-source-id: 77de4391d8141d698a5689e617b692b337d01ae5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47588
This is unnecessary - we can pass the params directly instead of first populating them in a Rect.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D65843834
fbshipit-source-id: 92bb3faa622bba81792fe92e357bc1667894d4ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47595
Enables the `useInsertionEffectsForAnimations` feature flag by default. This changes `useAnimatedProps` to enqueue updates to the `AnimatedNode` graph in `useInsertionEffect` instead of `useLayoutEffect`.
The main motivation for `useInsertionEffect` is to avoid unmounting `AnimatedNode` graphs when an `Activity` subtree becomes hidden.
Both `useInsertionEffect` and `useLayoutEffect` occur during the commit phase. Although they occur at different moments in the commit phase, the different is difficult to observe and unlikely to impact product code.
One observable impact is that with `useInsertionEffect`, animations can now be started from layout effects.
Changelog:
[General][Changed] - The `AnimatedNode` graph will not occur during the insertion effect phase, which means animations can now be reliably started during layout effects.
Reviewed By: mdvacca
Differential Revision: D65906157
fbshipit-source-id: d09b2f1b76079eecafbed8c6f5d8ee4695a1f81c
Summary:
This PR adds support for negative values in enums.
Currently when we try to use an enum with negative value:
```ts
enum MyEnum {
ZERO = 0,
POSITIVE = 1,
NEGATIVE = -1,
}
export interface Spec extends TurboModule {
useArg(arg: MyEnum): void;
}
export default TurboModuleRegistry.get<Spec>('Foo');
```
It will fail:
```
Enum values can not be mixed. They all must be either blank, number, or string values.
```
This is because negative values are parsed as `UnaryExpressions` which have `-` operator in front and value as argument.
With the new approach codegen properly generates enums with negative values.
## Changelog:
[GENERAL] [ADDED] - Codegen: Support negative values in enums
Pull Request resolved: https://github.com/facebook/react-native/pull/47452
Test Plan: I've added tests to see if everything is working properly
Reviewed By: vzaidman
Differential Revision: D65887888
Pulled By: elicwhite
fbshipit-source-id: edb25f663dc58afa68c69cb84a47cfc67fc1f7e7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47577
Changelog: [Android][Fixed] ensure setSelection in onAttachedToWindow is within text range
Reviewed By: javache
Differential Revision: D65824906
fbshipit-source-id: 3dc7d27bf4f9a10762f11fa4a0bcae8af13c7db7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47585
We have two classes named ReactFontManager and during the Kotlin migration this got mixed up.
Changelog: [Android][Fixed] Fixed crash in legacy ReactFontManager
Reviewed By: fabriziocucci
Differential Revision: D65877606
fbshipit-source-id: d9dc4f29045ad377adb216216334af5501c5546e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47567
Changelog: [Android][Changed] Invocations to JS will now invoke their callbacks immediately if the instance is ready. Surface starts will not wait for the main thread to become available to dispatch the work in JS.
Reviewed By: rshest
Differential Revision: D65661888
fbshipit-source-id: c67802bd56fac6bc6c145b96d823274e2b97de69
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47566
Changelog: [Android][Changed] TurboModules marked as requiring eager init will now be constructed on the mqt_native thread to increase concurrency in React Native init.
Reviewed By: rshest
Differential Revision: D65661887
fbshipit-source-id: c1863ea44771de5caedc2968a325abcc7022c792
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47579
BridgeReactContext is public only for testing. I'm annotating it with VisibileForTesting to make it explicit
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D65705093
fbshipit-source-id: d4d7c4195926e2d0397e805b4c49b0710a82a7eb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47565
Changelog: [internal]
We unified the feature flags for the event loop in https://github.com/facebook/react-native/pull/47084, but we left the legacy flags defined for temporary backwards compatibility.
We don't need that anymore, so we can clean them up.
Reviewed By: fabriziocucci
Differential Revision: D65606068
fbshipit-source-id: 403c278cef2afc8eddf07592d88cadc58765f660
Summary:
This PR follows up on https://github.com/facebook/react-native/issues/47182 and https://github.com/facebook/react-native/issues/47348 by adding `force-cache`, the final missing option to align caching controls with the existing behavior on iOS.
Local caching behavior remains unchanged: if a cached image is available locally, it will be returned; otherwise, a network request will be made.
When an image request is sent over the network, the `force-cache` option sent from the sent fJS side will now use the `okhttp3.CacheControl.FORCE_CACHE` directive.
## Changelog:
[ANDROID] [ADDED] - Image `force-cache` caching control option
Pull Request resolved: https://github.com/facebook/react-native/pull/47426
Test Plan:
New example added to the RNTester under the cache policy examples. Then inspecting that the cache control is set correctly before sending it in the `okhttp3.Request` builder.
```kt
FLog.w("ReactNative", "fetching uri: %s, with cacheControl: %s", uri, cacheControlBuilder.build().toString())
// fetching uri: https:...png?cacheBust=force-cache, with cacheControl: no-store, max-stale=2147483647, only-if-cached
```
This case was a bit more tricky to test in terms of e2e as it would involve some caching in the server as well, I'm open to suggestions to make this more complete.
Reviewed By: javache
Differential Revision: D65490360
Pulled By: Abbondanzo
fbshipit-source-id: f807a9793f85caea39c59a370d057b9a1d450a78
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47520
Right now, when a 3p library needs to register a component in the component system, we have to crawl the library to try and get the mappng, best effort.
With this approach, we are enriching the `codegenConfig` property to allow library developers to define the mapping themselves.
For example:
```json
//...
"codegenConfig": {
//..
"ios": {
"componentProvider": {
"RNTMyNativeView": "RNTMyNativeViewComponentView"
}
}
},
```
means that the JS component `RNTMyNativeView` will be mapped to the `RNTMyNativeViewComponentView` class.
This also work for local apps, and it warns the users about what libraries are using the deprecated approach, so they can open an issue or a PR to those libraries.
## Changelog:
[iOS][Added] - Allow 3p developers to specify the association between components and classes in Fabric
Reviewed By: dmytrorykun
Differential Revision: D65666061
fbshipit-source-id: 692e753635873ff9260e131d2d18ed226b2378c2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47518
This change reintroduce the generation of the `RCTThirdPartyComponentProvider` but in the right place and with the right patterns.
1. We are generating it in the user space, not in the node_modules (fixes the circular dependency)
2. We are not using weak function signature that have to be implicitly linked to some symbols found during compilation
The change needs to crawl the folder to retrieve the information it needs. We need to implement it this way not to be breaking with respect of the current implementation.
The assumption is that components have a function in their `.mm` file with this shape:
```objc
Class<RCTComponentViewProtocol> <componentName>Cls(void)
{
return <ComponentViewClass>.class;
}
```
I verified on GH that all the libraries out there follow this pattern.
A better approach will let library owner to specify the association of `componentName, componentClass` in the `codegenConfig`.
We will implement that as the next step and we will support both for some versions for backward compatibility.
## Changelog
[iOS][Changed] - Change how components automatically register
Reviewed By: dmytrorykun
Differential Revision: D65614347
fbshipit-source-id: a378b8bc31c1ab3d49552f2f6a4c86c3b578746b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47517
The `RCTThirdPartyLibraryComponentProvider` has been introduced to automate the component registration of third party libraries in the apps. However, it has some serious flaws:
* It is generated in the React/Fabric folder, which means that it is generated in node_modules
* It is generated when the user installs the components in the app, which means that we can't prebuild and redistribute React Native as a binary
* it does not work with Frameworks and dynamic linking: in this scenarion, Fabric must build in isolation and if there are third party libraries involved, the lookup of the `xxxCls` function will fail
This change removes the generation of the `RCTThirdPartyLibraryComponentProvider`. In the next diffs we will implement a different mechanism to register components
## Changelog
[iOS][Changed] - Stop generating the RCTThirdPartyLibraryComponentProvider
Reviewed By: dmytrorykun
Differential Revision: D65601939
fbshipit-source-id: 9cc8c46102827d124b93b8aa6705b5e6014695c1
Summary:
Resolve warning on ios build:
```
.../ios/Pods/Headers/Public/React-Core/React/RCTAppearance.h:16:60 A function declaration without a prototype is deprecated in all versions of C
```
## 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] - Resolve deprecated function prototype warning in RCTAppearance.h
Pull Request resolved: https://github.com/facebook/react-native/pull/47564
Test Plan:
Jest Result (`yarn test`):
```
Test Suites: 234 passed, 234 total
Tests: 2 skipped, 4899 passed, 4901 total
Snapshots: 1687 passed, 1687 total
Time: 46.387 s
Ran all test suites.
```
Reviewed By: cipolleschi
Differential Revision: D65816584
Pulled By: javache
fbshipit-source-id: 212021c39dfde7e638752940e67a9f964d2194ab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47531
When the activity is paused, or destroyed, we should disable the devsupportmanager. (This performs cleanup).
When the activity is resumed, we should re-enable devsupportmanager. (This performs re-initialization).
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D65689053
fbshipit-source-id: 99de0906b8cdc84f56b4d334ac0eeecc7b436dd5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47528
After the js pipeline fails to handle the error, reset the hasHandledFatalError var.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D65678387
fbshipit-source-id: ac7cd4724954ea78bf33542e208c5f5d3dba5383
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47529
RuntimeExecutor, RuntimeScheduler, etc. can execute arbitrary c++ on the javascript thread.
If that c++ throws a non-jsi::JSError, it will bypass the js error handler (and start tearing down the react instance 😱).
Let's have the js error handler manage all exceptions raised while native is calling into js. This is more sane.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D64626610
fbshipit-source-id: 40132f24b4e2737ae3f055fbd09153111404e5bf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47468
Across our scroll view implementations on iOS, we fire `onMomentumScrollEnd` whenever the scroll view finishes decelerating, whether it comes from a user's touch or call to `setContentOffset` with animations. But we omit dispatching the `onMomentumScrollBegin` event in the latter cases.
This change updates both old and new architecture to dispatch `onMomentumScrollBegin` when a view-command-driven scroll occurs with animation, like `scrollTo` or `scrollToEnd`.
Changelog:
[iOS][Fixed] - Fixed `onMomentumScrollBegin` event not firing on command-driven scroll events
Reviewed By: javache
Differential Revision: D65556000
fbshipit-source-id: bc4b778c63d8a032e1d8e00b9d4d5f83a5d651d6
Summary:
Follow up from https://github.com/facebook/react-native/issues/47433, adding some missing scenarios in the unit tests for the image component in Android.
## Changelog:
[INTERNAL] [ADDED] - Improving Android `ImageResizeMode` unit tests
Pull Request resolved: https://github.com/facebook/react-native/pull/47527
Test Plan:
```bash
yarn test-android
```
Reviewed By: fabriziocucci
Differential Revision: D65735794
Pulled By: Abbondanzo
fbshipit-source-id: a420274c78d9eadf0439870cfaae4d16247c6034
Summary:
On android the isGrayScaleEnabled method of AccessibilityInfo always returns false due to missing implementation. This PR fills the gap by providing the native module logic for checking grayscale mode.
## Changelog:
- Added native module code to check for grayscale mode on android
- Updated js accessibility info module to return the correct promise instead of default false for isGrayScaleEnabled()
- Moved the test for isGrayScaleEnabled() out of ios scope to common Android and iOS scope
[ANDROID] [ADDED] - logic to check for grayscale mode on android
Pull Request resolved: https://github.com/facebook/react-native/pull/47497
Test Plan:
Tested on :
- Google Pixel 7 Pro (Android 14)
- OnePlus 12 (Android 14)
- Pixel 6 (Android 15)
Reviewed By: cortinico
Differential Revision: D65662583
Pulled By: javache
fbshipit-source-id: 39f9ce37c9375b5380257847395393045eedbadc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47494
Changelog: [General][Changed] AttributedString `appendFragment` and `prependFragment` take an rval instead of a const ref; append/prependAttributedString have been removed
Reviewed By: mdvacca
Differential Revision: D65603864
fbshipit-source-id: 1160a9e2064470f826bea66736b4fce13caa3a73
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47543
TaskCompletionSource is public but it shouldn't, in this diff I'm making it intenral
changelog: [Android][Breaking] Reduce visibility of TaskCompletionSource class
Reviewed By: javache
Differential Revision: D65738324
fbshipit-source-id: 61db35a408162c53398b20e45a52f3eb46de1eae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47540
Continuation is only used inside RN, we should make it internal
changelog: [Android][Changed] Reduce visibility of Continuation to internal, although this interface wasn't being exposed in any public API
Reviewed By: javache
Differential Revision: D65738329
fbshipit-source-id: 6fb1b9e9a253eafad0f6eb1e4c1363d6254846da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47548
changelog: [internal]
This race condition only shows itself with flag `useOptimizedEventBatchingOnAndroid`
# Problem
EventBeat assumes method `induce` will be called repeatedly on every UI tick. This is true for iOS and existing implementation of event beat on Android. The first early exist inside of `induce` method is built with this assumption.
`useOptimizedEventBatchingOnAndroid` on Android changes this. `induce` will only be called after FabricUIManager.onRequestEventBeat is invoked and then it will stop. For one `FabricUIManager.onRequestEventBeat` call, `EventBeat::induce` is called once. And there is a chance for race condition.
Here is a simplified implementation of `induce`. This method may be called many times in sequence. The caller will set [isRequested_](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactCommon/react/renderer/core/EventBeat.cpp#L25) and then invoke [FabricUIManager.onRequestEventBeat](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/jni/react/fabric/AndroidEventBeat.cpp#L43). Notice how `FabricUIManager.onRequestEventBeat` is debounced if `isRequested_` flag is true.
```
void EventBeat::induce() const {
if (!isRequested_ || isBeatCallbackScheduled_) {
// isRequested_ is not set to false in case isBeatCallbackScheduled_) is true.
return;
}
isRequested_ = false;
isBeatCallbackScheduled_ = true;
auto beat = std::function<void(jsi::Runtime&)>(
// on JS queue
isBeatCallbackScheduled_ = false;
// beatCallback_(runtime)
}
runtimeScheduler_.scheduleWork(std::move(beat));
}
```
This can get into a state where `isRequested_` is not reset back to false even though `EventBeat::induce` is called when `isBeatCallbackScheduled_` is true.
`AndroidEventBeat::request` -> `isRequested_` is set to true -> `FabricUIManager::onRequestEventBeat` -> `EventBeat::induce` -> `isRequested_` is set to false -> `isBeatCallbackScheduled_` is set to true -> `AndroidEventBeat::request` -> `FabricUIManager::onRequestEventBeat` -> `EventBeat::induce` (early exit because `isBeatCallbackScheduled_` is true) -> `beat` is executed on the JS thread.
From this point on, subsequent calls to `AndroidEventBeat::request` are always debounced because flag `isRequested_` is true.
Any subsequent event on Android will end up calling `EventBeat::induce` and the mechanism gets unstuck.
# The fix
The fix is simple, any time `EventBeat::induce` is called, make sure `request_` flag is set to false. This then satisfied the expectation of `useOptimizedEventBatchingOnAndroid` optimisation.
Reviewed By: rubennorte
Differential Revision: D65566258
fbshipit-source-id: 5f15da8f5cb722b329f9f72b9ddca8e2cac04144
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47547
In [#47176](https://github.com/facebook/react-native/pull/47176) we disabled the generation of the component registration for app specific components as it was creating a circular dependency between the app and React Native.
However, we made a couple of typos that make it not work as expected and users picked up those typos soon.
This change fixes them for good.
## Changelog
[iOS][Fixed] - Properly stop generating component registration for components defined in app.
Reviewed By: blakef
Differential Revision: D65750433
fbshipit-source-id: 1a879c5be014905558b9fd05e6f16ac36b784ed6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47534
This diff is introducing a new method to destroy React instance that allows the caller to be notified when the destroy finishes
This is necessary for apps to act upon destroy of the react instance
changelog: [internal] internal
Reviewed By: shwanton
Differential Revision: D65721107
fbshipit-source-id: 2d3d9755db38461ba381b86c72df5869c542379b
Summary:
All `removeEventListener` methods was removed https://github.com/facebook/react-native/commit/2596b2f6954362d2cd34a1be870810ab90cbb916 perviously but seems a `BackHandler` was missed
This can be a breaking change for some third-party modules.
**Migration**: Use `remove` on the EventSubscription from `addEventListener`:
```diff
useEffect(()=>{
+ const subscription = NativeModule.removeListener(name, listener);
+ return ()=>subscription.remove();
},[])
```
## Changelog:
[GENERAL] [REMOVED] - Remove `BackHandler.removeEventListener`
Pull Request resolved: https://github.com/facebook/react-native/pull/45892
Test Plan: ...
Reviewed By: huntie
Differential Revision: D65663591
Pulled By: javache
fbshipit-source-id: 01b804cd6ec77ea4916a0ced7fee551d045f1684
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47383
CatalystInstance is deprecated and will be removed in new architecture
changelog: [Android][Changed] Deprecate CatalystInstance in old architecture
Reviewed By: cortinico
Differential Revision: D65430643
fbshipit-source-id: 96ba91c45760ead8155f9f28b6fad523be75929e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47525
This API is awkward for nullsafe code. Adding an extension allows Kotlin code to use `applyTextTransform()` on either nullable or non-null strings:
```
val a: String = string.applyTextTransform(...)
val b: String? = nullableString?.applyTextTransform(...)
```
Changelog:
[Android][Added] TextTransform ktx
Reviewed By: javache
Differential Revision: D65618709
fbshipit-source-id: 28a0fe61a0eaf27aa9677af39d932982f3b694b2
Summary:
`react.ref_as_prop=experimental.partial_support` will expose errors where a ref prop is passed to a function component without ref prop. This diff pre-suppresses the newly exposed errors.
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D65686695
fbshipit-source-id: f241cc40f3ac414a2960dec60d9ba4633e5f93c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47278
When we have multiple spans of text inside a <Text> element, React will emit these as separate RawText ShadowNodes. RawText shadow nodes cannot have any properties beyond the text they contain, yet our current AttributedText logic will generate a separate span for each and duplicate all the relevant properties.
This can be particularly inefficient when JSX is used to interpolate strings, e.g. `<Text styles={styles.text}>Example {i}/{count}</Text>` results in 4 raw text elements with duplicated properties.
Changelog: [General][Changed] Improved AttributedText generation for raw text nodes.
Reviewed By: NickGerleman
Differential Revision: D65134912
fbshipit-source-id: dba4296ebe9987e989760cdee66f1e076fbb7a98
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47512
As can be seen in `renderApplication`, `useConcurrentRoot` is no longer used to decide whether to run the application in concurrent mode, as we default all Fabric-users to concurrent root.
Changelog: [General][Removed] Removed type for useConcurrentRoot from AppRegistry, as it was already ignored
Reviewed By: sammy-SC, fabriziocucci
Differential Revision: D65660681
fbshipit-source-id: c99e5ae14d515015709908ed21a854c780f628e0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47503
Enables the `scheduleAnimatedEndCallbackInMicrotask` feature flag that was introduced in https://github.com/facebook/react-native/pull/46714.
Changelog:
[General][Changed] - Callbacks passed to `animation.start(<callback>)` will be scheduled for execution in a microtask. Previously, there were certain scenarios in which the callback could be synchronously executed by `start`.
Reviewed By: javache
Differential Revision: D65645981
fbshipit-source-id: ac159208b7c1df60549baa52704bb0e704da0acf
Summary:
As titled. This API is legacy / Meta-only.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D65666574
fbshipit-source-id: f9700486aec0306b305910bff14ae7f3df3fab7f
Summary:
While we're waiting for 19 stable, let's bring main back to 18.3.1 ahead of the 0.77 branch cut. We'll land this change just after 19 stable lands.
This is a cherry pick of b93b378fa0 which landed in 0.76 already
bypass-github-export-checks
## Changelog:
[INTERNAL] - Revert React 19RC to React 18.3.1
Pull Request resolved: https://github.com/facebook/react-native/pull/47380
Test Plan: CI
Reviewed By: cipolleschi
Differential Revision: D65430775
Pulled By: cortinico
fbshipit-source-id: f0f211754c8ffe5d037fd299e4de52c29d1d7913
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47506
The Check nightlies job prepare a new nightly app with additional libraries and on iOS it builds with `yarn ios`.
The command tries to launch the app on the simulator which sometimes fails and this can make the jobs keep running for hours.
This change make sure that we only build the app
## Changelog:
[Internal] - Only build iOS in CI for Check Nightlies
Reviewed By: blakef
Differential Revision: D65656812
fbshipit-source-id: 14db3738f33f8024c9e99fe206b170209154bac7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47502
Enables the two following feature flags:
- `enableAnimatedAllowlist`
- `enableAnimatedPropsMemo`
The former enables the use of an experimental optimization to provide `unstable_createAnimatedComponentWithAllowlist` and `useAnimatedProps` an allowlist of props that reduces the set of props iterated over by to find props with `AnimatedNode` (e.g. `Animated.Value`) instance values.
The latter enables improved memoization logic in `Animated` so that its intenal state is invalidated less frequently, reducing the cost of updating `Animated` components.
Changelog:
[General][Changed] - Optimized the performance of updating `Animated` components.
Reviewed By: rozele
Differential Revision: D65645985
fbshipit-source-id: 85f9e53072f09a59589d76d0c096f4cedd17bb4b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47498
I am trying to help someone with creating a sticky header on a scrollview, specifically one that floats on the side of the scrollview instead of the top Currently we can't really do that, since utilizing `position: absolute` to layout this properly will get overriden by the header styles changed in this diff
This was only added since static was the default and we needed to apply zIndex. With proper static implementation that is no longer the case, so I think it makes sense to remove this to support this use case.
Changelog: [General] [Breaking] - `position` of sticky headers on `ScrollView` will now be taken into account
Reviewed By: rozele
Differential Revision: D65626544
fbshipit-source-id: 8d650ca7654918e692435935e7c1094c412fd9f6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47470
Convert to Kotlin and formalize it being an internal class (some methods were already `protected` in Java)
Changelog:
[Android] [Breaking] - Stable API - Make SwipeRefreshLayoutManager internal
Reviewed By: cortinico
Differential Revision: D65481861
fbshipit-source-id: afc5c624373fbcd3ca2d28b2834d2682de672997
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47466
Now, when the useAlwaysAvailableJSErrorHandling feature flag is true, React Native will use the earlyjs c++ error reporting pipeline for handling all javascript errors!
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D64715159
fbshipit-source-id: 597a5278eb792f87dca10e06fa9816b3a8c47b84
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47475
Creates a feature flag to evalute the impact of disabling `InteractionManager` and replacing its scheduling behavior with `setImmediate`.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D65577455
fbshipit-source-id: c0dc2b4d062eff4929ef37c5e217fd194addd790
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47419
Minor improvements to `ImageExample` so we log when images fail to load. Also replaces a `Text` component with `RNTesterText` so it's legible.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D65363864
fbshipit-source-id: 6c7ce8d5af6aabfed21479c784911bdcffe4684e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47478
That's a reland of D65540601
The `UIManager.eventDispatcher` return type is wrong and is causing a breaking change in 0.77
For 0.76 we fixed it in the release branch but we should fix it for good in main as well.
To solve it I had to fix the circular dependency between .bridge and .uimanager.
I wish I could have isolated the .events package better but as everythign is public, any
change we do is going to be a breaking change so I'm being over cautios here.
Changelog:
[Android] [Fixed] - Undo breaking change of UiManager.eventDispatcher return type
Reviewed By: javache
Differential Revision: D65595391
fbshipit-source-id: fc7f6dce78e531c5ec0cc493ed90c0012262b77f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47461
As titled, is overwritten later in the file.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D65546370
fbshipit-source-id: 4ea71d24e429b7bbded3e7bb7c75015a2c9d95d8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47482
XCBeautify swallow some errors, especially all the linker errors when some symbol is not defined. The full error is not available in the raw log either.
This makes much harder to debug those issues when they happen.
We can remove xcbeautify for the time being, while we find a better solution.
## Changelog
[Internal] - Remove XCBeautify from ci
Reviewed By: dmytrorykun
Differential Revision: D65596745
fbshipit-source-id: 0550d4cbeadc5bec8acc61b5edc1320d3445bcaf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47481
The Codegenerated files has this option turned off.
This is causing Xcode to output hundreds of warnings due to missing nullability options. RThis fixes them.
## CHANGELOG
[Internal] - Set ASSUME_NONNULL regions in codegen'd files
Reviewed By: dmytrorykun
Differential Revision: D65596598
fbshipit-source-id: bbf664944e103c05ef593a7e07bf5b767445950c
Summary:
When running the commands to check the flow types locally, there is quite some noise from files under `packages/rn-tester/Pods` that should not be checked as they are not from the source code itself.
<img width="839" alt="Screenshot 2024-11-07 at 00 50 55" src="https://github.com/user-attachments/assets/7ad3d96d-0f4a-4772-9e37-34d7e593b4cf">
## Changelog:
[INTERNAL] [FIXED] - Excluding `packages/rn-tester/Pods/` from flow checks
Pull Request resolved: https://github.com/facebook/react-native/pull/47474
Test Plan:
```bash
yarn flow
```
Reviewed By: cortinico
Differential Revision: D65594400
Pulled By: cipolleschi
fbshipit-source-id: d5e8828f41fc87c9a95293c250f24673ebbc6cd4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47458
We are in a weird situation where React Native depends on some files that are generated by Codegen.
Codegen runs in the user project, so those dependencies are not available to React Native if we try to build it in isolation.
This is a problem and a blocker to prepare the prebuilds for iOS.
This image show the changes we are introducing:
On the right we have the current situation.
On the left the new one.
{F1954418630}
## Changelog:
[Internal] - Generate React Native specific code inside React Native
Reviewed By: cortinico, blakef
Differential Revision: D65541505
fbshipit-source-id: 1412d7f23c4d2230b795af41f1e832c8a70d5859
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47399
Deletes `unstable_setEnableSyncOnScroll` which we are no longer experirmenting with in React Native.
Changelog:
[Internal] - Deleted `unstable_setEnableSyncOnScroll` on `ScrollView`, which was never part of the React Native Public API.
Reviewed By: tdn120, sammy-SC
Differential Revision: D65449039
fbshipit-source-id: 6608d5ccca477f1da5e0168c4a342cce17014b08
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47354
`PointerValue::invalidate()` is called from `Pointer` destructor, which is implicitly `noexcept`, and from `Pointer` move-assignment operator, which is now `noexcept`.
Reviewed By: neildhar
Differential Revision: D65271399
fbshipit-source-id: 26fd9707e4389da78537d0d607adaef0c68690ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47463
Note this is just a temporary approach which will be cleaned up later.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D65514902
fbshipit-source-id: f722031c5cd34eb1400b3f732fd94c0b03d5434d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47376
This makes several classes inside `com.facebook.react.views.progressbar` internal:
- ReactProgressBarViewManager
- ProgressBarShadowNode
- ProgressBarContainerView
Those classes should have not been exposed in the first place and users should not depend on them directly.
Marked as Breaking but verified that there are no meaningful usages in OSS.
Changelog:
[Android] [Breaking] - Stable API - Make classes inside `com.facebook.react.views.progressbar` internal
Reviewed By: javache
Differential Revision: D65423290
fbshipit-source-id: dc98fdca996eb648593adb2c32787cbf0d878e3e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47473
For example,
```
declare function C<T>(ref: React.RefSetter<Set<T>>): React.Node;
type T = React.ElementRef<typeof C>
```
Previously Flow will evaluate `T` to `Set<mixed>`, by automatically replacing generic types with their upper bounds. But in the future it might be replaced with `empty`.
This diff cleans up instances like this in react-native codebase.
Changelog: [Internal]
Reviewed By: alexmckenley
Differential Revision: D65562571
fbshipit-source-id: bca2f4f022a5a23a5aa40886f5661899cb315f2e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47404
Changelog: [Internal]
introducing an internal API to reload without starting up the surfaces that were stopped at time of reload
Reviewed By: sammy-SC
Differential Revision: D65461606
fbshipit-source-id: 9e58bebdc3e03ead7f91376b7aaba5c7944bddcf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47472
using ViewManagerDelegates for ReactHorizontalScrollContainerViewManager which extends ReactClippingViewManager will introduce a bug (not updating props that are managed by ReactClippingViewManager)
I'm reverting the migration and we should fix the bug in codegen
This diff is a revert of D65428646
changelog: [internal] internal
Reviewed By: sammy-SC, Abbondanzo
Differential Revision: D65564730
fbshipit-source-id: ff183876321d4d36e51da8f38ff6f381207c7c3a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47465
When you do @(NO), in objc, it creates an NSNumber.
So this if condition actually evaluates to true:
```
if (@(NO))
```
This means that all soft errors will get logged as fatals on ios.
Changelog: [Internal]
Created from CodeHub with https://fburl.com/edit-in-codehub
Reviewed By: realsoelynn
Differential Revision: D65551648
fbshipit-source-id: 99b5bcb5fa1b0b5dc8055a3c86fc983863a25526
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47440
Removing file as it does not seem to be used
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D65457514
fbshipit-source-id: 39efa12176fe65a491fa4285099134f2bf753159
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47457
The `UIManager.eventDispatcher` return type is wrong and is causing a breaking change in 0.77
For 0.76 we fixed it in the release branch but we should fix it for good in main as well.
To solve it I had to fix the circular dependency between .bridge and .uimanager.
I wish I could have isolated the .events package better but as everythign is public, any
change we do is going to be a breaking change so I'm being over cautios here.
Changelog:
[Android] [Fixed] - Undo breaking change of UiManager.eventDispatcher return type
Reviewed By: tdn120
Differential Revision: D65540601
fbshipit-source-id: 4b1f62806baac5f6c3ffdd51b8628ef088447604
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47454
As far as I can tell, this module is now unused both within the codebase and externally. Delete to reduce our public API surface (deep module is an accessible import path).
Changelog:
[General][Breaking] - Remove ReactFabricInternals module
Reviewed By: cortinico
Differential Revision: D65535378
fbshipit-source-id: 25ee16ccc637815ffe1c69a5fc546bd3e11d1689
Summary:
I've doing some enhancements around the Image component for Android, and in the process of understanding the codebase I saw some opportunity to improve the test cases as there is no much coverage around the underlying functionality.
## Changelog:
[INTERNAL] [ADDED] - Improving Android Image property test cases
Pull Request resolved: https://github.com/facebook/react-native/pull/47433
Test Plan:
```bash
yarn test-android
```
Reviewed By: javache
Differential Revision: D65530813
Pulled By: cortinico
fbshipit-source-id: b314eaf7493c6f3c859b7cb0d06771c109e5e854
Summary:
I forgot to add some `\n` in the bot messages. This fixes it.
## Changelog:
[INTERNAL] - Add missing `\n` on actOnLabel.js
Pull Request resolved: https://github.com/facebook/react-native/pull/47451
Test Plan: N/A
Reviewed By: cipolleschi
Differential Revision: D65533495
Pulled By: cortinico
fbshipit-source-id: c2214d00800f6b70ec331a9ae72578414f50cd43
Summary:
Changelog:
[General][Added] Use the TypeScript key in syntax to restrict permissions and types of results
- Use key in 'GRANTED' | 'DENIED' | 'NEVER_ASK_AGAIN for RESULTS constants to ensure that only these values are allowed
- Use a detailed list of permission names for PERMISSIONS constants to restrict the type of key
Pull Request resolved: https://github.com/facebook/react-native/pull/47299
Reviewed By: yungsters
Differential Revision: D65480410
Pulled By: tdn120
fbshipit-source-id: ec23750d72ede0ba6ed96e80c35242da08b2508e
Summary:
When decoupling the community-cli-plugin from the react-native-community/cli-server-api (https://github.com/facebook/react-native/issues/45311), a middleware stub was created to allow a runtime stub to be used in this case. This middleware should be used so as not to break when the optional cli-server-api dependency isn't present.
Changelog:
[General][Fixed] - Fix npm react-native start when cli-server-api isn't installed
Pull Request resolved: https://github.com/facebook/react-native/pull/47450
Test Plan:
Forced a runtime exception simulating the package not being dependent and was able to build rn-tester.

Reviewed By: cipolleschi
Differential Revision: D65532486
Pulled By: blakef
fbshipit-source-id: 2b380607de63ac2da906ef0cb1e48b9ef263cb68
Summary:
In order to use a reusable workflow in GHA, we need first to checkout the repository so the action has access to the other workflows.
## Changelog:
[Internal] - Add checkout step to Check Nightlies
Pull Request resolved: https://github.com/facebook/react-native/pull/47448
Test Plan: GHA - https://github.com/facebook/react-native/actions/runs/11702038686?pr=47448
Reviewed By: cortinico
Differential Revision: D65532274
Pulled By: cipolleschi
fbshipit-source-id: 58117ac81973e3c07829d73d5bde4e6fd4d212f9
This directory was home to the Circle CI configuration files.
In July 2024 we moved to GitHub Actions, and week this folder for backward compatibility, as we want to keep on using Circle CI for the release of React Native <= 0.74.
* Please [search for similar issues](https://github.com/facebook/react-native/issues) in our issue tracker.
Make sure that your issue:
* Have a **valid reproducer** (either a [Expo Snack](https://snack.expo.dev/) or a [empty project from template](https://github.com/react-native-community/reproducer-react-native).
* Have a **valid reproducer** (See [How to report a bug](https://reactnative.dev/contributing/how-to-report-a-bug)).
* Is tested against the [**latest stable**](https://github.com/facebook/react-native/releases/) of React Native.
Due to the extreme number of bugs we receive, we will be looking **ONLY** into issues with a reproducer, and on [supported versions](https://github.com/reactwg/react-native-releases#which-versions-are-currently-supported) of React Native.
🚨 IMPORTANT: Due to the extreme number of bugs we receive, issues **without a reproducer** or for an [**unsupported versions**](https://github.com/reactwg/react-native-releases#which-versions-are-currently-supported) of React Native **will be closed**.
- type:textarea
id:description
attributes:
@@ -69,10 +69,10 @@ body:
- type:textarea
id:react-native-info
attributes:
label:Output of `npx react-native info`
description:Run `npx react-native info` in your terminal, copy and paste the results here.
label:Output of `npx @react-native-community/cli info`
description:Run `npx @react-native-community/cli info` in your terminal, copy and paste the results here.
placeholder:|
Paste the output of `npx react-native info` here. The output looks like:
Paste the output of `npx @react-native-community/cli info` here. The output looks like:
...
System:
OS: macOS 14.1.1
@@ -83,7 +83,7 @@ body:
path: /bin/zsh
Binaries:
Node: ...
version: 18.14.0
version: 22.14.0
...
render:text
validations:
@@ -109,8 +109,8 @@ body:
- type:input
id:reproducer
attributes:
label:Reproducer
description:A link to a Expo Snack or a public repository that reproduces this bug, using [this template](https://github.com/react-native-community/reproducer-react-native). Reproducers are **mandatory**.
label:MANDATORY Reproducer
description:A link to either a failing RNTesterPlayground.js file, an Expo Snack or a public repository from [this template](https://github.com/react-native-community/reproducer-react-native) that reproduces this bug. Reproducers are **mandatory**, issues without a reproducer will be closed.
Do not attempt to open a bug in this category if you're not using the New Architecture as your bug will be closed.
Make sure that your issue:
* Have a **valid reproducer** (either a [Expo Snack](https://snack.expo.dev/) or a [empty project from template](https://github.com/react-native-community/reproducer-react-native).
* Have a **valid reproducer** (See [How to report a bug](https://reactnative.dev/contributing/how-to-report-a-bug)).
* Is tested against the [**latest stable**](https://github.com/facebook/react-native/releases/) of React Native.
Due to the extreme number of bugs we receive, we will be looking **ONLY** into issues with a reproducer, and on [supported versions](https://github.com/reactwg/react-native-releases#which-versions-are-currently-supported) of React Native.
🚨 IMPORTANT: Due to the extreme number of bugs we receive, issues **without a reproducer** or for an [**unsupported versions**](https://github.com/reactwg/react-native-releases#which-versions-are-currently-supported) of React Native **will be closed**.
- type:textarea
id:description
attributes:
@@ -81,10 +81,10 @@ body:
- type:textarea
id:react-native-info
attributes:
label:Output of `npx react-native info`
description:Run `npx react-native info` in your terminal, copy and paste the results here.
label:Output of `npx @react-native-community/cli info`
description:Run `npx @react-native-community/cli info` in your terminal, copy and paste the results here.
placeholder:|
Paste the output of `npx react-native info` here. The output looks like:
Paste the output of `npx @react-native-community/cli info` here. The output looks like:
...
System:
OS: macOS 14.1.1
@@ -95,7 +95,7 @@ body:
path: /bin/zsh
Binaries:
Node: ...
version: 18.14.0
version: 22.14.0
...
render:text
validations:
@@ -121,8 +121,8 @@ body:
- type:input
id:reproducer
attributes:
label:Reproducer
description:A link to a Expo Snack or a public repository that reproduces this bug, using [this template](https://github.com/react-native-community/reproducer-react-native). Reproducers are **mandatory**.
label:MANDATORY Reproducer
description:A link to either a failing RNTesterPlayground.js file, an Expo Snack or a public repository from [this template](https://github.com/react-native-community/reproducer-react-native) that reproduces this bug. Reproducers are **mandatory**, issues without a reproducer will be closed.
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"
* Copyright (c) Meta Platforms, Inc. and affiliates.
*
* This source code is licensed under the MIT license found in the
* LICENSE file in the root directory of this source tree.
*
* @format
*/
'use strict';
const{
prepareFailurePayload,
sendMessageToDiscord,
}=require('../notifyDiscord');
describe('prepareFailurePayload',()=>{
it('should handle undefined failures',()=>{
constmessage=prepareFailurePayload(undefined);
expect(message).toEqual({
content:
'⚠️ **React Native Nightly Integration Failures** ⚠️\n\nNo failures to report.',
});
});
it('should handle empty failures array',()=>{
constmessage=prepareFailurePayload([]);
expect(message).toEqual({
content:
'⚠️ **React Native Nightly Integration Failures** ⚠️\n\nNo failures to report.',
});
});
it('should format a single failure correctly',()=>{
constfailures=[
{
library:'react-native-reanimated',
platform:'iOS',
},
];
constmessage=prepareFailurePayload(failures);
expect(message).toEqual({
content:
'⚠️ **React Native Nightly Integration Failures** ⚠️\n\nThe integration of libraries with React Native nightly failed for the following libraries:\n\n❌ [iOS] react-native-reanimated',
});
});
it('should sort multiple failures by platform and library name',()=>{
constfailures=[
{
library:'react-native-reanimated',
platform:'iOS',
},
{
library:'react-native-gesture-handler',
platform:'Android',
},
{
library:'react-native-screens',
platform:'iOS',
},
{
library:'react-native-svg',
platform:'Android',
},
];
constmessage=prepareFailurePayload(failures);
// The failures should be sorted: first Android (alphabetically), then iOS
// Within each platform, libraries should be sorted alphabetically
expect(message).toEqual({
content:
'⚠️ **React Native Nightly Integration Failures** ⚠️\n\nThe integration of libraries with React Native nightly failed for the following libraries:\n\n❌ [Android] react-native-gesture-handler\n❌ [Android] react-native-svg\n❌ [iOS] react-native-reanimated\n❌ [iOS] react-native-screens',
});
});
it('should handle failures with missing properties',()=>{
constfailures=[
{
// Missing library
platform:'iOS',
},
{
library:'react-native-gesture-handler',
// Missing platform
},
{
// Both missing
},
];
constmessage=prepareFailurePayload(failures);
expect(message).toEqual({
content:
'⚠️ **React Native Nightly Integration Failures** ⚠️\n\nThe integration of libraries with React Native nightly failed for the following libraries:\n\n❌ [iOS] Unknown\n❌ [Unknown] react-native-gesture-handler\n❌ [Unknown] Unknown',
`> **Invalid issue**: This issue is not valid, either is not a bug in React Native, it doesn't match any of the issue template, or we can't help further with this.`,
);
awaitcloseIssue();
return;
case'Type: Question':
awaitaddComment(
`> [!NOTE]`+
`> [!NOTE]\n`+
`> **Not a bug report**: This issue looks like a question. We are using GitHub issues exclusively to track bugs in React Native. GitHub may not be the ideal place to ask a question, but you can try asking over on [Stack Overflow](http://stackoverflow.com/questions/tagged/react-native), or on [Reactiflux](https://www.reactiflux.com/).`,
);
awaitcloseIssue();
return;
case'Resolution: For Stack Overflow':
awaitaddComment(
`> [!NOTE]`+
`> [!NOTE]\n`+
`> **Not a bug report**: This issue looks like a question. We are using GitHub issues exclusively to track bugs in React Native. GitHub may not be the ideal place to ask a question, but you can try asking over on [Stack Overflow](http://stackoverflow.com/questions/tagged/react-native), or on [Reactiflux](https://www.reactiflux.com/).`,
);
awaitcloseIssue();
return;
case'Type: Docs':
awaitaddComment(
`> [!NOTE]`+
`> [!NOTE]\n`+
`> **Docs issue**: This issue looks like an issue related to our docs. Please report documentation issues in the [react-native-website](https://github.com/facebook/react-native-website/issues) repository.`,
);
awaitcloseIssue();
return;
case'Type: Expo':
awaitaddComment(
`> [!NOTE]`+
`> [!NOTE]\n`+
`> **Expo related**: It looks like your issue is related to Expo and not React Native core. Please open your issue in [Expo's repository](https://github.com/expo/expo/issues/new). If you are able to create a repro that showcases that this issue is also happening in React Native vanilla, we will be happy to re-open.`,
);
awaitcloseIssue();
return;
case'Needs: Issue Template':
awaitaddComment(
`> [!WARNING]`+
`> [!WARNING]\n`+
`> **Missing issue template**: It looks like your issue may be missing some necessary information. GitHub provides an example template whenever a [new issue is created](https://github.com/facebook/react-native/issues/new?assignees=&labels=Needs%3A+Triage+%3Amag%3A&projects=&template=bug_report.yml). Could you go back and make sure to fill out the template? You may edit this issue, or close it and open a new one.`,
);
awaitrequestAuthorFeedback();
return;
case'Needs: Environment Info':
awaitaddComment(
`> [!WARNING]`+
`> [!WARNING]\n`+
`> **Missing info**: It looks like your issue may be missing information about your development environment. You can obtain the missing information by running <code>react-native info</code> in a console.`,
);
awaitrequestAuthorFeedback();
return;
case'Newer Patch Available':
awaitaddComment(
`> [!TIP]`+
`> **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.`,
);
return;
case'Needs: Version Info':
awaitaddComment(
`> [!WARNING]`+
`> [!WARNING]\n`+
`> **Could not parse version**: We could not find or parse the version number of React Native in your issue report. Please use the template, and report your version including major, minor, and patch numbers - e.g. 0.76.2.`,
);
awaitrequestAuthorFeedback();
return;
case'Needs: Repro':
awaitaddComment(
`> [!WARNING]`+
`> **Missing reproducer**: We could not detect a reproducible example in your issue report. Please provide either: <br/><ul><li>If your bug is UI related: a [Snack](https://snack.expo.dev)</li><li> If your bug is build/upgrade related: a project using our [Reproducer Template](https://github.com/react-native-community/reproducer-react-native/generate)</li><li>Otherwise send us a Pull Request with the [RNTesterPlayground.js](https://github.com/facebook/react-native/blob/main/packages/rn-tester/js/examples/Playground/RNTesterPlayground.js) edited toreproduce your bug.</li></ul>`,
`> [!WARNING]\n`+
`> **Missing reproducer**: We could not detect a reproducible example in your issue report. Reproducers are **mandatory** and we can accept only one of those as a valid reproducer: <br/><ul><li>For majority of bugs: send us a Pull Request with the [RNTesterPlayground.js](https://github.com/facebook/react-native/blob/main/packages/rn-tester/js/examples/Playground/RNTesterPlayground.js) edited to reproduce your bug.</li><li>If your bug is UI related: a [Snack](https://snack.expo.dev)</li><li> If your bug is build/upgrade related: a project using our [Reproducer Template](https://github.com/react-native-community/reproducer-react-native/generate)</li></ul><br/>You can read more about about it on our website: [How to report a bug](https://reactnative.dev/contributing/how-to-report-a-bug).`,
);
awaitrequestAuthorFeedback();
return;
case'Type: Unsupported Version':
awaitaddComment(
`> [!WARNING]`+
`> [!WARNING]\n`+
`> **Unsupported version**: It looks like your issue or the example you provided uses an [unsupported version of React Native](https://github.com/reactwg/react-native-releases/blob/main/docs/support.md).<br/><br/>Due to the number of issues we receive, we're currently only accepting new issues against one of the supported versions. Please [upgrade](https://reactnative.dev/docs/upgrading) to latest and verify if the issue persists (alternatively, create a new project and repro the issue in it). If you cannot upgrade, please open your issue on [StackOverflow](https://stackoverflow.com/questions/tagged/react-native) to get further community support.`,
);
awaitrequestAuthorFeedback();
return;
case'Type: Too Old Version':
awaitaddComment(
`> [!CAUTION]`+
`> [!CAUTION]\n`+
`> **Too old version**: It looks like your issue or the example you provided uses a [**Too Old Version of React Native**](https://github.com/reactwg/react-native-releases/blob/main/docs/support.md).<br/><br/>Due to the number of issues we receive, we're currently only accepting new issues against one of the supported versions. Please [upgrade](https://reactnative.dev/docs/upgrading) to latest and verify if the issue persists (alternatively, create a new project and repro the issue in it). If you cannot upgrade, please open your issue on [StackOverflow](https://stackoverflow.com/questions/tagged/react-native) to get further community support.`,
console.log('Successfully sent message to Discord');
return;
}else{
consterrorText=awaitresponse.text();
console.error(
`Failed to send message to Discord: ${response.status}${errorText}`,
);
thrownewError(`HTTP status code: ${response.status}`);
}
}
/**
* Prepares a formatted Discord message payload from a list of failures.
* @param {Array<Object>} failures - List of failures to format
* @returns {Object} - The formatted Discord message payload
*/
functionprepareFailurePayload(failures){
if(!failures||failures.length===0){
return{
content:
'⚠️ **React Native Nightly Integration Failures** ⚠️\n\nNo failures to report.',
};
}
// Sort failures by platform and then by library name
constsortedFailures=[...failures].sort((a,b)=>{
// First sort by platform
constplatformA=a.platform||'Unknown';
constplatformB=b.platform||'Unknown';
if(platformA!==platformB){
returnplatformA.localeCompare(platformB);
}
// Then sort by library name
constlibraryA=a.library||'Unknown';
constlibraryB=b.library||'Unknown';
returnlibraryA.localeCompare(libraryB);
});
// Format the failures into a message
constformattedFailures=sortedFailures
.map(failure=>{
constlibrary=failure.library||'Unknown';
constplatform=failure.platform||'Unknown';
return`❌ [${platform}] ${library}`;
})
.join('\n');
return{
content:`⚠️ **React Native Nightly Integration Failures** ⚠️\n\nThe integration of libraries with React Native nightly failed for the following libraries:\n\n${formattedFailures}`,
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]# prepare_hermes_workspace must be there because we need its reference to retrieve a couple of outputs
runs-on:macos-14
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]# prepare_hermes_workspace must be there because we need its reference to retrieve a couple of outputs
runs-on:macos-14
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/)
@@ -67,7 +64,7 @@ React Native is developed and supported by many companies and individual core co
## 📋 Requirements
React Native apps may target iOS 13.4 and Android 6.0 (API 23) or newer. You may use Windows, macOS, or Linux as your development operating system, though building and running iOS apps is limited to macOS. Tools like [Expo](https://expo.dev) can be used to work around this.
React Native apps may target iOS 15.1 and Android 7.0 (API 24) or newer. You may use Windows, macOS, or Linux as your development operating system, though building and running iOS apps is limited to macOS. Tools like [Expo](https://expo.dev) can be used to work around this.
## 🎉 Building your first React Native app
@@ -87,7 +84,7 @@ The full documentation for React Native can be found on our [website][docs].
The React Native documentation discusses components, APIs, and topics that are specific to React Native. For further documentation on the React API that is shared between React Native and React DOM, refer to the [React documentation][r-docs].
The source for the React Native documentation and website is hosted on a separate repo, [**@facebook/react-native-website**][repo-website].
The source for the React Native documentation and website is hosted on a separate repository, [**@facebook/react-native-website**][repo-website].
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.