Summary:
Fixes a bug where page IDs would collide for multiple connected Android devices running the same React Native app. The `Secure.ANDROID_ID` key (not value!) was being substituted in the ID string (pre-hashing) — now this segment is fixed.
Changelog:
[Android][Changed] - Update constructor signature of `DevServerHelper`
Reviewed By: hoxyq
Differential Revision: D58134323
fbshipit-source-id: 859e2758108e266167205a777bb6a6e87ca0573b
Summary:
## Changelog:
[Internal] - Exclude the windows folder from View in React-Fabric podspec
## Facebook:
The `platforms/windows` folder is internal only, not synched with OSS.
However, the C++ linking was picking up some files from that folder when running RNTester on iOS using the OSS pipeline.
bypass-github-export-checks
Reviewed By: dmytrorykun
Differential Revision: D58182437
fbshipit-source-id: 5397fadbe96d5c2c7980fbf5e74ffab7b237b912
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44790
Was seeing crash due to:
> Abort message: 'terminating due to uncaught exception of type facebook::jni::JniException: java.lang.NoSuchMethodError: no non-static method "Lcom/facebook/react/bridge/ReactInstanceManagerInspectorTarget$
TargetDelegate;.onSetPausedInDebuggerMessage(Ljava/lang/String;)V"
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D58165901
fbshipit-source-id: ceafd5776933fca5abb2e2edcac5e5f677cb7f7d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44788
We disabled the event loop in RN on the main branch after we found some issues in the implementation. Those have been resolved already so we can re-enable it again.
For context, it's already enabled in the latest branch so this is just for main.
Changelog: [internal]
Reviewed By: cortinico
Differential Revision: D58146393
fbshipit-source-id: ab908ecbd507d7087137a36cad5cc917eb7b1311
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44765
Noticed this was not shared with open-source. Needs to be converted to Kotlin still.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D58088583
fbshipit-source-id: 51d13f2faddc7bce297dda54f2dd23cefed6a588
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44779
We forked a copy of Bolts when we open-sourced bridgeless, but it contains many features we don't require, since we only use Tasks to orchestrate the bridgeless startup path.
The only meaningful change I made is removing the fallback on stack overflow from the immediate executor, which is not something we expect to hit during startup, and would be better surfaced as a StackOverflowException.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D58087989
fbshipit-source-id: a4908723a04bf47fdc38d91bf47df928b91456f5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44766
Changelog: [Internal]
There is currently a lifecycle bug in both the Bridge (`com.facebook.react.bridge`) and Bridgeless (`com.facebook.react.runtime`) integrations of Fusebox in React Native Android, whereby `HostTarget::unregisterInstance` gets called after the `HostTarget` has been destroyed. This manifests as a handful of related C++ crashes depending on the exact circumstances and build flags.
This diff makes the bug trigger a Java assertion instead of a C++ crash for ease of debugging. The next diff in the stack will actually fix the lifecycle issue.
Reviewed By: hoxyq
Differential Revision: D58031217
fbshipit-source-id: 9301b34edf5e526cbc72d86e78b328d29c9921b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44778
We now have the Publish_bumped_packages in GHA, so we should not have two jobs in two different systems that perform the same publishing operation.
## Changelog:
[Internal] - Remove duplicated jobs from CCI
Reviewed By: cortinico
Differential Revision: D58131196
fbshipit-source-id: 408b0a76dff89e9d327fe56d1e6e4c13b55eb2bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44758
Changelog: [Internal]
Adding a unit test to verify that the shadow node references are correctly updated to reference the new shadow node instance after cloning.
Reviewed By: sammy-SC
Differential Revision: D57893880
fbshipit-source-id: 6e36ca3d1b159f7bafb084246f714f3bfec58c1e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44773
Changelog: [Internal]
Update runtime shadow node references for cloning happening within `YogaLayoutableShadowNode` during layout. This will update the JS references to shadow nodes with the latest layout metrics used to render the component and improve layout cache usage on the next commit.
Reviewed By: sammy-SC
Differential Revision: D58000071
fbshipit-source-id: 373d41f37a81e81ab8f23006491027473493de61
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44771
Changelog: [Internal]
Adding a feature flag for enabling runtime shadow node reference updates only for clones happening within `YogaLayoutableShadowNode` to support layout data changes.
Reviewed By: sammy-SC
Differential Revision: D58000072
fbshipit-source-id: 204c0488edb992511a4b33d098b9df1b04001b9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44770
Changelog: [Internal]
Any shadow node cloning happening outside the execution of the UIManagerBinding `cloneNode` function should update references held to the shadow node to reference the latest revision. All shadow node cloning not requested by the JS runtime should update the references to those shadow nodes within the JS runtime so that these would hold the latest state updated outside of the React renderer (i.e. state data and layout metrics).
This guarantees that the React renderer's current fiber tree holds references to the ShadowNode instances that acually were layed out and committed for rendering on the native side. Maintaining these references up to date on the JS current fiber tree allows to maximize layout cache usage on subsequent commits.
Reviewed By: sammy-SC
Differential Revision: D57860867
fbshipit-source-id: f13e3fa9ad501fb2c8a387fb58b6379d236d7c2d
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 3f7e0a2c96 , 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
