Summary:
After testing the latest RC and nighly builds, crash appeared when emitting events from turbo modules on 32bit Android devices. The crash is always reproducible only on 32bit devices on signed production builds. Fore more details and the crash log, check the [related issue](https://github.com/facebook/react-native/issues/51628#issue-3094045077).
From what I found, the variadic functions like CallVoidMethod are unsafe on 32bit due to not type checking the passed arguments at compile time. As far as I understand the 64bit cpus and ABIs are more forgiving with alignment and calling conventions. On 32bit the ABIs are strict as arguments are passed on the stack and if there is type/size/alignment issue it reads the wrong memory, which causes the SIGEGV crashes.
## Changelog:
[ANDROID] [FIXED] - emitting event from turbo module crashes on 32bit android
Pull Request resolved: https://github.com/facebook/react-native/pull/51695
Test Plan:
1. Pull the [reproduction demo](https://github.com/vladimirivanoviliev/rn079eventcrash), install the dependencies (v `0.80` is on PR)
2. Run codegen on android
3. Build signed apk. To create it you will need to create new demo key-store.
4. To install the build apk in 32bit mode you can use `adb -s YOURDEVICE install --abi armeabi-v7a android/app/release/app-release.apk`
5. Run the app, create key, save it. Than update the key and save it again. The app crashes when try to emit event from the turbo module.
6. Patch the related `JavaTurboModule.cpp` file with the changes from this PR and enable build from source.
7. Rebuild and reinstall the apk and test again - the issue is now fixed
## Additional notes:
I have tested the app on android using the `rn-tester` demo app, everything works as expected. I also patched our production app and tested more complex scenarios and they works as expected. I have run the tests and linter and they passed.
One thing that I didn't able to setup and run is the iOS `rn-tester` app, due to Hermes engine error `Command PhaseScriptExecution failed with a nonzero exit code`. I haven't found any information how to fix it. I have followed [this guide](https://github.com/facebook/react-native/blob/main/packages/rn-tester/README.md) and installed node modules using yarn and started the `yarn prepare-ios`. I also haven't found any information with what node version and ruby version the react native package is build on CI so I use the same versions locally. If you provide me with updated instructions for those I can contribute by updating the related guides and including `.npmrc`, `.ruby-version` files.
Reviewed By: cortinico
Differential Revision: D75782377
Pulled By: javache
fbshipit-source-id: b94998be6dd51e90ad4137b1d2e38a6850bc3cb2
Summary:
Fixes https://github.com/facebook/react-native/issues/51548
## 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
-->
[General][ADDED] Added more Pending Decleration for ScrollView
Pull Request resolved: https://github.com/facebook/react-native/pull/51613
Test Plan: Can be tested on RNTester with ScrollView
Reviewed By: cortinico
Differential Revision: D75516801
Pulled By: rshest
fbshipit-source-id: 87d6f68ab0a3ffd50af57b5eeaf313da4bf7ed98
Summary:
The retry mechanism introduced in [this commit]() works for iOS e2e failures but it is skipped if android e2e tests fails.
This change should fix that
## Changelog:
[Internal] - Fix retry for Android E2E tests
Pull Request resolved: https://github.com/facebook/react-native/pull/51684
Test Plan: GHA
Reviewed By: rshest
Differential Revision: D75719890
Pulled By: cipolleschi
fbshipit-source-id: 0c2a22268bb655617eaf27f61227a46650878b4e
Summary:
D75596329 disabled many, many rules that we previously explicitly enabled over the codebase, due to a specific rule causing crash in linter when specifically linting some files like RCTDeviceInfo.mm.
Let's revert the change, and remove the specific problematic rule from our list of manually enabled rules instead.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D75734557
fbshipit-source-id: 9d6ee401bfa5d1efc8de993d366839c740aa0bdc
Summary:
The Image component in Android now supports the same cache control behaviour as in iOS, the examples needed to be separated in the past because the support was not the same for iOS and Android, but now that it is, we can unify the example.
## Changelog:
[INTERNAL] - Unify RNTester Cache Policy Image example
Pull Request resolved: https://github.com/facebook/react-native/pull/51580
Test Plan:
<details>
<summary>RNTester Screenshots</summary>
| iOS | Android |
|--------|-------|
|  |  |
</details>
Reviewed By: yungsters
Differential Revision: D75538812
Pulled By: Abbondanzo
fbshipit-source-id: 7705c8f824cb18cebc39e84b6f48979035dc104c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51705
changelog: [internal]
use if/else instead of unordered_map to map types of nodes/drivers from string to a class. This is faster and improves binary size.
Reviewed By: javache
Differential Revision: D75676701
fbshipit-source-id: be9b8b646ebd9472382e6f692768b8fe9703d88f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51704
Changelog: [internal]
If you create a Fantom test that throws an error during its setup (not during the execution of specific tests), Fantom fails with an error saying there are no tests defined, which isn't useful.
This fixes the problem and shows where the error in the test setup happened exactly.
Reviewed By: javache
Differential Revision: D75689283
fbshipit-source-id: 54dd2382868dda0d284f46743ed94ba94aa3afdc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51702
We have no need for C++ bridging in this TurboModule, as the generated code matches the base codegen exactly.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D75681901
fbshipit-source-id: 4b6caafe0bcd08a06686e0a44112bdb99a64a1cf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51699
Re-expose **all `"./src/*"` paths via `package.json#exports`.
Follows D72228547 — as we'd attempted to be proactive with hiding `src/`, but are now reverting — essentially reducing this change as much as possible (read: most defensive/safer effect on OSS).
**Motivation**
Mitigates a warning emitted by Metro that may surface in new bare React Native template projects.
{F1978757796}
This is due to a 1P reference to `'react-native/src/private/featureflags/ReactNativeFeatureFlags` in `react-native/virtualized-lists`.
This is enough motivation to undo part of our change with introducing `"exports"` on `react-native` in 0.80.
**Especially**, to avoid confusion with other warnings we've intentionally introduced in 0.80 around subpath imports.
- The key difference is the above screenshot is from Metro and covers **any** import from any `node_modules` file — as opposed to just the immediate project.
Changelog:
[General][Changed] - Re-expose `src/*` subpaths when not using the Strict TypeScript API
The net breaking change for 0.80, once picked, is simply the presence of `"exports"` (only very edge case effects on expanding per-platform extensions, which we've mitigated). **All exported paths equivalent**.
Reviewed By: robhogan
Differential Revision: D75682566
fbshipit-source-id: f90c7298279c6be3a4eab70f2dfdc618ffcf1124
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51696
Changelog: [internal]
I realized that the Fantom module was being initialized before the execution of the test module itself (as part of the code generated by the runner), which could have problems if the test sets up the global environment that Fantom consumes. For example, if Fantom needs to use the `EventTarget` type from the global scope, it needs to wait until the initialization of the runtime so it can use it safely.
This refactors all the code calling into Fantom as part of our infra to always initialize it lazily, so the first thing that runs as part of the test execution is the test itself (apart from our test setup, which is supposed to be side-effect free).
Reviewed By: sammy-SC
Differential Revision: D75681181
fbshipit-source-id: 91e4b903a49fcee59c5875e73db314cde0adea03
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51697
changelog: [internal]
as a general rule of thumb, do not call outside of your class when holding a mutex. It is easy to cause a deadlock because the outside code may end up trying to acquire the mutex down the stack, leading to deadlock.
Here, it happens because `startRenderCallbackIfNeeded` may end up calling onRender and in onRender, we try to acquire the mutex again
Reviewed By: javache
Differential Revision: D75675465
fbshipit-source-id: 46168ee154a54ae5cccaa74728b41f027519db59
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51694
Changelog: [Internal]
D74820232 was missing an `exports` entry for `debugger-shell/package.json`, which is needed for some of our build tooling.
Reviewed By: hoxyq
Differential Revision: D75679347
fbshipit-source-id: 8deaf55ce354afcff410104948cad1b9a30093b7
Summary:
This React Native Android fix hardens the Fabric `InteropUiBlockListener` against `ConcurrentModificationException` crashes in `willMountItems` and `didMountItems`. By iterating over a shallow copy of the UI‐block lists and catching any mid‐iteration mutations, we ensure the listener never throws during a UI frame and always clears its pending blocks.
The issue was first reported in [React Native Issue https://github.com/facebook/react-native/issues/49783](https://github.com/facebook/react-native/issues/49783), and although [React Native PR#50091](https://github.com/facebook/react-native/pull/50091) was closed and not merged, the work in that PR did make it to React Native in [commit 17da3cb](https://github.com/facebook/react-native/commit/17da3cbbf4687f86226c4a80297c4d8abfc9c4f5). However, the fix didn't go far enough. We saw intermittent examples of this exception being thrown when swiping through a carousel from `react-native-reanimated-carousel`. This fix goes right to the exception site itself.
## Changelog:
[ANDROID] [FIXED] - Hardened the Fabric `InteropUiBlockListener` against `ConcurrentModificationException` crashes in `willMountItems` and `didMountItems`
Pull Request resolved: https://github.com/facebook/react-native/pull/51631
Test Plan:
The only way to test this is to develop a standalone app that emulates what we've been seeing in our commercially available RN app. We have done extensive testing of before (intermittent crashes) and after the fix (no crashes) and things have been standing up very well for us.
Here is a the Red Box we see right at the time of the crash, before this fix:
<img width="414" alt="image" src="https://github.com/user-attachments/assets/8d1b6c6d-42f7-48a0-9574-2f05436547d4" />
And here is the beginning of the logcat crash log:
```
2025-05-07 16:01:49.212 unknown:BridgelessReact com.aura.suite W ReactHost{0}.handleHostException(message = "null")
2025-05-07 16:01:49.212 unknown:ReactNative com.aura.suite E Exception in native call
java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:1111)
at java.util.ArrayList$Itr.next(ArrayList.java:1064)
at com.facebook.react.fabric.internal.interop.InteropUIBlockListener.willMountItems(InteropUiBlockListener.kt:72)
at com.facebook.react.fabric.FabricUIManager$MountItemDispatchListener.willMountItems(FabricUIManager.java:1235)
at com.facebook.react.fabric.mounting.MountItemDispatcher.dispatchMountItems(MountItemDispatcher.java:184)
at com.facebook.react.fabric.mounting.MountItemDispatcher.tryDispatchMountItems(MountItemDispatcher.java:122)
at com.facebook.react.fabric.FabricUIManager$3.runGuarded(FabricUIManager.java:820)
at com.facebook.react.bridge.GuardedRunnable.run(GuardedRunnable.java:29)
at com.facebook.react.fabric.FabricUIManager.scheduleMountItem(FabricUIManager.java:824)
at com.facebook.react.fabric.FabricUIManagerBinding.reportMount(Native Method)
at com.facebook.react.fabric.FabricUIManager$MountItemDispatchListener$1.run(FabricUIManager.java:1282)
at android.os.Handler.handleCallback(Handler.java:959)
at android.os.Handler.dispatchMessage(Handler.java:100)
at android.os.Looper.loopOnce(Looper.java:232)
at android.os.Looper.loop(Looper.java:317)
at android.app.ActivityThread.main(ActivityThread.java:8592)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:580)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:878)
```
All of this goes away with this fix. We're using React Native 0.79.2 and this is the first time we've open a PR for react-native. I hope this is enough info as far as testing goes.
Can we see a 0.79.x release with this fix, please?
Reviewed By: Abbondanzo, cortinico
Differential Revision: D75594791
Pulled By: javache
fbshipit-source-id: 982ae27e89756fdb290a24b0bdfa67c2e47c04e3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51688
Changelog: [Internal]
# Context
See D74904547.
## This diff
Creates the `react-native/debugger-shell` package, containing a basic implementation of an Electron-based shell for React Native DevTools. At this point, there is no direct dependency on the new package from the rest of React Native - it's designed to be used as part of a Meta-internal experimental rollout of the new debugger shell via the `BrowserLauncher` interface in `dev-middleware`.
Reviewed By: huntie
Differential Revision: D74820232
fbshipit-source-id: cb06ea9e2ed8c8822019cad8296cc19e69f9db0b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51687
Changelog: [Internal]
# Context
This is the first of several commits that aim to implement a **standalone shell for React Native DevTools**. This will be a lightweight desktop app designed to host the debugger frontend, in much the same way as we currently use Chrome or Edge. The launch flow will otherwise remain **very similar** to the one that exists today.
## What's changing for users?
1. With this commit, nothing; we're merely setting up an experiment flag (for stage 1 - Meta-internal testing) and will make separate plans for open source rollout, coordinated with our framework maintainer partners.
2. If the experiment is successful, we aim to *eventually* phase out the use of Chrome/Edge in React Native DevTools and ship the standalone shell as standard to all React Native developers. This is to enable further improvements that will rely on the standalone shell to work.
3. The first iteration of the standalone shell aims to solve some concrete pain points such as the "dead window problem" - the fact that opening DevTools multiple times for the same target will leave behind a now-dead window (that would ideally have been reused).
## This diff
We amend the `unstable_experiments` and `unstable_browserLauncher` APIs in `dev-middleware` to add basic support for launching a standalone shell based on a frontend URL and a *window key* - the latter being an opaque string that the shell process can match against previous launches in order to reuse and foreground existing windows.
We leave it up to `BrowserLauncher` implementers ( = frameworks) to provide a working implementation of `unstable_showFuseboxShell`, and do not provide one with `DefaultBrowserLauncher`. This will effectively allow us to dependency-inject the actual shell implementation at stage 1 so we don't increase the download size of React Native unnecessarily.
Reviewed By: rickhanlonii, robhogan
Differential Revision: D74904547
fbshipit-source-id: fbc6eac97923062bda8892bc130b39051845ea82
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51679
## Problem
I noticed that clang-tidy was crashing in some of our native modules.
This diff fixes the crash. And it blocklists all the warnings that got raised when I ran clang tidy for react native.
## Fix
This rule would crash clang tidy:
```
cppcoreguidelines-avoid-const-or-ref-data-members
```
I disabled it in the .clang-tidy file via:
```
-clang-analyzer-*,
```
## Why disable existing warnings?
We need to double check which checks make sense to enable for react native github. Until we have that understanding, I don't think we should prompt people to adjust their code. After we have that understanding, it should be really easy to enable the checks: just run the linter on react native, and fix the code.
Reviewed By: lunaleaps
Differential Revision: D75596329
fbshipit-source-id: 757a8d38f203d7fb4403bbda3703fda7b44923b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51676
Changelog: [internal]
This replaces all existing usages of `shadowNodeFromValue` (previously defined in `primitives.h`) to use the new bridging method to automatically convert `ShadowNode::Shared` from and to JS.
It also deletes the old method.
Reviewed By: javache
Differential Revision: D75597543
fbshipit-source-id: ab4e307dad80c7507b7ebd1cfa6621d020473d89
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51675
Changelog: [internal]
This defines a new bridging method to convert ShadowNode::Shared from and to JS. This has some benefits over the existing `shadowNodeFromValue` and `valueFromShadowNode` functions:
1. It's more convenient, as we can just use `ShadowNode::Shared` in classes implementing the codegen, and the runtime will do the conversion automatically.
2. It's safer, as it checks for nullability and throws JS exceptions except of having segmentation faults down the line.
Reviewed By: javache
Differential Revision: D75597542
fbshipit-source-id: 37c0c43cbde0f4de9a740d9da910f215ae50efbd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51660
We should be able to clean this up as we're not using it directly.
It would be used via the NDK logging utilities from Android, that we don't use.
Changelog:
[Internal] [Changed] -
Reviewed By: mdvacca
Differential Revision: D75531640
fbshipit-source-id: e96932b6e77b159683728194ac2e856cb868e06f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51671
Adds `flow` (or `noflow`) to all files in this directory and ensures that Flow succeeds (by adding type annotations, using minor refactors, or suppressing errors due to intentionally dynamic logic).
This will help improve type safety when making changes both in these files as well as files that these depend on.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D75581879
fbshipit-source-id: 6dcd8cc55d0021973eeae2670c1ebceb6d69fa8f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51669
Refactors the default mocks initialized in `packages/react-native/jest/setup.js` so that each mock is defined in its own file.
This provides several benefits, including:
- The ability to use `import` statements without worrying about eager initialization of dependencies before `globals` is setup.
- The ability to verify mocks export the same types as the actual module, using a new Flow-typed `mock` helper function.
- The ergonomic of implementing mocks with more complex logic, without having to split them out into a separate module (e.g. `mockModal`, `mockScrollView`).
As part of this migration, I also fixed any minor discrepancies to match the actual type definition. For more involved discrepancies (e.g. missing methods), I added type suppressions for now to minimize breaking changes.
Changelog:
[General][Changed] - Improved default mocking for Jest unit tests.
Reviewed By: javache
Differential Revision: D75575421
fbshipit-source-id: 98d60e10b753f1505ffdccf5f12f5d3ef306ebb5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51674
changelog: [internal]
just a clean up of code in AnimationDriverUtils and removal of unused headers.
Reviewed By: mdvacca
Differential Revision: D75549612
fbshipit-source-id: a8ad63622478d06318b6304b886554478b43d19b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51673
Fixes a lint warning that seems to inconsistently fire, by improving the code that it complains about.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D75583443
fbshipit-source-id: b6df191e2e51dee688df3f3c960704dea28a4ece
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51634
Creates an example in the ViewExample setup for how onBlur/onFocus behave when using keyboard navigation
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D75238317
fbshipit-source-id: e69122ca17727fc7f71e9bb7a09098a2771b098e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51570
As the title suggests: adds support strictly to `View` components on Android for `onFocus` and `onBlur` events. This is especially helpful for apps that respond to controller or remote inputs and aligns with existing support for the `focusable` prop.
In order to make this change cross-compatible with text inputs, `TextInputFocusEvent` has been deprecated in favor of the `BlurEvent`/`FocusEvent` types now available from core. Their type signatures are identical but `BlurEvent`/`FocusEvent` should be the type going forward for all views that intend to support focus/blur. Text inputs intentionally do not forward information about their state upon focus/blur and docs specifically call out `onEndEditing` as a means of reading state synchronously when blurring. Therefore, the changes to the native side to remove the event type specifically for text inputs is not breaking.
Changelog: [Android][Added] - Support for `onFocus` and `onBlur` function calls in `View` components
Reviewed By: mdvacca
Differential Revision: D75238291
fbshipit-source-id: b991d1f24fc094ba9d5d466201ecd058f59258e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51666
The platforms handle this in pretty different ways right now. Let's add a test showing the differences.
Android also adds a bunch of unicode zero width spaces in there...
Changelog: [Internal]
Reviewed By: mlord93
Differential Revision: D75567210
fbshipit-source-id: 98cac7d3fd23451868b55b69478e2667a2de3716
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51654
Facsimile may or may not use a global measure cache. Adding flags to let us run experiment, to understand real-world performance impact, now that we have fixed some (but not all) of the issues which may lead to measurement invalidation in Fabric.
Also does some quick cleanup th `SimpleThreadSafeCache` to remove the cache key as part of the lambda, which is never used, and makes this change mildly less efficient, and to accept lambda by generic type instead of repacking into std::function which has runtime overhead.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D75509799
fbshipit-source-id: 165c08d626ab1f2758f0203d3a0d527a1a5106a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51627
This cdhanges are inspired by https://stackoverflow.com/a/78314483 and they should help with the stability of E2E tests on main.
Most of the time, those tests fails because of flakyness in the E2E infrastructure on GHA. Usually, rerunning the tests manually makes the workflow pass.
These couple of jobs automatically reruns the workflow up to 3 times in case one of the E2E tests fails
## Changelog:
[Internal] - improve CI by rerunning the workflow if the E2E tests fails
Reviewed By: cortinico
Differential Revision: D75449445
fbshipit-source-id: d9c235c76007a3bda048ec76b62710ca930cf252
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51662
## Changes
DeviceInfo: Deafult fontScale to 1 when accessibility manager isn't available
# Analysis
**The problem:** For reasons that we don't understand, accessibility manager is sometimes nil, when deviceinfo needs it. This is a long-standing issue in react native.
```
_constants = @{
@"Dimensions" : [self _exportedDimensions],
// Note:
// This prop is deprecated and will be removed in a future release.
// Please use this only for a quick and temporary solution.
// Use <SafeAreaView> instead.
@"isIPhoneX_deprecated" : @(RCTIsIPhoneNotched()),
};
```
```
- (NSDictionary *)_exportedDimensions
{
RCTAssert(!_invalidated, @"Failed to get exported dimensions: RCTDeviceInfo has been invalidated");
RCTAssert(_moduleRegistry, @"Failed to get exported dimensions: RCTModuleRegistry is nil");
RCTAccessibilityManager *accessibilityManager =
(RCTAccessibilityManager *)[_moduleRegistry moduleForName:"AccessibilityManager"];
if (!accessibilityManager) {
return nil;
}
CGFloat fontScale = accessibilityManager ? accessibilityManager.multiplier : 1.0;
return RCTExportedDimensions(fontScale);
}
```
**The crash:** When accessibility manager is nil, device info tries to insert nil into an NSDictionary, and crashes.
We found a possible repro of this issue: [launch facebook, log out, and log back in](https://www.internalfb.com/diff/D72020801?transaction_fbid=982516293994114).
**Why this surged now:** Recently, we started initializing device info during react native init. That means this code-path just runs much more often.
# Mitigation
Remove the return nil in `[self _exportedDimensions]`. Instead, just default the fontScale to 1 when the accessibility manager isn't available.
**This should be safe:** If we assume that accessibility manager eventually becomes available, the fontScale will eventually become correct. Device info will send the updated fontScale to js when it becomes available: [native](https://www.internalfb.com/code/fbsource/[ec6fd664a9cd]/xplat/js/react-native-github/packages/react-native/React/CoreModules/RCTDeviceInfo.mm?lines=231-232), [js](https://www.internalfb.com/code/fbsource/[ec6fd664a9cd]/xplat/js/react-native-github/packages/react-native/Libraries/Utilities/Dimensions.js?lines=120-125).
# Long-term fix
Understand why accessibility manager is nil.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D75537894
fbshipit-source-id: 921cc573fdfd7e5c340ac3a4ada268caadb9e382
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51549
This is copied from `ReactTextView`, with a comment explaining the shenanigans.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D75248328
fbshipit-source-id: b325cf05e0000ee0b0c5fb82f0e7412a680e5d01
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51575
Before we were relying on absolute focus direction to determine the next focusable view inspired by Recycler View's implementation. This turned out to be inaccurate since FocusForward and FocusBackward do the ordering differently.
For FocusForward and FocusBackwards the children of the root node are ordered first from top to bottom then, row groups are created by getting views with the same vertical position and then everything else is sorted left to right.
Android creates an array with this order and then just focuses the next or previous element of this list. We don't do this but now FocusForward and FocusBackward follow the some comparisons used to build this array on Android.
Also, there was an issue with nested children within an accessible view, this just needed a bit of refactor on the focusSearch function so that we can tell when we actually need to trigger our custom focus search
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D75301251
fbshipit-source-id: 93b708092299afa778ba5938b093c2c38209b497
Summary:
Adds `flow` (or `noflow`) to all files in this directory and ensures that Flow succeeds (by adding type annotations, using minor refactors, or suppressing errors due to intentionally dynamic logic).
This will help improve type safety when making changes both in these files as well as files that these depend on.
Changelog:
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/51652
Test Plan:
Ran Flow and Jest tests successfully:
```
$ yarn flow
$ yarn test
```
Ran a Jest unit test internally to make sure they work with our internal environment setup:
```
$ cd ~/fbsource
$ js1 test /View-test.js
```
Reviewed By: javache
Differential Revision: D75488160
Pulled By: yungsters
fbshipit-source-id: 536cef9699acfa1edcd3dcf61c53ebcd92f560f9
Summary:
This PR adds a new cloning method, allowing for updating multiple nodes in a single transaction. It works in two phases:
1. Find which nodes have to be cloned (i.e. nodes given on input and all their ancestors)
2. Clone nodes in the bottom up order - so that every node is cloned exactly once
So the idea is that when we want to update all the red nodes in this picture, we first find the nodes in the green area and the clone only them in the correct order (children are cloned before parents):
Adapting this method [brought a huge performance gain to reanimated](https://github.com/software-mansion/react-native-reanimated/pull/6214). I want to upstream it, so that:
1. we can optimize it further, because making it a part of the `ShadowNode` class gives us access to the parent field in `ShadowNodeFamily` so we can traverse the tree upwards, allowing for a optimal implementation of the first phase (in reanimated we repeatedly call `getAncestors`, which revisits some nodes multiple times)
2. the community can use it
A naive approach that calls `cloneTree` for every node is much slower, as it has to repeat many operations.
## Changelog:
[GENERAL] [ADDED] - Added `cloneMultiple` to `ShadowNode` class.
Pull Request resolved: https://github.com/facebook/react-native/pull/50624
Test Plan:
I tested it with the following reanimated implementation and everything works fine:
<details>
```c++
const auto callback =
[&](const ShadowNode &shadowNode,
const std::optional<ShadowNode::ListOfShared> &newChildren) {
return shadowNode.clone(
{mergeProps(shadowNode, propsMap, shadowNode.getFamily()),
newChildren
? std::make_shared<ShadowNode::ListOfShared>(*newChildren)
: ShadowNodeFragment::childrenPlaceholder(),
shadowNode.getState()});
};
return std::static_pointer_cast<RootShadowNode>(
oldRootNode.cloneMultiple(families, callback));
```
</details>
I would like to add tests for it, but I'm not sure what's the best approach for that in the repo.
Reviewed By: mdvacca
Differential Revision: D75284060
Pulled By: javache
fbshipit-source-id: 0704c4386c3041eb368adf6950d46de197479058
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51657
changelog: [internal]
Introduce a new ShadowNodeTraits: `Unstable_uncullableView` and `Unstable_uncullableTrace`. As the name suggests, this is not stable API yet.
When a shadow node sets this trait, it will be opted out of view culling together with its ancestors all the way to the root.
The trait is propagated to its parent in 4 different places:
1. When node is first created.
2. When node is cloned.
3. When child is appended.
4. When child is replaced.
we can safely do it only in those places because React constructs nodes from bottom up. We are leveraging this implementation detail here but if that changes in the future, a traversal will be required.
Alternative solution considered here was a traversal of shadow tree during commit phase to propagate `Unstable_uncullable` trait. This could be done in a separate traversal or as part of layout phase where layout information is copied out of Yoga tree. Leveraging the fact that React is cloning bottom up makes the implementation simpler.
If React changes its cloning approach in the future, this will be caught by tests.
Reviewed By: lenaic
Differential Revision: D75476847
fbshipit-source-id: f1e98804565c140c64945662af0247b1bd0e1882
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51656
This fixes an issue with the internal networking layer when `enableModuleArgumentNSNullConversionIOS` is enabled, as we'd try to pass `NSNull` as trackingName instead of omitting it.
`
Changelog: [Internal]
Reviewed By: fabriziocucci
Differential Revision: D75516619
fbshipit-source-id: 91a3bba32772fdd66edde1e24b7edd977918f727
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51639
changelog: [internal]
### Fix Crash in View Culling
This diff fixes a crash that occurs when a view is unflattened or flattened in a deep hierarchy where each node has a top offset.
The problem is that nodes passed to *calculateShadowViewMutationsFlattener* via argument *unvisitedOtherNodes* have their positions calculated in a different coordinate space and the view culling algorithm does not have the correct data to determine visibility of a node. To fix this, we pass another argument to *calculateShadowViewMutationsFlattener* which does have original view culling context with which these nodes had their position calculated.
Reviewed By: javache
Differential Revision: D75455704
fbshipit-source-id: 925f14dfdc6c2b669c89e100629291921f27cd1e
Vladimir Iliev
riteshshukla04
Riccardo Cipolleschi
Nick Gerleman
Mateo Guzmán
Sam Zhou
Samuel Susla
Rubén Norte
Pieter De Baets
Alex Hunt
Moti Zilberman
Jay Koutavas
Ramanpreet Nara
Nicola Corti
Ruslan Lesiutin
Tim Yung
Peter Abbondanzo
Jorge Cabiedes Acosta
Bartłomiej Błoniarz
Arthur Kushka