Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44772
Changelog: [Internal]
React native clones shadow nodes internally without providing the new instances to the React renderer (current fiber tree). To support updating the shadow node references held by the JS side, this diff wraps the returned shadow nodes and adds a link to the runtime reference on the shadow node instance.
This will allow for updating the shadow node references held within the JS runtime from the native side.
Reviewed By: sammy-SC
Differential Revision: D57860869
fbshipit-source-id: 1703f0cd0183e2760436920a122857e17fda8dbb
Summary:
This diff reverts D57878119
D57878119: [RN] [Android] Fix status bar height calculation for all cutout sizes by Abbondanzo causes the following test failure:
Tests affected:
- [xplat/endtoend/jest-e2e/apps/fb4a/__tests__/dating/onboarding/fb4aDatingOnboardingSessionImpressionLogging-e2e.js](https://www.internalfb.com/intern/test/562949977559606/)
Here's the Multisect link:
https://www.internalfb.com/multisect/5267005
Here are the tasks that are relevant to this breakage:
T189149205: 17 critical tests unhealthy for oncall dating_react_native_sop
The backout may land if someone accepts it.
If this diff has been generated in error, you can Commandeer and Abandon it.
Changelog: [Internal]
Reviewed By: Abbondanzo
Differential Revision: D58053899
fbshipit-source-id: c65a1094259f85c8e6084b2f191ca1e4cd149510
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44702
Based on bgirard initial changes in D53478653, this creates an initial integration of the Perfetto SDK with the User Timing API, allowing performance information to be logged from JS to Perfetto traces.
We only enable this for Android right now, but may be able to leverage this on other platforms too in the future.
The logic in `initializePerfetto` may need to moved to another common target (eg reactperflogger) once we want to make this usable in other components, but keeping it scoped to User Timing for now.
Changelog: [Internal]
Reviewed By: bgirard
Differential Revision: D57881823
fbshipit-source-id: 11ba09cbc01a102a72eee65ce6d6aeca508e864a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44480
TextInputs' onTextInput callback was removed way back in React Native 0.62 with https://github.com/facebook/react-native/commit/3f7e0a2c9601fc186f25bfd794cd0008ac3983ab , but remnants of the implementation exists.
Fully remove references on JS side now that no older clients are emitting this event
Changelog: [General][Removed] Remove viewconfigs for onTextInput callbacks
Reviewed By: cipolleschi
Differential Revision: D57092733
fbshipit-source-id: 62dae37d8e8f155969a1ca65131d4ee9a1d5f1c4
Summary:
Based on https://github.com/facebook/react-native/issues/44723.
This PR removes some Old Arch build only jobs on iOS.
Some of the recent changes where unifying the build process across archs, so we don't have to build Old and New Arch
## Changelog:
[Internal] - Remove OldArch jobs when they are not required
Pull Request resolved: https://github.com/facebook/react-native/pull/44729
Test Plan: CCI is green
Reviewed By: cortinico
Differential Revision: D57975238
Pulled By: cipolleschi
fbshipit-source-id: ffd0ff0534f25019d501aa3862baee1442088784
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44733
We are returning a Path to callers, which shouldn't be mutated. This isn't really safe. Return a copy to external callers instead, if they need a path to work with.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D57996157
fbshipit-source-id: 53cd95df6e2641d946f7c3fef40f6449b16ca5cb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44732
`getBorderBoxPath()` and `getPaddingBoxPath()` currently assume `updatePath()` will set a path, but this does not happen on Android 24 emulators where it seems like `onBoundsChanged` isn't called to set flag for needing update.
But, the current design tries to be lazy with path generation, and these are probably more expensive to clip, so we should really make these functions return nullable value, then fall back to rect, like the internals of `CSSBackgroundDrawable`, and how I misremembered these as working in the view code added originally in D57668976.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D57951852
fbshipit-source-id: 33bc8f738950597822ae9026408ab3a23b0923f3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44668
Enables regenerator for `hermes-canary`. Along with the previous diff, regenerator is the only difference between `hermes-stable` and `hermes-canary`.
Reviewed By: motiz88
Differential Revision: D57742907
fbshipit-source-id: ca14cb50fe976744c7fa2c0b3397e81661359f15
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44728
This makes them identical so the diff that makes them diverge is clear.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D57970711
fbshipit-source-id: 8586ef202ad27796918378832fa62df1708a0218
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44744
Correctly handle TurboModule promise rejections when there is no Exception message.
Changelog: [Android][Fixed] Android exceptions without a message would lead to unexpected crashes
Reviewed By: fabriziocucci
Differential Revision: D58014797
fbshipit-source-id: c94042818a00669a1be2db8e89e84c6b616efbec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44697
Google has discouraged attempting to read the `status_bar_height` resource [since 2017](https://youtu.be/_mGDMVRO3iE?si=qGQd7gLa_qTmfLGL&t=1079). With the introduction of display cutouts there can be a mismatch between the resource value and the true status bar size (and issues like [this one](https://github.com/facebook/react-native/issues/33612) popped up). The recommended approach is to instead call `getInsets` with the proper status bar and navigation flags provided by `WindowInsets`. On older APIs where `getInsets` is not supported, we have access to `systemWindowInsetTop`.
Changelog:
[Android][Fixed] - Fixed StatusBar.currentHeight calculations to honor all cutout sizes
Reviewed By: cipolleschi, alanleedev
Differential Revision: D57878119
fbshipit-source-id: 9fadd33d5f9b617a70a052c98dbd53fd29281650
Summary:
Changelog: [General][Fixed] Fixed LogBox not showing correctly on the New Architecture
We found an incorrect behavior in the event loop, where an error in a task would prevent its microtasks from running. This isn't spec compliant and should be fixed.
This caused LogBox to not work correctly, as error reporting is implemented via microtasks that would never execute.
Reviewed By: sammy-SC
Differential Revision: D58010521
fbshipit-source-id: 7901c5d6e83fb63af148e12ad6c32be490a3999d
Summary:
In the previous months, we worked with a GH engineer to run our test workflow on PRs. The workflow was running properly, so we want to run it on main too.
## Changelog:
[Internal] - Run gha on main too
Pull Request resolved: https://github.com/facebook/react-native/pull/44723
Test Plan: GHA is green
Reviewed By: cortinico, NickGerleman
Differential Revision: D57975230
Pulled By: cipolleschi
fbshipit-source-id: 89d06361ad6f2230b7000e05970e9b16539c9164
Summary:
Add synchronous JS bindings installation for TurboModules. That would help some 3rd party JSI based modules to install JS bindings easier.
https://github.com/facebook/react-native/issues/44486 for Android
## Changelog:
[Android] [ADDED] - Add BindingsInstaller for TurboModules
Pull Request resolved: https://github.com/facebook/react-native/pull/44526
Test Plan:
Added test in RN-Tester TurboModule test case
{F1660267530}
{F1660287029}
Reviewed By: javache
Differential Revision: D57223328
Pulled By: philIip
fbshipit-source-id: d4a69a16f6ce77c0a0fd63f008bea929b1964ab8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44709
Add some extra logging to try to figure out heisenbug, where we cannot find MapBuffer key that we should expect to be present, only during view preallocation.
ReadableMapBuffer toString() will itself iterate through MapBuffer entries, so this might not return something sane if underlying MapBuffer is corrupt or wrongly oriented, but should give us more context.
We also need to be careful here, to avoid logging the actual state mapbuffer or its binary which may contain text content. Only the paragraph attributes.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D57925730
fbshipit-source-id: cecca1a1fe53b4b417d520e65c30d47243cb2fb2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44707
Changelog: [Internal]
For DrawerLayoutAndroid in New Architecture, when we use ReactDev Tools layout inspection, incorrect node is being shown in the inspector tools.
This is because pointerEvents is not set to either `box-none` or `none` based on the drawer open/close state for the drawer child wrapper `View`.
Reviewed By: hoxyq
Differential Revision: D57873834
fbshipit-source-id: b2b82633969922189a0b96feea2115ddc0b2ebb5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44726
Changelog: [internal]
## Context
We ran an experiment to test synchronous state updates in Fabric and we saw some crashes on Android. Those crashes were caused by mounting operations not being applied in the correct order.
There were 2 root causes for that problem:
1. State updates triggered during mount would be committed and mounted synchronously during that specific mount operation. That caused problems like trying to clip views that weren't created already (as we were processing the state update for the content offset before we actually created the child views).
2. Same problem as before, but with mount operations that were processed when the root view wasn't available yet (this is a separate queue).
We tried to fix the problem in https://github.com/facebook/react-native/pull/44015, but the solution for 2) was incorrect, as we didn't account for those operations being in a different queue (it was reverted in https://github.com/facebook/react-native/pull/44724).
## Changes
I think the right solution for point 2) is that, instead of marking the root view as available and then process all pending operations, we flip those operations.
That was, if there are any mount operations as a side-effect of processing that queue, those will also be added to the same queue, instead of being processed immediately in `MountItemDispatcher`.
Reviewed By: sammy-SC
Differential Revision: D57968937
fbshipit-source-id: 93d10cdeced0c837d4301768aee8575d2c940b10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44725
Changelog: [internal]
## Context
We're currently testing synchronous state updates in Fabric (committing shadow trees for state updates synchronously in the thread where they were dispatched, instead of always scheduling it in the JS thread).
In these experiments we saw a problem caused by a recent change in the Android mounting layer (done to fix a problem with the Event Loop) where we were doing the mount operations inside a mutex lock. The problem is that we didn't have recursive commit+mount operations (because we were dispatching state updates in the JS thread) but now that we do we get a deadlock here.
{F1659804385}
These recursive commit+mount operations happen because it's possible to trigger state updates while we mount changes in the host platform (e.g.: we create the scroll view and we update the state to set the content offset). Those state updates trigger more mount operations, which deadlock in the mentioned place.
## Changes
This fixes the described issue by restricting the lock only to access the list of pending operations, but not to apply them. In the current implementation, `mountingManager->executeMount` is protected by the lock, whereas in the new version it isn't (so it can be safely called recursively). The synchronization of the mount operations is done directly at the mounting layer on Android.
Reviewed By: sammy-SC
Differential Revision: D57968936
fbshipit-source-id: 52f996d212cad691646610632b03b5223e7e90ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44724
Changelog: [internal]
Batching operations at this layer was wrong because these are the operations that were already flushed by the mounting layer but were accumulated in `SurfaceMountingManager` because the root view wasn't created.
These operations should be executed before anything else that's scheduled in the `MountItemDispatcher`, so we should never batch them. The problem this was trying to solve is solved in a different way in D57968937.
This was gated so this shouldn't affect any current usages.
Reviewed By: sammy-SC
Differential Revision: D57968939
fbshipit-source-id: e9131614cdc76e9d553540757611bc8b0736c927
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44727
This is a re-land of https://github.com/facebook/react-native/pull/44048
Reverting it caused even bigger regression, so my earlier assessment was wrong. The initial regression was caused by something else.
Changelog: [Internal] - Let's keep the changelog entry form the original diff.
Reviewed By: fkgozali
Differential Revision: D57970133
fbshipit-source-id: c683d661a805d44434f5491e89dd4b7218379bee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44716
Move to listr2 which handle non-TTY environment, outputting to CircleCI logs in a useful way. This gives our CI users more useful debugging information, but limits the output when running locally.
If you want more explicit output locally, do something like:
```
yarn run build | cat
```
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D57915369
fbshipit-source-id: ae9f87b0b9608f16ee035b791c5f7b81544c498c
Summary:
On React Native macOS (I am not sure with the current state of React Native), the Xcode Unit and Integration tests are a bit flaky. Rather than set "retry on failure up to 3 times" through the pipeline config (in our case, Azure Pipelines), I realized my earlier PR to use Xcode test plans (https://github.com/facebook/react-native/pull/36443) means we can have Xcode retry the test. This should be faster than retrying it on the pipeline, because it retries just the failing test, not the entire "test" step. I did this on React Native macOS, so I'm doing it upstream so we can remove a diff.
## Changelog:
[INTERNAL] [CHANGED] - Set `retryOnFailure` for Xcode Unit and Integration tests
Pull Request resolved: https://github.com/facebook/react-native/pull/44642
Test Plan: CI should pass (faster)
Reviewed By: cortinico
Differential Revision: D57662523
Pulled By: cipolleschi
fbshipit-source-id: 8de2ab0ea15ba4d38c3b5bf96108c0c7ff5e9f32
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44708
Changelog: [internal]
We had a fallback to use a Hermes internal API if the native module exposing `queueMicrotask` wasn't available. This is no longer necessary as the module is available everywhere we enable the event loop, so we can remove it.
Reviewed By: christophpurrer
Differential Revision: D57922076
fbshipit-source-id: 0ca48abacd77a75ce8559db08f55c78a3e0ec815
Summary:
Add synchronous JS bindings installation for TurboModules. That would help some 3rd party JSI based modules to install JS bindings easier.
Re-create from https://github.com/facebook/react-native/issues/43110 but for iOS
## Changelog:
[IOS] [ADDED] - Add BindingsInstaller for TurboModules
Pull Request resolved: https://github.com/facebook/react-native/pull/44486
Test Plan: Added test in RN-Tester TurboModule test case
Reviewed By: javache
Differential Revision: D57224891
Pulled By: philIip
fbshipit-source-id: fabe5c4f8d2087ac9a465f2cb90d884b83265a68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44705
`focusable` props behaviors are inconsistent across different flavors of Touchable components. Some use the disabled prop to check if the component should be focusable, others do not.
This ensures all Touchable* component flavors use the disabled prop.
## Changelog
[General][Fixed] Fixed inconsistency in TouchableX component disabled / focusable behavior
Reviewed By: yungsters
Differential Revision: D57910488
fbshipit-source-id: af17227403338fcd5bebd9ba7c3172b4c6776e1f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44706
We didn't ship this, and asking around, I don't think mdvacca was looking at this actively (though is on PTO right now).
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D57913491
fbshipit-source-id: 86afd5a6bb5e7ce6be540f2295aa407134a6d81c
Summary:
Expose host delegate methods that users can do some customize work.
## Changelog:
[IOS] [ADDED] - Bridgeless: Expose host delegate methods
Pull Request resolved: https://github.com/facebook/react-native/pull/44158
Test Plan: Users can do some customized work by `RCTRootViewFactory`.
Reviewed By: sammy-SC
Differential Revision: D56521470
Pulled By: cipolleschi
fbshipit-source-id: dd22d0978b9fd4385380945a514eb6596b7d874f
Summary:
XCode privacy files might not contain a `NSPrivacyAccessedAPITypes` key, which causes the following error:
```
[!] An error occurred while processing the post-install hook of the Podfile.
undefined method `each' for nil
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:111:in `block (4 levels) in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:106:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:106:in `block (3 levels) in get_used_required_reason_apis'
```
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [FIXED] - Privacy Manifest aggregation failing due to no `NSPrivacyAccessedAPITypes` key
Pull Request resolved: https://github.com/facebook/react-native/pull/44628
Test Plan: I tested this patch on our own app and it solved the issue.
Reviewed By: christophpurrer
Differential Revision: D57618425
Pulled By: cipolleschi
fbshipit-source-id: 1a36ab5a1bb45b8507d3663b782c95258d97c8a4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44699
Changelog: [Internal]
In Fabric, overflow props for ScrollView is not passed down. Hence, the overflow props is ignored and FlatList content is always clipped.
Reported from OSS https://github.com/facebook/react-native/issues/44683
Reviewed By: sammy-SC
Differential Revision: D57895399
fbshipit-source-id: 6ce65bea0803971060e8229b66563123dd6fc114
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44695
Changelog: [internal]
We tested this feature flag at Meta and it's neutral when used outside the event loop. We'll handle its effects on the event loop as part of the event loop experiment itself (when enabling paint blocking).
Reviewed By: tdn120
Differential Revision: D57861195
fbshipit-source-id: 11a208ef5433321a464cfc16f4ff026d52988b42
Summary:
Currently, if the `Animated.sequence` animation is finished, and then the `start()` method is called without a `reset()` method being invoked beforehand, the failure happens: ```undefined is not an object (evaluating 'animations[current].start')```.
Use cases:
- sequence animation started, finished, and then started again
- sequence animation is used in `Animation.loop` with `resetBeforeIteration` set to `false`, which essentially does the same as the previous case
Related issues:
- https://github.com/facebook/react-native/issues/43120
- https://github.com/facebook/react-native/issues/37611
## Changelog:
[General] [Fixed] - Fix sequence restart failure
Pull Request resolved: https://github.com/facebook/react-native/pull/44031
Test Plan: Test cases are included: 1 for regression and 2 for mentioned use cases in the summary
Reviewed By: cipolleschi
Differential Revision: D56015346
Pulled By: dmytrorykun
fbshipit-source-id: 8b0f46c8a33397fece807634463ce630c89d28af
