Summary:
After unobserve is called, the shadow node actually isn't deleted from the `targetToShadowNode` WeakMap. So, if the element is kept around, the shadow node will leak.
We suspect this doesn't happen in practice. But, still it's good to just do this cleanup, just in case.
Changelog: [General][Fixed] Fix potential leak inside IntersectionObserver
Reviewed By: lunaleaps, yungsters
Differential Revision: D74361644
fbshipit-source-id: 1a5ccce1486aa200fc7318c689bfa887f713c284
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51148
Intersection observer should not be holding on to shadow nodes.
This diff migrates the javascript infra to instead use families.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74262804
fbshipit-source-id: cc090be54f7312ce32b853ddf86567bb43e676b8
Summary:
IntersectionObserverManager now uses families to manage IntersectionObservers.
This diff just migrates its apis to family too.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D74263375
fbshipit-source-id: d2e5fda327dfc75f0f711932626643d49cb3322f
Summary:
X-link: https://github.com/facebook/yoga/pull/1809
Pull Request resolved: https://github.com/facebook/react-native/pull/51181
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: rshest
Differential Revision: D74292949
fbshipit-source-id: 05011c66a9a9480544313eb1dfe2c46bf7742bac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51183
D58818560 tried to deduplicate some code, but introduced an error, where we no longer correctly incorporate the width MeasureMode into the text layout that we create, instead, passing `YogaMeasureMode.EXACTLY`.
In effect, this means the Android layout created always takes up the maximum allowable space, even if content is smaller. This is later masked, because our returned measure when `AT_MOST` is based on maximum line length, and the layout is then recreated when drawing a TextView, but means:
1. Attachments may not be positioned correctly, when using a non-left-aligned paragraph alignment
2. Directly drawing the layout shows the wrong thing
Changelog:
[Android][Fixed] - Fix TextLayoutManager MeasureMode Regression
Reviewed By: rshest
Differential Revision: D74366936
fbshipit-source-id: 3eda8c716ba9790a61c2da19023e140afbb6971d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51180
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: rshest
Differential Revision: D74291373
fbshipit-source-id: 44166f2e47323384cb00f3cf4c32f398e298a63e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51195
This change adds a script that prepares the repository by creating hard links to the header files in the `.build` folder that is also gitignored
## Changelog:
[Internal] - Add sdcript to setup the repository so that we can build it properly.
Test Plan:
run:
```
node packages/react-native/scripts/ios-prebuilds.js
```
observe the folder `.build` being created with all the files.
Reviewed By: cortinico
Differential Revision: D74393116
Pulled By: cipolleschi
fbshipit-source-id: 4951e61b49db83fbebbcc265ae025f53185fec81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51194
This change adds an utils script to set up folders when needed.
## Changelog:
[INTERNAL] - Add utils script
Test Plan: This is tested in the next diff of the stack.
Reviewed By: cortinico
Differential Revision: D74393298
Pulled By: cipolleschi
fbshipit-source-id: db3db61ec938d2ebe5c0bf5ae0a42aa20c673bb0
Summary:
- Added multiple targets to Package.swift
- WIP: Builds up untill we need to touch files in React/Base
## Changelog:
[INTERNAL] - WIP: prebuilding using Swift packages
Pull Request resolved: https://github.com/facebook/react-native/pull/50766
Test Plan: This will be tested in a diff in the stack.
Reviewed By: cortinico
Differential Revision: D74386522
Pulled By: cipolleschi
fbshipit-source-id: 7bac3c21a362c4ef79d0104727cdd3494419012f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51174
Allows the start and end of the scrollview to be faded to different values independently by passing an object containing a "start" and "end" value to the fadingEdgeLength prop.
To support non-uniform edge lengths we use the [FadingEdgeStrength](https://developer.android.com/reference/android/view/View#getTopFadingEdgeStrength()) api to set different values for the start/end of the scrollview. The FadingEdgeStrength value is multiplied by the FadingEdgeLength value [internally by Android when drawing the view.](https://cs.android.com/android/platform/superproject/+/android15-qpr1-release:frameworks/base/core/java/android/view/View.java;l=25007)
Because the value of FadingEdgeStrength is required to be between 0 and 1, we set setFadingEdgeLength to the max value and set the smaller side as a percentage of that value.
Changelog: [Android][Added] Allow fadingEdgeLength to be set independently on the start and end of the scrollview
Reviewed By: martinbooth
Differential Revision: D74222606
fbshipit-source-id: 7010ca803cc48450ab98c2a457fdc72ff47c29d7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51167
Adding the ScrollView properties that are android specific to the common ScrollView props so that they can be diffed in a getDiffProps implementation.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D74327335
fbshipit-source-id: 8e5683d4bf7fe0f6d54d4b97f535731721c60292
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51192
The `build-types` script cannot currently resolve `react-native/assets-registry` and `react-native/js-polyfills`. This diff moves imported types from these packages to `react-native` to include them in generated types.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D74392568
fbshipit-source-id: cbce977b710f54dc53ce1b0fc080704b420490d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51096
**Problem:** `Activity.onBackPressed()` has been deprecated and with targetSdk 36, predictive back will be enforced and the API no longer called. We need to migrate to backward compatible AndroidX `OnBackPressedCallback`.
- https://developer.android.com/about/versions/16/behavior-changes-16#predictive-back.
**Solution:**
`OnBackPressedCallback` is registered conditionally only if it is `targetSdk` 36 or greater.
If the callback in enabled, `onBackPressed()` is not called and callback is used regardless of `android:enableOnBackInvokedCallback` property in <application> or <activity> set in AndroidManifest.xml.
As a workaround callback is manually calling existing `onBackPressed()`.
This is done rather than removing onBackPressed() completely and using only `OnBackPressedCallback` as we are not sure of the impact of removing the implementation entirely. Once we determine it is safe to do so then, we should remove the workaround and fully transition to `OnBackPressedCallback`
* I also surveyed child classes extending ReactActivity for overridden `onPressedBack()` usage and found only one usage which will be handled later.
NOTE: `ReactDelegate.onHostResume()` sets up the `DefaultHardwareBackBtnHandler` using `ReactActivity` (https://fburl.com/ul47tbeo) and will be called from JS `BackHanderl.exitApp` (https://fburl.com/code/a4l2pjsw). Calling `BackHanderl.exitApp` enables predictive back to work.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D74161428
fbshipit-source-id: 2e081ba6922b315e9d1746e83a41bab5277fa62e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51136
This diff attaches doc block to ProgressBarAndroid copied from the manual TS types.
Generated types result:
```ts
import * as React from "react";
import type $$IMPORT_TYPEOF_1$$ from "./ProgressBarAndroidNativeComponent";
type ProgressBarAndroidNativeComponentType = typeof $$IMPORT_TYPEOF_1$$;
import type { ProgressBarAndroidProps } from "./ProgressBarAndroidTypes";
export type { ProgressBarAndroidProps };
declare let ProgressBarAndroid: (props: Omit<ProgressBarAndroidProps, keyof {
ref?: React.Ref<React.ComponentRef<ProgressBarAndroidNativeComponentType>>;
}> & {
ref?: React.Ref<React.ComponentRef<ProgressBarAndroidNativeComponentType>>;
}) => React.ReactNode;
/**
* ProgressBarAndroid has been extracted from react-native core and will be removed in a future release.
* It can now be installed and imported from `react-native-community/progress-bar-android` instead of 'react-native'.
* see https://github.com/react-native-community/progress-bar-android
* deprecated
*/
declare const $$ProgressBarAndroid: typeof ProgressBarAndroid;
declare type $$ProgressBarAndroid = typeof $$ProgressBarAndroid;
export default $$ProgressBarAndroid;
```
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D73855212
fbshipit-source-id: c6c09ea68c9f61f305f96c0954370bb938fc59d9
Summary:
Selectively disabling autolinking of a native dependency with components registered in the codegen configuration in react-native.config.js causes builds to crash upon launch on iOS. This is because the generated `RCTThirdPartyComponentsProvider.mm` file contains references to the excluded library using `NSClassFromString` causing the returned NSDictionary from `+[RCTThirdPartyComponentsProvider thirdPartyFabricComponents]` to be populated with nil values and therefore crashing the app. This has been confirmed in 0.78.2 and 0.79.2 but probably exists in 0.77.x as well.
The issue has been further described in https://github.com/facebook/react-native/issues/51077.
## Changelog:
[IOS][FIXED] - Skip codegen for selectively disabled libraries in react-native.config.js
Pull Request resolved: https://github.com/facebook/react-native/pull/51078
Test Plan:
1. Install a library that has the componentProvider field set in the codegen config (see reproducer) and install the iOS pods.
2. Build the app.
3. App should run successfully without any crashes.
Reviewed By: cortinico
Differential Revision: D74248371
Pulled By: cipolleschi
fbshipit-source-id: 1ff7b477ed3d94ca45616ae243d3d2d30bd897db
Summary:
Follow up from https://github.com/facebook/react-native/issues/51061 – Static code analysis detected several redundant constructs across the codebase. Most of the ones fixed here are marked as warnings/weak warnings, likely code smells post-migration from Java.
Doing another small round to clean up some of them.
## Changelog:
[INTERNAL] - Kotlin: Clean up redundant constructs
Pull Request resolved: https://github.com/facebook/react-native/pull/51170
Test Plan:
```sh
yarn android
yarn test-android
```
Reviewed By: rshest
Differential Revision: D74381864
Pulled By: cortinico
fbshipit-source-id: 25244cdf384875f7cc4e2d091c8b247710de5ecf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51162
We specify the java target version to 17 for ReactAndroid but not for hermes-engine.
This is causing it to be the default (8) which will cause our build to fail on JDK 21.
This fixes it.
Changelog:
[Internal] [Changed] -
Reviewed By: alanleedev
Differential Revision: D74325107
fbshipit-source-id: 39ba745be4fa754fb0b0408160202940a61fcd94
Summary:
Enables `DEFINES_MODULE` in `React-jsc.podspec`
After upgrading app to RN `0.79`, when installing pods with JSC enabled there is an error being thrown that
`The following Swift pods cannot yet be integrated as static libraries`
`The Swift pod 'RNFlashList' depends upon 'React-jsc', which does not define modules. ...`
when installing packages that use Swift
## Changelog:
[IOS] [CHANGED] - enable `DEFINES_MODULE` in `React-jsc.podspec`
Pull Request resolved: https://github.com/facebook/react-native/pull/51160
Test Plan: RNTester runs and builds correctly
Reviewed By: huntie
Differential Revision: D74325357
Pulled By: cipolleschi
fbshipit-source-id: b994b7e678633440d5e362ae6965b2d5188d34f1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51138
The co-opting logic failed to account fo the case where the entire text view as a link and therefore turns off ax. In this case I think it makes sense to re-focus that element again so the user can interact with the link.
Changelog: [Internal]
Reviewed By: jorge-cab
Differential Revision: D74262675
fbshipit-source-id: c8d11cdff76cd92170581d167d5a8df64d0dd101
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51155
changelog: [internal]
we have experienced breakages where we stopped propagating accessibility prop to the mounting layer. These tests should catch it.
Reviewed By: fabriziocucci
Differential Revision: D74317767
fbshipit-source-id: 72c6d8c788afe3a9d4d41f7cfc0aa37605b20b6a
Summary:
Static code analysis detected several missing `ReplaceWith` on deprecated methods. This diff addresses some of them by adding the most accurate suggestions based on the implementations.
## Changelog:
[INTERNAL] - Add missing ReplaceWith on deprecations
Pull Request resolved: https://github.com/facebook/react-native/pull/51144
Test Plan:
```sh
yarn android
yarn test-android
```
Reviewed By: fabriziocucci
Differential Revision: D74327121
Pulled By: javache
fbshipit-source-id: 5b338531210bef104208d14cbd0e3320dc566b8e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51151
changelog: [General][Deprecated] - deprecate type aliases ShadowNode::Unshared and ShadowNode::Weak in favour of std::shared_ptr<ShadowNode> and std::weak_ptr<ShadowNode>
migrate away from using these type aliases to avoid confusion.
It is unclear from ShadowNode::Unshared what it means. This can be avoided by using std::shared_ptr<ShadowNode> directly. The same applies to ShadowNode::Weak.
Reviewed By: rubennorte
Differential Revision: D74245228
fbshipit-source-id: f22a18e87f170e46f5079e0ee7678700a3f5f623
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51149
Changelog: [internal]
This replaces the use of `ShadowNode` with `ShadowNodeFamily` in the `MutationObserver` logic to prevent retaining stale subtrees of the nodes being observed.
It refactors some existing logic so we don't need to keep track of the shadow nodes in JS. It was only used to be able to find the node for a target after unmounted, so we could "unobserve" it, but `MutationObserver` doesn't support unobserving individual targets anyway, so we removed that use case and implemented a more general `unobserveAll` method that doesn't require the shadow nodes in the first place.
Reviewed By: javache
Differential Revision: D74240834
fbshipit-source-id: 6d4c43a561780962874c76615fb53369c0c68cf7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51128
Changelog: [internal]
Just a minor refactor of a method in `MutationObserver` which was doing some redundant work that could be avoided.
Reviewed By: javache
Differential Revision: D74247437
fbshipit-source-id: 510d26f2a315582df9cddc215bf516d3d4ebd341
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51133
Changelog: [internal]
Having a single native module with all the test-specific functionality that we need in native in Fantom is just more convenient.
Reviewed By: rshest, huntie
Differential Revision: D73997209
fbshipit-source-id: 5d3aa69a2c799166a1351fbff3e80e4396cec9c6
Summary:
Static code analysis shows that there are a lot of unresolved KDoc references. This is just another round addressing several of them.
## Changelog:
[INTERNAL] - Fix unresolved KDoc references
Pull Request resolved: https://github.com/facebook/react-native/pull/51142
Test Plan: Verify that the comments link the classes correctly using Android Studio.
Reviewed By: rshest
Differential Revision: D74305933
Pulled By: javache
fbshipit-source-id: f512a33fa5da46fb828bb76bd95d9502261ea08a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51141
This diff introduces ReactSoftExceptionLogger.CategoryMode to limit categories used on soft errors, the limiation will only create a lint warning but won't create a compilation error.
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D74263367
fbshipit-source-id: 56fb2ef0ad3d24810172af300e43ecc1f479464f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51089
Currently, `IntersectionObserver#observe` retains a reference to the `ShadowNode` of the view that is supplied as an argument, which is used to compute intersection whenever a shadow tree is committed.
However, the `shadowNode` includes all of child nodes and state at the time that `IntersectionObserver#observe` is called. This means that an active `IntersectionObserverEntry` will retain references to memory that would otherwise be deallocated (e.g. if children of the observed view are unmounted after `IntersectionObserver#observe` is called).
This diff refactors `IntersectionObserver` to instead retain a reference to the `ShadowNodeFamily`, which does not retain references to child nodes and still eanbles `IntersectionObserver` to compute intersections.
Changelog:
[General][Changed] - Fixed `IntersectionObserver#observe` to avoid retaining memory for unmounted child nodes of observed views.
Reviewed By: RSNara
Differential Revision: D74130479
fbshipit-source-id: 6b581f73f06b93e6463d5004c181c39aae13896a