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