Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51222
The size parameters are flattened in the source object in the Android image component. This diff converts the `size` object to `width` and `height` props directly set on the source object, fixing image source setting more than one image source.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D74477884
fbshipit-source-id: f6064b4222d5eeafd5d74f9a2044babedd1e291b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51217
Add helper method to build the prop diffing based on the BaseTextProps which are used by the Text and Paragraph props.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D74473004
fbshipit-source-id: 0ae8c0c033ee136da3b8376bd485f8926310dcd4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51233
Migrates internal operational and experimental feature flags to React Native's feature flag system, in order to simplify integration of other infrastructure features (e.g. Fantom).
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D74534921
fbshipit-source-id: 1559cba4f208a554bb043a203f331062036c60de
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51220
Changelog: [internal]
Just a playground file to do quick tests in the Fantom environment.
For example, I just used it to know if Hermes supports `AggregateError`, which does:
```
it('...', () => {
console.log('AggregateError', global.AggregateError);
});
```
{F1977824992}
Reviewed By: lenaic
Differential Revision: D74474870
fbshipit-source-id: cbe8a287738b09afe336ae479cc3105d1474e58b
Summary:
Flag was removed in {D74196673}, this cleans up the dynamic flag.
bypass-github-export-checks
Changelog: [internal]
Reviewed By: jackpope
Differential Revision: D74493584
fbshipit-source-id: 6ade542b7e1bd9c4367b7dbef4d2f1ec2d79d0df
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50197
Adds `setRuntimeData` and `getRuntimeData` JSI APIs. This provides a
convenient way for users to store some custom data associated with an
UUID.
For the default implementation of this feature, store the runtime data
in the global map that is shared between all VMs. This is done to keep
JSI lightweight and stateless, instead of adding data members.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D71579532
fbshipit-source-id: 553e28fbf80c93e268d475860197a00d2c5bacf7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50270
Add UUID struct to JSI. This will be used in the incoming changes, such
as identifying JSI interfaces and storing custom runtime data.
Changelog: [Internal]
Reviewed By: tmikov
Differential Revision: D71826382
fbshipit-source-id: e0d9bc20fb0f0e75407b9c88e731623e6a9975dd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51206
When we create a layout from measure constraints, we do some processing of the width, to return a different one, potentially smaller than the layout width, sometimes using line width, and sometimes using the container width.
This logic has gotten spooooky over time, and after a series of changes, and bugfixes, now effectively does nothing!
1. Way back in 2020, yungsters made D21056031 introducing this logic to "shrink wrap" text which is wrapped.
2. "Shrink wrapping" is not how web works when text is wrapped, (though it is how it works when there is explicit newline), and https://github.com/facebook/react-native/pull/47435 later undid this change
3. https://github.com/facebook/react-native/pull/37790 made changes specific to the case of trailing newline, because the logic to "shrink wrap" did not handle correctly.
After D74366936, which changes width used for layout creation to correctly respect `Layout.desiredWidth`, we should be back to multiline layouts, with no paragraph whose lines take up more than container width, being "shrink wrapped", while not doing so when there is wrapping or ellipsization, like current behavior. The desired width also excludes the non-visible trailing whitespace.
It means we can remove all of this logic, while preserving the same behavior. Mismatched measure widths from those used in the intermediate layout may also result in issues for Facsimile (see example in last diff of stack).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D74368513
fbshipit-source-id: df5d7b773ad1888ebca1966ee4020a5c2ce7fd64
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51221
In the case of an empty root node, we don't need `buildStubViewTreeWithoutUsingDifferentiator` to create the initial `StubViewTree`
When testing with Fantom, this caused an additional unnecessary clone of RootShadowNode.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D74472766
fbshipit-source-id: 076e859a6c5795e9026c7a5f8246a5658db4a94b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51214
D74381864 caused a series of crashes to spike due to .IncompatibleClassChangeError: Class 'android.content.res.TypedArray' does not implement interface 'java.lang.AutoCloseable'
This fixes it.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D74468593
fbshipit-source-id: 70c14bdba4f229d4f59a01da3b56cd4fec29752f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51070
Changelog: [General][Internal][Breaking] When a bundle is failing to load throw an error of special type.
### Breaking
`didCompleteNetworkResponse` now throws an Error instead of throwing a string.
In dev, we use [lazy bundling](https://github.com/react-native-community/discussions-and-proposals/blob/main/proposals/0605-lazy-bundling.md#__loadbundleasync-in-metro) which allows us to re-build only the parts of the app that are changed.
However the function that loads these lazy bundles in `loadBundleFromServer.js` for requests that reach `didCompleteNetworkResponse` with an error **throws a string representing the error message** which makes debugging very inconvenient because it lacks stack trace and error type. Throwing strings is not a standard practice. We better throw an error in these cases so it can be handled better.
Why a special type of error?
* As you can see in the "after", in the test plan below, even with a stack trace, it might be hard to know where this error originates from
* Also so extra information can be added on it. Currently adding "url"
* Also to support error handling based on the type of error
Reviewed By: hoxyq
Differential Revision: D73925027
fbshipit-source-id: a0f98d283ec8842696f1b87864fb63cb30c0c028
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51210
Changelog: [internal]
This adds a safety mechanism to Fantom tests to prevent LogBox from swallowing errors.
Now we validate that LogBox isn't installed when running tasks, so we can properly fix error reporting in tests.
Reviewed By: rshest
Differential Revision: D74464749
fbshipit-source-id: ef5e814b14aedbc681a4c7f9f8f60f454b239b6d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51211
Changelog: [internal]
This modifies the setup for Fantom so:
1. We don't inject "InitializeCore" by default.
2. We define a default environment setup module for Fantom with good defaults (LogBox, etc. disabled).
We also migrate all existing tests to use the new module.
The goal of this is to prevent LogBox from being used in tests so we can properly fix error propagation in the work loop (so they're not intercepted by it).
Reviewed By: rshest
Differential Revision: D69003812
fbshipit-source-id: 00353b5055e3700943a08ea67f698d49e068555b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51209
Changelog: [internal]
This refactors `InitializeCore` to extract the initialization logic to a separate configurable module.
By default, this does the same thing it does now, but the new module could be used without `InitializeCore` to set up the environment forcing disabling developer tools (e.g.: for testing in Fantom in development environments).
Reviewed By: rshest
Differential Revision: D69003811
fbshipit-source-id: ab85b10e4f21adccd8844a848d3272c407832031
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51208
Changelog: [internal]
Adding a few more test cases to make sure error handling is fixed considering these use cases.
Reviewed By: rshest
Differential Revision: D74459974
fbshipit-source-id: 9a5865a9a09dd64535b4d38307db6c30f213b45f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51197
This change adds the Package.swift file that can finally build React Native core using SPM
## Changelog:
[Internal] - Add Swift PM file to uild React Native Core using SwiftPM
Test Plan:
prepare the repo with
```
node packages/react-native/scripts/ios-prebuilds.js
```
and by downloading the ReactNativedependencies from the CI
Then open the Package.swift file in Xcode. I successfully built:
- iOS
- iOS Simulator
- Mac Catalyst
Reviewed By: lenaic
Differential Revision: D74393435
Pulled By: cipolleschi
fbshipit-source-id: 7d61ad1d09444a0c16e865062ae448ec1e7ef5ad
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
Nick Lefever
zhongwuzw
Mateo Guzmán
Tim Yung
Rubén Norte
Jan Kassens
Chi Tsai
generatedunixname89002005287564
Nick Gerleman
Pieter De Baets
Nicola Corti
Vitali Zaidman
Christian Falch
Yannick Loriot
Ramanpreet Nara
Ramanpreet Nara
Mark Verlingieri
Dawid Małecki
Alan Lee
Fabrizio Cucci
Alex Hunt
ismarbesic