Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49855
Changelog: [IOS][FIXED] - Fixed touch events not being dispatched to ScrollView's children when they overflow the content container
Closes https://github.com/facebook/react-native/issues/47740.
Changes the ScrollView's container view to be `RCTViewComponentView` instead of `UIView` and sets custom layout metrics to it in a way that it will propagate touch events to all children, even if they overflow its bounds.
Reviewed By: sammy-SC
Differential Revision: D70619894
fbshipit-source-id: 348a1a369489d5208d6037c8d76b223c4ab2d5f7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49582
TSIA, this is a fairly straightforward implementation since iOS likes the shape the data is already in. Note I form a stacking context since I need the native view that has `accessibilityElements` to actually be an ancestor of everything under it
Note I am not exposing anything yet on the JS side, since we need to do Android also
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D69625269
fbshipit-source-id: 836f1bb631646408a5726f126be61c0ff6afe1d0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49960
Fixes https://github.com/facebook/react-native/issues/49106
RN legacy arch, and web, will clip inline content which appears after elipsized text. This is the correct behavior, compared to new arch, which will put it in a random place depending on the platform.
`line-clamp`: https://jsfiddle.net/7xgdke1b/
`text-overflow`: https://jsfiddle.net/7xgdke1b/2/
Fabric renderer does not, funnily enough, having an `isClipped` field on `TextMeasurement::Attachment` that is never used.
This change propagates state for whether an attachment is beyond elipsized area to this measurement, then when we see it, we set empty layout results with `DisplayType::None` so that we don't create native views. We don't layout child views either, but this seems to work out okay, even when removing and re-adding `numberOfLines`.
Changelog:
[General][Fixed] - Fix New Arch handling of inline views when text truncated
Reviewed By: mdvacca
Differential Revision: D70922174
fbshipit-source-id: 8c1f4aadbf53ff64ce55b44d6c7953d9b2e40bc5
Summary:
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.
Changelog: [Android][Fixed] - Fix keyboard navigation on lists with `removeClippedSubviews` enabled
Reviewed By: joevilches
Differential Revision: D69618406
fbshipit-source-id: 1df7f90066dfc685e74a89b29222937777714b87
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49961
As preparation for fixing focus on FlatList we need to prevent the currently focused view from getting clipped. This is because in Android, if the currently focused view gets clipped before transferring focus we crash.
Changelog: [Android][Changed] - Prevent currently focused child from getting clipped when `removeClippedSubviews` is enabled
Reviewed By: NickGerleman
Differential Revision: D70994348
fbshipit-source-id: 8c68eeebd7df8e7d8f788e50a3bbe46b0335ace3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49951
We previously fixed Differentiator generating an incorrect parentTag (https://github.com/facebook/react-native/pull/48055), but this can lead to crashes in Android UI due to reordering that happens in the Android mounting layer. While we have an experiment to disable this reordering (https://github.com/facebook/react-native/pull/46702) this currently has a negative performance impact which needs to be addressed.
As a mitigation, we can make the lookup of parentTag's ViewManager state nullable. We only require this to support `needsCustomLayoutForChildren`, which is not commonly used, and seems acceptable to drop in this scenario.
Changelog: [Android][Changed] Do not crash when parent view state can't be found
Reviewed By: NickGerleman
Differential Revision: D70966621
fbshipit-source-id: 33d0b6a90860788a4c9a8c6cea36c2c72c1392e1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49937
Adding an assert for recycled views still attached to their parent, which would lead to an exception when the view would be added to a new parent.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D70922503
fbshipit-source-id: 7d4daf427306203d603c31999ab138b3aee08e83
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49954
We have a different version of OkHttp internally and in OSS so we need to suppress these for now.
Changelog: [Internal]
Reviewed By: Abbondanzo
Differential Revision: D70975145
fbshipit-source-id: cd2a3ab5cdc52f25c78cb608e917fa3ca378e4f1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49817
changelog: [internal]
Remove feature flag excludeYogaFromRawProps. It did not yield any performance wins and the code to support the feature is spread across multiple classes. Removal simplifies complexity.
Reviewed By: javache
Differential Revision: D70389071
fbshipit-source-id: 21751f56aec8de501ff1e1efafda035069d8ef48
Summary:
Migrate com.facebook.react.uimanager.layoutanimation.OpacityAnimation to Kotlin.
I moved out `OpacityAnimationListener` as well in this PR to separate concerns and align more with the codebase.
## Changelog:
[INTERNAL] - Migrate com.facebook.react.uimanager.layoutanimation.OpacityAnimation to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/49822
Test Plan:
```bash
yarn test-android
yarn android
```
Reviewed By: javache
Differential Revision: D70588884
Pulled By: alanleedev
fbshipit-source-id: 1b70f5e5facd5f47b828090e7c63a218229000cb
Summary:
When using the `login-password` prompt type, there is a TypeScript type mismatch issue. The `callbackOrButtons` parameter returns an object with `{login: string, password: string}` structure, but this type variation is not properly included in the **AlertType** type definition. This causes TypeScript to show type errors when using callback functions that expect credentials in the format `(credentials: {login: string, password: string}) => void`.
## Changelog:
- [General] [Fixed] Add missing type variation `{login: string, password: string}` to **AlertType** type definition to properly support `login-password` prompt callbacks
Pull Request resolved: https://github.com/facebook/react-native/pull/49757
Test Plan: This change is purely type-related and doesn't affect runtime behavior.
Reviewed By: NickGerleman
Differential Revision: D70797036
Pulled By: alanleedev
fbshipit-source-id: 8e27a39f0c8f49083730c683b41b69173715bd68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49927
This change automates updating App's Info.plist with the new `RCTNewArchEnabled` boolean entry. The value depends on how the pod install is set up. In this way, we maintain the previous UX to enable/disable the New Arch.
## Context
The RCT_NEW_ARCH_ENABLE flag is a compile time flag we used for almost two years to configure the iOS apps and to determine whether the app should build with the New Arch or not.
However, given that we are looking into prebuilding React Native, we have to get rid of all the compilation flags, because they would require us to prebuild a combinatorial number of artifacts for react native. For example:
- New Arch / Hermes
- Old Arch / Hermes
- New Arch / JSC
- Old Arch / JSC
- ...
## Backward compatibility
We are going to keep adding the RCT_NEW_ARCH_ENABLED flag in all the dependencies, through the cocoapods inrastructure, so libraries, which are not prebuilt, will be build for the right architecture by the app itself.
## Changelog:
[iOS][Added] -
Reviewed By: cortinico
Differential Revision: D70888212
fbshipit-source-id: 541a818e02ccb96c822de29b0714646d1e69a5a9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49924
This change deprecates the RCT_NEW_ARCH_ENABLEd flag to toggle the New Architecture.
The new approach bring iOS closer to Android: to diasable the New Architecture, user needs to modify the App's Info.plist and add a `RCTNewArchEnabled` boolean entry and set it to `NO`.
The absence of the entry implies that the New Arch is enabled. (Defaults to enabled)
This also deprecates the `RCTSetNewArchEnabled` function because it makes no sense now
## Context
The RCT_NEW_ARCH_ENABLE flag is a compile time flag we used for almost two years to configure the iOS apps and to determine whether the app should build with the New Arch or not.
However, given that we are looking into prebuilding React Native, we have to get rid of all the compilation flags, because they would require us to prebuild a combinatorial number of artifacts for react native. For example:
- New Arch / Hermes
- Old Arch / Hermes
- New Arch / JSC
- Old Arch / JSC
- ...
## Backward compatibility
We are going to keep adding the RCT_NEW_ARCH_ENABLED flag in all the dependencies, through the cocoapods inrastructure, so libraries, which are not prebuilt, will be build for the right architecture by the app itself.
## Changelog:
[iOS][Deprecated] - deprecate the `RCT_NEW_ARCH_ENABLED` and the `RCTSetNewArchEnabled`
Reviewed By: cortinico
Differential Revision: D70885454
fbshipit-source-id: 4b8404ead4900d9787049ebd0b8b3c29b272f913
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49936
Ensure LegacyArchitectureLogger.assertWhenLegacyArchitectureMinifyingEnabled is called only once per class loading in kotlin
changelog: [internal] internal
Reviewed By: alanleedev
Differential Revision: D70922132
fbshipit-source-id: ce4d68dc2ab0f61266e4bb5cddfc175c364f568a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49938
Recycling a `ReactViewGroup` will lead to all child views being removed from the view. To avoid having view recycling corrupt the clipping state set for the child views, ahead of base view recycling preparation this diff disables `removeClippedSubviews` so that layout changes don't run over all child views that will end up being removed anyway.
The bug reported earlier should already have been resolved by D70672120 since the view recycling of a child view would remove the view from the parent. Meaning the ReactViewGroup can only have subviews that are not prepared for recycling, any recycled view would have been removed from their parent (the ReactViewGroup)
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D70921641
fbshipit-source-id: a8b311169b268c09400d2b62008184e379f6fe79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49934
The typing of internal version of jest and the libdef in react-native has diverged a bit. This diff aligns the typing for `describe`
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D70917375
fbshipit-source-id: 9c2ab98a08394aa187712f4966748a8a60e202b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49900
This appears to fix an issue where removing a sibling with zIndex breaks drawing of the next sibling. The theory is that eager return in `onViewRemoved` prevents the view from reverting into a state where it no longer uses custom draw order. However, tracing back history, this eager return was [added](https://github.com/facebook/react-native/pull/43389) to fix a bug in Reanimated. cc bartlomiejbloniarz to confirm if [this Reanimated issue](https://github.com/software-mansion/react-native-reanimated/issues/5715) resurfaces from this change.
Fixes#49838
## Changelog
[Android][Fixed] Fixes issue with z-indexed sibling removal
Reviewed By: NickGerleman, cipolleschi
Differential Revision: D70795631
fbshipit-source-id: 500af92226be29af73f36f911ffff27a0c083ae9
Summary:
Currently, when integrating into a native app using ReactNativeFactory, when we forget to set `dependencyProvider` we get a random crash exception instructing us (depending on native modules in our app) about an unrecognized selector:

After this change we get a proper error informing us that we for got to set dependencyProvider:

## Changelog:
[IOS] [ADDED] - Useful error message about setting dependency provider
Pull Request resolved: https://github.com/facebook/react-native/pull/49843
Test Plan: CI Green
Reviewed By: cortinico
Differential Revision: D70631515
Pulled By: cipolleschi
fbshipit-source-id: d99c8fa12fdb0624a01fe16c50fe0f2d10554f94
Summary:
Migrate com.facebook.react.bridge JavaScriptContextHolder & JavaScriptExecutor to Kotlin.
In this PR I also marked the return of HermesExecutor.initHybridDefaultConfig as non-nullable to keep the conversion without logic changes. I checked that this was changed unintentionally to nullable in 12e321daf0 but I think it was not supposed to be.
## Changelog:
[INTERNAL] - Migrate com.facebook.react.bridge JavaScriptContextHolder & JavaScriptExecutor to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/49909
Test Plan:
```bash
yarn test-android
yarn android
```
Reviewed By: javache
Differential Revision: D70871012
Pulled By: Abbondanzo
fbshipit-source-id: 1c15927056baf166e520e896e92bebf664fa0229
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49931
This change fixes the app startup in the Old Architecture by implementing the loadSourceForBridge:onProgress:onComplete method in the RCTDefaultReactNativeFactoryDelegate object.
The method was missing here, so the Bridge was never trying to load the JS bundle from Metro, resulting in an empty app.
## Changelog:
[iOS][Fixed] - Implement the loadSourceForBridge:onProgress:onComplete in the RCTDefaultReactNativeFactoryDelegate.
Reviewed By: cortinico
Differential Revision: D70898811
fbshipit-source-id: 3e5d519a1965e92ace91ca6d5b316a9069279448
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49906
Task.call is equivalent to a try-catch and wrapping the result in a Task. Inlining this is cheaper than creating a TaskCompletionSource and a Runnable.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D70803554
fbshipit-source-id: 0886176be974eff67c983ce1475ad685a8021b14
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49926
Those files can be fully removed as it's not referenced at all in OSS/Internal
Changelog:
[Internal] [Changed] -
Reviewed By: fabriziocucci
Differential Revision: D70888664
fbshipit-source-id: 4cacc449aa141e0465f771bf8c52d573d4227ef5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49922
Spamming the DB with "heartbeat" events with close to 0 ping didn't give us any useful information. Instead, report high ping situations.
Changelog:
[General][Internal] Remove reporting all device and debugger heartbeat events, only report heartbeats with high round trip latency
Reviewed By: GijsWeterings
Differential Revision: D70707457
fbshipit-source-id: 6bc8a55fd32dfa60fb4f7764ac00a6218417dcb5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49907
These tests have been disabled for a while due to feature flags being introduced, fusebox flags with native dependencies, and the removal of Powermock.
Changelog: [Internal]
Reviewed By: Abbondanzo
Differential Revision: D70803553
fbshipit-source-id: d1ae6e4ca6c0d22e6a8c89bf01b28333929fa8a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49912
Changelog: [internal]
This migrates all Fantom tests to use package-relative imports from `react-native` instead of relative paths.
Note that a lot of the current deep imports (e.g.: `import ReactNativeElement from 'react-native/src/private/webapis/dom/nodes/ReactNativeElement'`) will not be necessary when we release those APIs as public.
Reviewed By: sammy-SC
Differential Revision: D70779722
fbshipit-source-id: f0d28e00ca9881dc2a3cd151b75327b26711277e
Summary:
- Update ignore micromatch pattern to filter out `__test_fixtures__` from build output
- Remove `babel/plugin-transform-object-rest-spread`
- Remove `babel/plugin-transform-async-to-generator`
- Remove `babel/plugin-transform-destructuring`
The `package.json:engines:node` field is already set to `>=18` which makes the three Babel transforms that were removed redundant.
## Changelog:
[INTERNAL] [CHANGED] - Remove fixtures files and outdated Babel transforms from `react-native/codegen` build output
Pull Request resolved: https://github.com/facebook/react-native/pull/49916
Test Plan: - Ran against Node 18
Reviewed By: robhogan
Differential Revision: D70885090
Pulled By: cortinico
fbshipit-source-id: 328b75a6031a7ca6a9b3ed170061ffb0a47d6d93
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49898
Changelog: [internal]
In the method to access the native node reference from elements, we weren't considering the case where the element is the `documentElement`, which is a special case we were handling correctly in the case of native node references from nodes (where we also handle it possibly being a document node).
Because of this, methods in `Element` and `ReactNativeElement` weren't working correctly on the `documentElement`. We didn't catch this initially because we only tested the traversal methods defined in node in the test for `ReactNativeDocument`.
This fixes the issue.
Reviewed By: javache
Differential Revision: D70792748
fbshipit-source-id: c42d05a066efaffccade94e9d3835fb7172e2335
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49896
This change makes possible to opt-out from the New Architecture.
Env variables are always `string`s in ruby and the check was always failing because it was comparing it with a number (always false)
## Changelog:
[iOS][Fixed] - enable back the opt-out from the New Architecture
Reviewed By: cortinico
Differential Revision: D70789827
fbshipit-source-id: 7d3f96c3db22f2715dec2b649534b20e3273ea3e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49860
changelog: [internal]
now that Fantom supports tests with <Modal />, add a test to cover scenario where <ScrollView /> is inside of <Modal />.
Reviewed By: rubennorte, rshest
Differential Revision: D70696834
fbshipit-source-id: 5f51917ac5c6a2cf451906e302ee2b62c15449ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49859
changelog: [internal]
this will be used for testing purposes in Fantom.
This diff also cleans up `ModalInjection.js` which is unused.
Reviewed By: rubennorte
Differential Revision: D69883384
fbshipit-source-id: 4ff278ef174c95fd5a93f70519f14c5190a5ada5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49885
Updates all `metro*` dependencies to the latest `^0.82.0`.
The breaking changes in this release apply only to frameworks and integrators.
This update brings `package.json#exports` resolution enabled by default, and lazy hashing for much faster Metro startup.
Release notes:
https://github.com/facebook/metro/releases/tag/v0.82.0
Changelog:
[General][Changed] Update Metro to ^0.82.0
Reviewed By: vzaidman
Differential Revision: D70778791
fbshipit-source-id: ffb55ed384d721205aa4d7f528c63c0b0a38abc5
Summary:
acquireWakeLockNow was static before but wasn't marked as static in https://github.com/facebook/react-native/commit/9afad527b831ec0c5d50e88daacbaacbc476d478 when changing code to Kotlin.
This breaks react-native-firebase but I've submitted the bug report there as I guess it might be fixed there too.
## Changelog:
[ANDROID] [FIXED] - Marked acquireWakeLockNow as static
Pull Request resolved: https://github.com/facebook/react-native/pull/49875
Test Plan: No tests as it reverts the broken change
Reviewed By: rshest
Differential Revision: D70773675
Pulled By: javache
fbshipit-source-id: d7363702dfec078b7e6d2693d05b8ab87e818522