Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49824
The way this works is each element on the list of `accessibilityElements` says that each element should go before the next element in its list. For example:
Imagine the default focus order:
```
[A, B, C, D, E]
```
If I set `accessibilityElements` to be:
```
[E, D, C, B, A]
```
That's just re ordering the focus order to be reversed, but what happens if I miss elements?
If I set `accessibilityElements` to be:
```
[D, B]
- D should go before B
```
Then my resulting order will be:
```
[A, D, B, C, E]
```
Because we follow the default order, then we find `B` but `D` should go before `B` so we first go to `D` and then finally go back to `B` and then continue our default order
This algorithm works with nested elements and it doesn't need to be exhaustive
We are also borrowing the concepts of Containers and elements from iOS.
We will disable views according to iOS logic to facilitate code shareability
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D70129295
fbshipit-source-id: 5ada03c7e5eb71a7b0a9d205296c2fa4366a3643
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50080
I'm renaming ReactNativeFeatureFlagsProviderHolder -> ReactNativeFeatureFlagsJavaProvider to make naming consistent with documentation and remove the concept of "Holder" which is not part of the original design
changelog: [internal] internal
Reviewed By: rubennorte
Differential Revision: D71333170
fbshipit-source-id: be89c3aafe5d9b1c9699aff224c7c8511bdf9327
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50180
Prepare for the change that makes `React.ComponentType` an alias of `component(...Props)`, which comes with stricter checking and making the props automatically readonly.
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D71566900
fbshipit-source-id: cefcc10fda9a9777532f25b325412b0d50ebb9b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50106
## Changelog:
[General] [Added] - Create TurboModuleWithJSIBindings interface
So c++ TurboModules can initialize some private members with reference to `jsi::Runtime`
Reviewed By: lenaic
Differential Revision: D71396842
fbshipit-source-id: 59d32e4cbf2c5081912a4c828acc66ceb8702855
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50158
Compile-out UIManagerModule from FpsDebugFrameCallback
The setViewHierarchyUpdateDebugListener does not exists on Bridgeless and NotThreadSafeViewHierarchyUpdateDebugListener is deprecated and marked for deletion on the new architecture.
The new architecture exposes a different API called ItemDispatchListener that's a sort of replacement for NotThreadSafeViewHierarchyUpdateDebugListener. Although it's not the same.
FpsView is broken in old/new arch and needs to be rebuild, I believe this behavior needs to be rethinked in the future. For now I'm excluding usages of NotThreadSafeViewHierarchyUpdateDebugListener and setViewHierarchyUpdateDebugListener for apps running on the new arch enabled by default.
changelog: [internal] internal
Reviewed By: rshest
Differential Revision: D71050642
fbshipit-source-id: 662deb064ffc2322b560618fac3203ab4e86c277
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50164
Based on analysis this method is only used by legacy architecture, this diff adds an assert if NativeModuleRegistry.onBatchComplete() is used in new architecture
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D71050638
fbshipit-source-id: 7a9791230880d2431e6b136735653a8ab4c34d7d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50160
In this diff we are removing UIManagerModule from NativeAnimatedModule
This code wasn't executing when fabric is enabled, with this change the code that references UIManagerModule will be stripped out
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D71050641
fbshipit-source-id: fbedd5b9e1a9efb45c2fb7558d97fc639897c28c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50157
UIManagerType.DEFAULT is becoming confusings As we are expanding the usage of the New architecture everywhere.
That's why I'm depreacting this constant and introducing UIManagerType.LEGACY.
changelog: [Android][Deprecated] Deprecate UIManagerType.DEFAULT, replaced by UIManagerType.LEGACY
Reviewed By: alanleedev
Differential Revision: D70738948
fbshipit-source-id: 9793a6cce3b931f9c0de4e0c2026852119f392b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50172
This specific warning is only for React Native users.
We don't need this warning on console for RNtester so I'm excluding react-native-github
project from the list of project where this warning gets fired.
Changelog:
[Internal] [Changed] - Do not warn for JSC deprecation on react-native-github
Reviewed By: mdvacca
Differential Revision: D71556035
fbshipit-source-id: 8ab625eb2c090416119903dbc9c29afac51c91bd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50104
Changelog:
[General][Internal] raises an event report when an attempt to open the debugger for not supported apps is made
Reviewed By: robhogan
Differential Revision: D71398802
fbshipit-source-id: 66b90a0286ee0844ced4319381e3a0581ce540b5
Summary:
fix: https://github.com/facebook/react-native/issues/50132
The goal of this PR is to ensure selected TextInput scrolls to the selected range when text or selection change.
The background of this feature check is to implement a rich text editor.
## Changelog:
[IOS][FIXED] - Selection range not respected when changing text or selection when selection is forced
Pull Request resolved: https://github.com/facebook/react-native/pull/50166
Test Plan:
Tested with the sample linked to this pull request.
As TextInput is a controlled component
Here is a video of the sample with the patch: https://drive.google.com/file/d/1lS9_70quNqND_E8MjLFcRG6HoHcDkfmv/view?usp=drive_link
First TextInput shows the initial issue reported in the ticket.
Second TextInput shows the global behavior of the controlled component, the 2 buttons allows to force focus and the force text values
I have also backport this part on 0.77.1 and test it in my app, it works fine for me (let's see if I have QA feedback)
Reviewed By: javache
Differential Revision: D71544064
Pulled By: cipolleschi
fbshipit-source-id: ca49a3a2ca0f5f87307054efda31b0c779c31496
Summary:
Expose eager initialization method on `RCTRootViewFactory` (iOS) so that application can prepare `ReactHost`/Bridge before actually creating a root view. Then creating a root view is significantly faster.
## Changelog:
[IOS] [ADDED] - allow eager initialization of `RCTRootViewFactory`
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/49986
Test Plan:
Invoke `initializeReactHostWithLaunchOptions:` before calling `viewWithModuleName:` and measure the time difference vs not using eager initilization:
Before
- calling `viewWithModuleName:`: 63.39ms, 47.91 ms, 60.18ms
After:
- calling `initializeReactHostWithLaunchOptions`: 52.41 ms, 81.03 ms, 60.52 ms
- calling `viewWithModuleName`: 0.49 ms, 0.63 ms, 0.47 ms
Test run 3 times on iPhone simulator on M1 mac.
Reviewed By: javache
Differential Revision: D71548601
Pulled By: cipolleschi
fbshipit-source-id: 86ecfb8bec4c2657537caf32af49545b21d3656b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50131
Outlines and stubs methods on the `NetworkReporter` class, and the `Network.getResponseBody` CDP request on `NetworkIOAgent`. Together, these form the APIs to implement for CDP network debugging.
Also updates internal mutex use to `std::atomic<bool>`.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D70708526
fbshipit-source-id: f44bd0d246a38883dd591752fb2d3ed4567de4a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50115
## Rationale
Rendering can now include main -> js sync calls.
If we allow js -> main sync calls during rendering, react native can deadlock.
So, this diff moves the js -> main sync calls to "main queue module setup", which occurs before rendering.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D71348561
fbshipit-source-id: 1c57ba1d40b062712fd53b9dac0bc8ecd60b425d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50113
## Rationale
Rendering can now include main -> js sync calls.
If we allow js -> main sync calls during rendering, react native can deadlock.
So, this diff moves the js -> main sync calls to "main queue module setup", which occurs before rendering.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D71348559
fbshipit-source-id: 918f145d817866a5d08087c1a4a0e151f783109e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50112
## Rationale
Rendering can now include main -> js sync calls.
If we allow js -> main sync calls during rendering, react native can deadlock.
So, this diff moves the js -> main sync calls to "main queue module setup", which occurs before rendering.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D71347448
fbshipit-source-id: f62a92a35011a7c8de0a7ee35047cc94f23106d1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50109
## Rationale
Rendering can now include main -> js sync calls.
If we allow js -> main sync calls during rendering, react native can deadlock.
So, this diff moves the js -> main sync calls to "main queue module setup", which occurs before rendering.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D71347449
fbshipit-source-id: 1fa010fd08a2d0b809f36a4c8df973b86e4610f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50111
## Rationale
Rendering can now include main -> js sync calls.
If we allow js -> main sync calls during rendering, react native can deadlock.
So, this diff moves the js -> main sync calls to "main queue module setup", which occurs before rendering.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D71480047
fbshipit-source-id: e36a4dd317bbbf46a6766f01fbf4d69a83a45c17
Summary:
We will use main queue setup of native modules to solve this problem instead.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D71341038
fbshipit-source-id: 77e2064c732a5572d063a240f769fa7a79530f1b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50040
This diff implements main queue module setup.
Sometimes, people need to capture uikit things, and use them from javascript. In those cases, people can write main queue modules. These modules will be eagerly initialized on the main queue, during react native init.
## On Necessity
**Sync** dispatches to the main thread from the js thread can deadlock react native. And **async** dispatches to the main thread from the js thread sometimes might not be enough: it could lead to flickery rendering. So, we need to allow people to capture ui thread things, before any js executes.
## Caveat
This api is dangerous and discouraged. All react native surfaces will pay the cost of one surface introducing a main queue module. It could also slow down common/critical interactions in your app, if you're not careful.
We will introduce performance logging for this infrastructure. So that we can monitor and file tasks, when main queue module init starts taking "too long."
Changelog: [General][Breaking]: Introduce beforeload callback arg into ReactInstance::loadScript
Reviewed By: mdvacca
Differential Revision: D71084243
fbshipit-source-id: 8fdb84761ac69468afc428f4f79eff6322449e3c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49957
## Changes
This diff introduces the api for "main queue modules" into turbo modules.
This will occur occurs before any rendering.
## Rationale
Rendering can now include main -> js sync calls. If we allow js -> main sync calls during rendering, react native can deadlock.
With this diff, we can move the js -> main sync calls to before any rendering happens.
## APIs
**Buck API:**
Plugin:
```
react_module_plugin_providers(
name = "AccessibilityManager",
native_class_func = "RCTAccessibilityManagerCls",
unstable_requires_main_queue_setup = True,
)
```
**OSS API:**
[codegenConfig](https://reactnative.dev/docs/the-new-architecture/using-codegen) in package.json:
```
"codegenConfig": {
"name": "<SpecName>",
"type": "<types>",
"jsSrcsDir": "<source_dir>",
"android": {
"javaPackageName": "<java.package.name>"
},
"ios": {
"modules": {
"AccessibilityManager": {
"className": "RCTAccessibilityManager",
"unstableRequiresMainQueueSetup": true
}
}
}
},
```
Changelog: [iOS][Added] Introduce unstableRequiresMainQueueSetup api to modules
Reviewed By: cipolleschi
Differential Revision: D70413478
fbshipit-source-id: 78d89437c2869a979ae5c94f08b01087686dfae7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50140
Extends `react-native-codegen` to support the `.fb` filename suffix used to gate source code that is only relevant for Meta internal use cases.
Changelog:
[Internal]
Reviewed By: cipolleschi
Differential Revision: D70808462
fbshipit-source-id: a6772d6504f76724b8474df6799bc69a76a2f81b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50147
Noticed a couple bugs here, around a crash from assertion internal to the caching map which hashes on the AttributedString, that may or may not be related.
1. We are missing `baseTextAttributes` for both hashing and equality (which is mostly innocuous, but still wrong)
2. We were not hashing or comparing `textAlignVertical`
3. For equality, we were comparing parent shadow view tag and metrics, but for hashing, we were hashing the whole ShadowView.
I think #3 could cause issues, since we could see different hash despite equality, which could break invariants.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D71500246
fbshipit-source-id: 462749d5ca10d10bf0dab88089253a2bb8e603fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50139
adding this event to Pressable because it is going to be consumed after to track if pressable location is moved
Changelog:
[General] [Added] - Expose `onPressMove` as base prop for `Pressable`
Reviewed By: thurn
Differential Revision: D71429258
fbshipit-source-id: 79acaa735764a47a21d89042d3e4b9c114c72950
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50117
D70870978 failed the compat check because it modified a union by removing an element in the middle:
```
'global' | 'self'
```
from
```
'global' | 'application' | 'self'
```
This caused the compat check to complain that index 1 in both unions: `self` didn't match `application` and thus it was a type incompatibility.
We should have been comparing these as an unsorted array of options, which first sorts, then treats differences as added/removed elements instead of incompatbile elements.
If in the example above the removed element was the last one from the union, it would have been fine.
Once these are classified as added/removed, the VersionDiffer is able to check whether that change is allowed in fromNative or toNative.
Changelog: [General][Fixed] Compatibility Check: Allow union changes when the new element is in the middle of the union
Reviewed By: makovkastar
Differential Revision: D71433054
fbshipit-source-id: 20a73f0ba0576daf30cec97bae969b31baf7f468
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50135
We settled on a different name here so gotta change some code with the old name. This is not exposed yet so this change is chill
Changelog: [Internal]
Reviewed By: jorge-cab
Differential Revision: D71471884
fbshipit-source-id: c30384802ef51e5aae830b27299859db05f2520b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50075
This is an exploratory change to see how it will look like to build core from SPM.
In this change we are building three pieces of React native (using the Podspec names for simplicity):
- React-jsi
- React-debug
- React-logger
- React-MapBuffer
They depends on a local ReactNativeDependency.xcframework we can build using the prebuild-io script.
## CHANGELOG:
[INTERNAL] - set up initial Swift PM configuration
Reviewed By: cortinico
Differential Revision: D70567840
fbshipit-source-id: 3f65a3e7c3dd39f71f6d4c04726712a5968e0a97
Jorge Cabiedes Acosta
Mateo Guzmán
Ramanpreet Nara
David Vacca
Sam Zhou
Zeya Peng
Nicola Corti
Vitali Zaidman
Olivier Bouillet
Maciej Jastrzębski
Alex Hunt
Eric Rozell
Riccardo Cipolleschi
Tim Yung
Nick Gerleman
Yurii Nakonechnyi
Regina Tuk
qnnp
Eli White
Joe Vilches
Jakub Piasecki