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
Christian Falch
Wojciech Lewicki
Tomek Zawadzki
Luna Wei
Tim Yung
Nick Gerleman
Peter Abbondanzo
David Vacca
Nick Lefever
Panos Vekris
Alex Hunt
Ruslan Lesiutin
Riccardo Cipolleschi
Zeya Peng
louix
Oskar Kwaśniewski
Andrew Coates
Ruslan Shestopalyuk
Phil Pluckthun
Dawid Małecki
generatedunixname89002005232357
Yannick Loriot
Jiawei Lü