Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49272
Turns out bounds does not account for the proper size if a scaling transform is applied while frame does. Using the example listed in https://github.com/facebook/react-native/issues/49134, the size of the frame is the expected 240, but the size of the bounds is 200.
We had a mismatch where we use bounds everywhere in shadow image creation, but use the frame when asking for the size of the box shadow layer. What ends up happening is we have a 240x240 layer that is getting scaled again.
I refactored the shadow creation to just take a CGSize instead of a whole CALayer (which we had only used for its size anyway) so that we can be consistent with frame and bounds, and use bounds everywhere so that we only scale once.
Changelog: [iOS] [Fixed] - Fix cases where background color, filter, and background image were sized incorrectly if there was a scaling transform
Reviewed By: jorge-cab
Differential Revision: D69320213
fbshipit-source-id: a913e0df91d78ec9665752acefcae755ab607ac8
Summary:
Changelog: [Internal]
This is an automatically generated fixup patch to bring fbsource back into sync with
facebook/react on GitHub. Please land this patch as soon as possible, as the difference
reflected on here is already on GitHub and future changes may depend on these
changes!
<< DO NOT EDIT BELOW THIS LINE >>
diff-train-skip-merge
diff-train-source-id: 7e59b47d91fda2c6ef8946499d9e4457522a90d5
Generated by: https://www.internalfb.com/intern/sandcastle/job/4503601290447444/
GitHub Repo: facebook/react
Reviewed By: mofeiZ
Differential Revision: D69418289
fbshipit-source-id: 48636ba5bedfef7a09e0802f2a640be0417cdb7c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49284
All of the CMake library names in the "renderer" directory use "render" for the name, missing the last two letters of the directory name.
eye_twitch
I don't think fixing that should be breaking, since 3p libraries need to rely on the merged library anyway, so let's fix that and find/replace all these.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D69338892
fbshipit-source-id: d3b306ad0ea191728dfbacf9e2aaa12b00caa619
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49313
When the flag is enabled, we expect legacy native viewconfigs to add processor, where SVCs do not, and instead parse in native. Don't emit warnings in this case.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D69337802
fbshipit-source-id: f4c354c3b7b6ecbe4a8a72a37ea6d60dcc336b67
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49314
Add a flag which we will use to prefer Fabric CSS parser to ViewConfig processors. We will use this to experiment on iOS, where we are using Fabric props (until Props 2.0 for Android).
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D69337803
fbshipit-source-id: e3d4faeecbadb138c0a58f3fca6dba79eb7b13fa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49250
The TurboModule System decided to ignore the Null values when they are coming to JS. However, in iOS, null value can be mapped to `[NSNull null];` and this value is a valid value that can be used on the native side.
In the old architecture, when the user were sending a null value from JS to a native module, the Native side was receiving the value.
In the New Architecture, the value was stripped away.
This change allow us to handle the `null` value properly in the interop layer, to restore the usage of legacy modules in the New Arch.
I also tried with a more radical approach, but several tests were crashing because some modules do not know how to handle `NSNull`.
See discussion happening here: https://github.com/invertase/react-native-firebase/issues/8144#issuecomment-2548067344
## Changelog:
[iOS][Changed] - Properly handle `null` values coming from NativeModules.
Reviewed By: sammy-SC
Differential Revision: D69301396
fbshipit-source-id: be275185e2643092f6c3dc2481fe9381bbcf69e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49046
## Motivation
Modernising the RN codebase to allow for modern Flow tooling to process it.
## This diff
- Migrates files in `Libraries/PermissionsAndroid/*.js` and `Libraries/PushNotificationIOS/*.js` to use the `export` syntax.
- Updates deep-imports of these files to use `.default`
- Updates jest mocks
- Updates the current iteration of API snapshots (intended).
Changelog:
[General][Breaking] - Deep imports to modules inside `Libraries/PermissionsAndroid` and `Libraries/PushNotificationIOS` with `require` syntax has to be appended with '.default'.
Reviewed By: huntie
Differential Revision: D68832494
fbshipit-source-id: 4c44667856f5ad76b32a27a603a6538704c3192c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49292
changelog: [internal]
remove feature flag enableGranularShadowTreeStateReconciliation which was introduced in August 2023 and isn't rolled out.
Reviewed By: rshest
Differential Revision: D69393016
fbshipit-source-id: a1730f9811b1d8476d845e0303647b4d85f6b4a0
Summary:
Reland https://github.com/facebook/react-native/issues/48496 .
## Changelog:
[IOS] [FIXED] - Fabric: Fixes crash of dynamic color when light/dark mode changed
Pull Request resolved: https://github.com/facebook/react-native/pull/49265
Test Plan: RNTester -> PlatformColor example -> changed the dark/light mode in the system settings -> go back to App and pop and push the PlatformColor example, it would crash:
Reviewed By: javache
Differential Revision: D69309825
Pulled By: cipolleschi
fbshipit-source-id: 7a533a73ef343b071000388b653b2d1d0c54ae88
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49295
Motivated by https://github.com/facebook/react-native/issues/49287.
This improves on the less useful output of "fetch failed" currently. We expect failing to make a request to the dev server (made from the dev server!) to be a rare edge case, in which case we want to log as much info as possible.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D69395983
fbshipit-source-id: ee96d72ade5a887d190397c3b798a5b545152587
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49268
changelog: [internal]
ShadowView has three shared_ptr and copying those can be avoided here. Let's use std::move.
Reviewed By: NickGerleman
Differential Revision: D69303346
fbshipit-source-id: b13103369f6423610dd8f8ccb293e59f04acc5dc
Summary:
The performance of `_getFreeIndex` is quite terrible since the `timersID` array can get quite large when you spawn a lot of promises or timers. We profiled our application for 28 seconds on RN 0.71.11 and noticed that the `indexOf` into this array was consuming almost a second.
The hermes version that we are using has a pretty slow `indexOf` compared to other engines, and the static hermes will improve it by 12x but for the time being, this is a perf issue. https://github.com/facebook/hermes/pull/1447
We avoid having to use `indexOf` by maintaining a list of the free ids.
**Before - Samsung Galaxy A52 for 28 seconds of profiling**

