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
Jorge Cabiedes Acosta
Samuel Susla
Nicola Corti
Alex Hunt
Mateo Guzmán
Pieter De Baets
JatinDream11
Alan Lee
Joe Vilches
David Vacca
Anupriya Verma
Ramanpreet Nara
Phillip Pan
George Zahariev
David Richey
Nick Gerleman
Tim Yung
Jakub Piasecki
nishan (o^▽^o)
Mohd. Yasir Ansari
generatedunixname89002005287564
Gijs Weterings