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
Nick Lefever
Jorge Cabiedes Acosta
David Vacca
Peter Abbondanzo
Riccardo Cipolleschi
Pieter De Baets
Iwo Plaza
bornkiss
Mateo Guzmán
Samuel Susla
Vitali Zaidman
Jorge Cabiedes Acosta
Erich Graham
Sim Sun
Nicola Corti
Alex Hunt
JatinDream11
Alan Lee
Joe Vilches
Anupriya Verma