**After - Samsung Galaxy A52 for 28 seconds of profiling**

## Changelog:
[INTERNAL] [FIXED] - Improve performance of _getFreeIndex
Pull Request resolved: https://github.com/facebook/react-native/pull/48925
Test Plan: - Tests pass, promises resolve and reject correctly, setTimeout works as expected
Reviewed By: javache
Differential Revision: D69059102
Pulled By: cipolleschi
fbshipit-source-id: d7de2c4adcf4dfc1d15e597e2a801e23c8d652aa
Summary:
Was going through some tests and I notice several files that use `RobolectricTestRunner` unnecessarily. This PR cleans that up.
## Changelog:
[INTERNAL] - Remove unnecessary RobolectricTestRunner usage
Pull Request resolved: https://github.com/facebook/react-native/pull/49290
Test Plan:
```
yarn test-android
```
Reviewed By: cipolleschi
Differential Revision: D69383948
Pulled By: cortinico
fbshipit-source-id: 6102319115240267ba83a086d03a850d1b7cdae5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49283
In this diff I'm introducing a new BuildConfig called UNSTABLE_ENABLE_MINIFY_LEGACY_ARCHITECTURE to determine if the new architecture is fully enabled into an Android app at build time, fully enabled means:
- no interop
- all view managers migrated to new API
- all native modules migrated to new API
- legacy architecture can be stripped
This BuildConfig is different from ReactNativeFeatureFlags.enableBridgelessArchitecture() because the latter is controlled at runtime, BuildConfig.UNSTABLE_ENABLE_MINIFY_LEGACY_ARCHITECTURE is used at the build system level and it can be accessed from proguard to optimize code that's unused when the app is fully running in the new architecture. Additionally we will use the BuildConfig to assert that some classes and methods are not loaded or executed.
changelog: [Android][Changed] Introduces BuildConfig.UNSTABLE_ENABLE_MINIFY_LEGACY_ARCHITECTURE to determine if the new architecture is fully enabled into an Android app
Reviewed By: cortinico
Differential Revision: D69206248
fbshipit-source-id: f60a059be8333d3051eb7d2efac79939a479f6f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49280
We were incorrectly consuming an `E` at the end of number tokens, even if not followed by a digit, which breaks dimension tokens where the unit starts with "E", like `em`. Follow the spec the right way:
https://www.w3.org/TR/css-syntax-3/#consume-number
> If the next 2 or 3 input code points are U+0045 LATIN CAPITAL LETTER E (E) or U+0065 LATIN SMALL LETTER E (e), optionally followed by U+002D HYPHEN-MINUS (-) or U+002B PLUS SIGN (+), followed by a digit, then...
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D69330975
fbshipit-source-id: a9bd5bceac9efbf02c1b7fb60659093774bb7228
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49279
I ended up using this same pattern for filter parsing where the logic betweeen functions is very similar. Let's deduplicate the logic for transform parsing a bit. This also separates `rotate()` and `rotateZ()` types, to be handled the same at a different layer.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D69326443
fbshipit-source-id: 9bf910c6d4e07748ff032433167576f9d58cd8d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49276
This diff replaces the remaining `React$` global types in the codebase, in preparation for their removal in Flow.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D69322418
fbshipit-source-id: 058a2489ce8e6bf59df2ec4e61e9708f63561671
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49271
This error is somewhat expected, so causing the red box error popup is a bit too disruptive. Flip it to a no-crash exception.
Changelog: [Internal]
Reviewed By: Abbondanzo
Differential Revision: D69125274
fbshipit-source-id: 0dc7ac59ac8637bdabde25bd8886b1aebf175395
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49277
Replaces the `-1` magic number representing unset children with a named constant
Changelog: [Internal]
Reviewed By: zeyap
Differential Revision: D69324509
fbshipit-source-id: 64fb6c920a7715f5d15d3955564a8bf2b6ce404a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49274
In this diff I'm updating all the non-codegen ViewManagerInterfaces to extend ViewManagerWithGeneratedInterface to make it consistent with codenerated ViewManagerInterfaces
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D69206247
fbshipit-source-id: 6a577d9ee7410be990a03e78847333b61b429e88
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49261
Update the version of Jest used in React Native and Metro's own tests from `^29.6.3` to `^29.7.0`
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D69307514
fbshipit-source-id: 686935ed4ba1334d445217fd2f8a303b774b6c4a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49198
changelog: [internal]
The work done on the main thread should scale with what is on the screen. React Native shouldn’t block the main thread for off screen elements that do not affect what is shown to the end user. When React schedules a commit, only views needed to achieve a screen full of content should be materialised and added to the host platform’s view hierarchy.
With Fabric View Culling, views that do not contribute pixels to the screen will not materialize and updates to them will be skipped. React Native will focus system resources on what is visible to the end user.
Fabric View Culling maximises benefits from view recycling. Each UI element such as text, image, or video is recycled individually. As soon as an item goes off screen, it can be reused anywhere in the UI and pieced together with other items to create new UI elements. Such recycling reduces the need of having multiple view types and improves memory usage and scroll performance.
In the example bellow, view B will not be mounted because the user can't see it.
{F1974949953}
The difference in number of allocated views:
Please note, the screenshots below are from Xcode View Hierarchy debugger. To show how many views are allocated in memory, I disabled [removeClippedSubviews](https://reactnative.dev/docs/scrollview#removeclippedsubviews) flag globally.
|Before|After:
| {F1974949979}| {F1974949981}
# Disclaimer, this is not a complete implementation
This implementation is not complete and it is missing to handle edge cases.
Things that are missing:
- Transform style is not taken into account.
- removeClippedSubviews is not respected. Fabric View Culling happens unconditionally for every scroll view.
- Fabric View Culling does not respect when ScrollView has overflow set to visible.
- Fabric View Culling is only performant enough on iOS.
- [enableSynchronousStateUpdates](https://github.com/facebook/react-native/blob/main/packages/react-native/scripts/featureflags/ReactNativeFeatureFlags.config.js#L248) must be enabled for Fabric View Culling to work correctly.
Reviewed By: javache
Differential Revision: D63458372
fbshipit-source-id: c93ec434081f2be8a446212e2c0681f8ae4e90f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49197
changelog: [internal]
Adds new method to LayoutMetrics that calculates frame adjusted for overflow inset.
For example, for the following view hierarchy. it would produce a frame that would fully contain view A and view B.
```
┌─────────────┐
│<View A /> │
│ ┌───────┴─────┐
└─────┤<View B /> │
│ │
└─────────────┘
```
See tests for more details
Reviewed By: javache, lenaic
Differential Revision: D68775683
fbshipit-source-id: b8f7c42cfca7dba8dcae75cae5e6944bd1082957
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49258
Updates dependency resolution in `yarn build-types` to happen after the `translateFlowToFlowDef` step. This means that we prune all non-type imports, massively reducing the input files of the program when building types only.
Changelog: [Internal]
Reviewed By: j-piasecki
Differential Revision: D69302812
fbshipit-source-id: aa80bea17cb584b747cb31c003e87fe00afd1e16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49257
Adds minimal dependency resolution to `yarn build-types`.
- This enables us to opt in React Native APIs by entry point, with the build script resolving all necessary dependencies. Improves correctness and removes concern of globbing paths manually.
Other notes:
- The `ActionSheetIOS.js` entry point is temporarily disabled as input; needs further work.
Changelog: [Internal]
Reviewed By: j-piasecki
Differential Revision: D69255015
fbshipit-source-id: 2d99c014b50e41e4695549f46ca874a2b546f545
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49241
In auditing differences between `InteractionManager` and `InteractionManagerStub` (used to evaluate to entirely remove the former all together), I noticed a behavioral disparity with how errors are handled.
In `InteractionManager`, the promise that's returned is never rejected, whereas `InteractionManagerStub` propagates errors by rejecting the promise that's returned. This changes `InteractionManagerStub` to behave like `InteractionManager` for the purpose of comparing apples-to-apples.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D69275495
fbshipit-source-id: 05439a0cadc1f76b34a3f1457f7db31d6bda2a90
Summary:
Fantom was disabling Metro hierarchical lookup in all cases when `JS_DIR` is set. The intention is that `node_modules` folders other than the configured `JS_DIR/public/node_modules` are not used.
However, this leads to incorrect resolution where a transitive dependency is not hoisted. If the origin of the resolution is already inside `node_modules`, we must perform a hierarchical lookup to avoid picking up just whichever version happens to be hoisted to `node_modules` root.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D69303559
fbshipit-source-id: 12068fb0bebb8c2f81b64c23b952a623cb6fd792
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49252
Changelog: [internal]
This adds a Fantom test placeholder for LogBox, which shows what type of tests we could be writing for this.
It also adds a few ids in LogBox components so we can inspect them in tests and make assertions on them.
Reviewed By: javache
Differential Revision: D69301572
fbshipit-source-id: 89a332a47c300c1dc18937cd91206ce6d820b6aa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49251
Changelog: [internal]
Components like `AppContainer` require passing the rootTag as a prop, but we don't have access to it from Fantom unless we render something in the root and access it via the RootTagContext. This exposes the rootTag of the Root as a method so we can use it in initial render too.
Reviewed By: javache
Differential Revision: D69301571
fbshipit-source-id: 429fb56d937d3dffeb3c17a70d136ba4925ece8e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49254
Changelog: [internal]
This is just a convenience method to do:
```
Fantom.dispatchNativeEvent(node, 'click');
```
Instead of:
```
runOnUIThread(() => {
enqueueNativeEvent(node, 'click');
});
runWorkLoop();
```
Which is too verbose and people rarely need this level of granularity in tests.
Note that, in Fabric, we have methods called `dispatchEvent` that don't match 1:1 with this API. In that case, `dispatchEvent` is more aligned with Fantom's `enqueueNativeEvent`.
Reviewed By: javache
Differential Revision: D69302382
fbshipit-source-id: 6f71a5ace11c81f551df2c2837881dbc6f48e7ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49253
Changelog: [internal]
Renaming this low level method as `enqueue` is more accurate in this case than `dispatch`, which is misleading because it actually doesn't dispatch it to JS.
We should also rename this in Fabric, but that's a larger and breaking change, so just making the change in Fantom for now. This is a trade-off between convenience/ergonomics of the testing API vs. alignment with the internal nomenclature. In this case we favor the first.
Reviewed By: javache
Differential Revision: D69302383
fbshipit-source-id: 7e163920ace709503367bf68baab5e9f2bf8ae3f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49231
Those public modifier have no meaning as the class is internal. I'm removing them.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D69252048
fbshipit-source-id: b51e5ac20338a01291d6cd04ee4c990cc8a6a755
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49229
This interface was converted to Kotlin, but the single method should have been converted to a `val`.
People kotlin consumers could call ReactOverflowView.overflow; now they need to call getOverflow().
Changelog:
[Internal] [Changed] - Undo a breaking change on ReactOverflowView
Reviewed By: NickGerleman
Differential Revision: D69250226
fbshipit-source-id: 5c7cca8c83f5c76a9cc1d254f8aa51409150c356