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/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
Vitali Zaidman
Nick Lefever
Samuel Susla
Rubén Norte
Ritesh Shukla
meg
Nick Gerleman
Joe Vilches
Tomasz Zawadzki
Vincent Riemer
Ruslan Shestopalyuk
Nicola Corti
Mateo Guzmán
Tim Yung
HyunWoo Lee
Mofei Zhang
Fabrizio Cucci
Ruslan Lesiutin
Mohamed Salama
Pieter De Baets
Evan Bacon
Jakub Piasecki