Summary:
Spotted a few errors in Codemod that migrated bridge.networking calls to [_moduleRegistry moduleForName:"Networking"] calls. This diff fixes those mistakes.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25499699
fbshipit-source-id: 29f296fc1011cf65d30e083e0ef001e3185edbfb
Summary:
All NativeModules that access the _bridge from self to require the Networking NativeModule now instead get the Networking NativeModule from the _moduleRegistry.
NOTE: xbgs .networking reveal any other usages. So, there won't be a manual migration diff associated with this codemod.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25499412
fbshipit-source-id: 7b0e33135c6c91ffc1e041ad3ab95f1346a8bc22
Summary:
All NativeModules that access the _bridge from self to require the ImageStoreManager now instead get the ImageStoreManager from the `_moduleRegistry`.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25498774
fbshipit-source-id: 1d97888ed2ef8d295aa35cf08cb9e9f3bc33ed05
Summary:
We currently spam the log with verbose state change messages by default.
These messages are really only useful for internal Inspector
development, so turn them off by default.
Changelog: [Internal]
Reviewed By: avp
Differential Revision: D25500449
fbshipit-source-id: 57e0901856f104be613f79de3b3ac9e3e95b2655
Summary:
Ship LayoutAnimations to 100% of users by removing feature-flag gating.
The `collapseDeleteCreateMountingInstructions_` stuff is always disabled for LayoutAnimations, so we can get rid of that too.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25510740
fbshipit-source-id: 71bac44f829530458e4906ecd1e7e68e766de2ec
Summary:
In preparation for flipping the default, marking autoglob as False in places where it isn't explicitly specified.
Changelog: [Internal]
Reviewed By: strulovich
Differential Revision: D25497305
fbshipit-source-id: 142e5caca2d67efcb3c25067a36934f7f6dd4b21
Summary:
Changelog: [internal]
Cloning of `LegacyViewManagerInteropViewProps` causes loss of `sourceProps.otherProps` if the cloning happens before shadow node is mounted. This was happening in WebView and callback `onLoadEnd` was dropped because of this.
Reviewed By: JoshuaGross
Differential Revision: D25474581
fbshipit-source-id: 74d7c5cd32b7318bb99306c82bc8b5e5eab63db2
Summary:
This is a followup to the issue described in D25477044, basically the TM cache can get messed up if `TurboModuleManager` is asked for "RCTNetworking" vs "Networking". This solves that issue globally.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D25480624
fbshipit-source-id: 2024560eadbcf58cdc3d7d5675b4120aa2fa2582
Summary:
While investigating a bridgeless networking issue, I noticed something very peculiar. **Two** networking turbo modules are built and used in bridgeless mode. Upon debugging, I realized that each of them have a different `TurboModuleHolder`. The reason is the following:
1. In JS, the module's name is [Networking](https://fburl.com/diffusion/f2xu4wie)
2. In ObjC, we call the module "RCTNetworking" (examples in this diff)
3. Both scenarios end up creating the correct Turbo Module: [RCTNetworking](https://www.internalfb.com/intern/diffusion/FBS/browsefile/master/xplat/js/react-native-github/Libraries/Network/RCTNetworking.mm?link_ref=search), but the `TurboModuleHolder` doesn't know that "RCTNetworking" and "Networking" are the same. Any other modules accessed this way will have the same issue.
An alternative solution would be to tell `TurboModuleHolder` to strip the `RCT` suffix, which would solve the problem globally. RSNara thoughts?
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D25477044
fbshipit-source-id: 02219de578ef4d19e579110e4242883a30cefcd6
Summary:
This is an extension of D25449795. I searched for all usages of .eventDispatcher within NativeModules, and migrated them all to the Venice-compatible RCTModuleRegistry API.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25473844
fbshipit-source-id: 2b8deec236e019f3adfb59fadd745c249ff822f4
Summary:
All NativeModules that use the bridge to require the eventDispatcher are now instead using the RCTModuleRegistry I introduced in D25412847 (https://github.com/facebook/react-native/commit/0ed81b28d3d786ea3b1cf0b932a008ef1f806ec4).
## What does this codemod do?
For all ObjC files that contain `synthesize bridge = _bridge`, migrate calls that access the React Native bridge from `self`, and use it to load the event dispatcher.
**Thoughts on Codemod Safety:** If we can access the bridge from self, then that means that if we synthesize the module registry, we can access the module registry from self. Therefore, this codemod is safe.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25449795
fbshipit-source-id: 2f7235d14659e73d673ae08763dc2cccdde55a19
Summary:
This should be a noop. It just makes writing codemods easier.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25442218
fbshipit-source-id: dba0c35a6f566e83ed5b7142075fff6929efeada
Summary:
The bridge now creates the RCTModuleRegistry, and assigns it to all NativeModules it creates.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25414108
fbshipit-source-id: 81c6a05bde0e52cff8ed60297f27d8aa3ff15a87
Summary:
NativeModules and TurboModules should use this API to lookup other NativeModules/TurboModules.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25414341
fbshipit-source-id: d8fab3d1b30b940fc5d1faa56bf195b9fda8d377
Summary:
## Problem
Many of our NativeModules are TurboModule-compatible. All our TurboModules currently use the bridge to require other NativeModules/TurboModules. As we migrate more surfaces to Venice, this lookup in many of these TurboModules will break, because the bridge will be nil.
## Initial Solution
We migrate all these TurboModules over to the turboModuleRegistry. In FBiOS, this will work because all NativeModules are TurboModule-compatible, and should [have the turboModuleRegistry attached to them by the TurboModuleManager](https://fburl.com/diffusion/d747fbc3). However, this solution has a few problems:
- If the TurboModule is used within a TurboModule-disabled app, it will break, because turboModuleRegistry will be nil on the module. Therefore, this solution isn't portable/flexible across apps.
- Longer term, we should deprecate synthesize bridge inside NativeModules. With this approach, we can't remove the synthesize bridge = bridge call from the NativeModule.
## Suggested Solution
Both NativeModules and TurboModules will be given access to an `RCTModuleRegistry` object. The RCTModuleRegistry object will use the TurboModuleManager when available and the Bridge when available to query for NativeModules and TurboModules. Otherwise, it'll just return nil.
When we do a lookup via this RCTModuleRegistry:
- In Venice, the bridge will be nil, so we won't search the bridge.
- In FBiOS, the bridge and the TurboModuleManager will be non-nil, so we'll first search the bridge, and then the TurboModuleManager.
- In standalone apps, the TurboModuleManager will be nil, so we'll only do a lookup on the bridge.
Long story short, RCTModuleRegistry will do the right thing in all scenarios.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25412847
fbshipit-source-id: 13f41276158d90c68ab4925e518d71a2f369c210
Summary:
This fix is still a little hypothetical. We have a few different JS errors that we're seeing with bridgeless mode that seem to be caused by Fabric trying to access `__fbBatchedBridge` from C++. I think what's happening is:
1. User encounters an unrelated JS error very early in rendering a new surface (possibly while the bundle is still loading?)
2. In release builds, BridgelessReactFragment handles the error by stopping the surface and rendering a retry button (actually, the surface is stopped in a bunch of places in BaseFbReactFragment, which might be why this is popping up now - I recently refactored that class to share more of its logic in bridgeless mode)
3. Fabric stops the surface by first checking to see if the custom binding `RN$stopSurface` exists; if not, it falls back to calling the registered callable module `ReactFabric`.
I think #3 is where things are going wrong for bridgeless mode; if you call stopSurface before `RN$stopSurface` is installed (which happens when ReactFabric shim is required) then you'll fall back to the bridge version.
My solution here is to instead rely on a flag set in C++ to determine whether we're in bridgeless mode, and then check to see if the stopSurface binding has been installed. If not, we just noop - if the ReactFabric shim hasn't been required, we probably don't actually have a React surface that needs to be stopped.
At least, that's my current theory. We'll see if this actually works.
Changelog: [Fixed][iOS] Fix an issue calling stopSurface in bridgeless mode before surface is started
Reviewed By: mdvacca
Differential Revision: D25453696
fbshipit-source-id: bff76675c43989101d0ba5ae0aba60089db230bf
Summary:
Some of the existing files under uimanager/ are self contained and used by the component codegen output. This commit split out those files into a dedicated uimanager/interfaces/ dir/target so that more targets can depend on it without causing dep cycle.
Also, the component codegen output doesn't need LayoutShadowNode at all, so this removed the import.
This will allow us to combine the Java codegen output for TM spec and Fabric components, simplifying build and dependency management (not in this commit yet).
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D25451409
fbshipit-source-id: 827545a3d78ebed1815cf9e52da2fa896b012aa1
Summary:
The flag `clipChildRectsIfOverflowIsHidden` has been set to false for a little over a year. Delete it and associated callsites.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25451696
fbshipit-source-id: a6067b2e25124f6bdef336c2ddead719dd44cca9
Summary:
In practice this has been enabled in production for months and is fine. Remove feature-flag and gating.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25451697
fbshipit-source-id: 9e70db3ed4e00de7b8295d9225d43ba09e4e68e9
Summary:
This has been true for 100% of users for months; clean up the old code.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25451470
fbshipit-source-id: feae59ce746869b9d84d6aaa69be10e91181f03a
Summary:
This code was useful for debugging T78035906 but is no longer needed.
I'm a bit conflicted about removing it, since such issues could crop up again in the future - but they're very rare, and hopefully now we know how to avoid them.
tl;dr: Make sure that mount instructions are not executed *during* a draw or measure.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25450846
fbshipit-source-id: e261f13db252d22773e373a5de744ecc8c380a43
Summary:
This code and this class isn't needed in Fabric, so don't create it during construction. Lazy-load it when it's needed outside of Fabric.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25450724
fbshipit-source-id: d14d8f03c194716f2aba0e499f3282ad2d1c1d29
Summary:
This commit:
* Generate Fabric component Java files along side Java NativeModule specs, when `USE_FABRIC=1` is set
* Adjust the component codegen to place output files in a subdir based on package name
* Adjust existing Buck targets to filter the right nativemodule vs component java files (this avoids duplicated symbols)
* Compiles the Java output during build time on RNTester/ReactAndroid (Gradle)
Not in this commit:
* Fabric C++ files
* Removing checked-in generated component files.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25416614
fbshipit-source-id: fd670ead2198c9b5a65812c692b7aed9f3d7cd58
Summary:
Changelog: [internal]
In D25386708 (https://github.com/facebook/react-native/commit/408bcdeedbc89cc9b90de73684d3f691b8e2e724) `synthesize bridge` was removed. But two modules actually depend on this.
`RCTFileReaderModule` and `VerseThreadView` which both use it.
Reviewed By: RSNara
Differential Revision: D25423574
fbshipit-source-id: daf95d9b27841cf8d205d8ea2666d5aa69a6d720
Summary:
This diff prevents the pre-calculation of ViewManager's constants for users with static view config enabled.
We still load viewManager classes and create viewManger objects for perf reasons
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D25414068
fbshipit-source-id: a91f6113e35b42625c03d13bd67b63e3f9f75098
Summary:
This is a codemod. All these NativeModules demand access to the bridge. However, they don't use it.
Changelog: [Internal]
Reviewed By: PeteTheHeat, RoelCastano
Differential Revision: D25386708
fbshipit-source-id: f05f4777d2527e96e53581e7ac58f6be47411dce
Summary:
There is partially compiled TurboModule code in [NativeAnimatedModule](https://fburl.com/diffusion/g91a70ng) that fails to build with:
`"File neither contains a module declaration, nor a component declaration. For module declarations, please make sure your file has an InterfaceDeclaration extending TurboModule. For component declarations, please make sure your file has a default export calling the codegenNativeComponent<Props>(...) macro"`
This diff removes react-native-web from the TurboModules logic while we work on a cleaner solution, tracked in T80868008
msdkland[metro]
Changelog: [Internal]
Reviewed By: cpojer, RSNara
Differential Revision: D25325163
fbshipit-source-id: 346abf52660073f976b0f978cbfbfc8402f4b3ee
Summary:
Cleanup release.gradle and remove code used to upload RN to maven repository, which is not longer used. Also removed configuration to include Javadoc, Sources in maven repo, thus reduce NPM package size.
## Changelog
[Internal] [Changed] - cleanup and remove maven upload from release.gradle
Pull Request resolved: https://github.com/facebook/react-native/pull/30468
Test Plan: you will no longer see *uploadArchives* in ./gradlew tasks. Also you can run **./gradlew :ReactAndroid:installArchives**
Reviewed By: mdvacca
Differential Revision: D25408128
Pulled By: fkgozali
fbshipit-source-id: b3ced1b466b9f11e3970136a116af4e29dbd33a1
Summary:
Added examples to RNTester for the AccessibilityInfo API for:
1. SetAccessibilityFocus()
2. isReduceMotionEnabled()
3. iOS Only
a. isBoldTextEnabled()
b. isGrayScaleEnabled()
c. isInvertColorsEnabled()
d. isReduceTransparencyEnabled()
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Added] - Add new examples to the Accessibility API page
Pull Request resolved: https://github.com/facebook/react-native/pull/30379
Test Plan: 
Reviewed By: TheSavior
Differential Revision: D25245329
Pulled By: rickhanlonii
fbshipit-source-id: e9c11c775410075199b4e1011b3dac0acd972e89
Summary:
When calling the original console methods we should set this to the value of the original console. Otherwise this can lead to different behaviour between when the debugger is enabled or not.
Changelog: [Internal]
Reviewed By: mhorowitz
Differential Revision: D25367929
fbshipit-source-id: 0a7b65e501d4460d5e09a7ccd3c38ef61fbd2ef0
Summary:
As part of the initialization of Native View configs, the PaperUIManager.getViewManagerConfig() method calls the native side to lazy initialize iOS Native components. This is necessaary to make ensure that native classes are loaded and initialized before a view is created.
Note that this requirement is only necessary when Fabric is disabled.
As part of JS ViewConfigs, we removed the native call to lazy initialize iOS native components. This causes a crash during the creation of NativeViews when JS ViewConfigs are enabled and Fabric is disabled. The rootcase of the exception is that native classes are not properly initialized when the createView method is executed in iOS.
This diff forces the lazy initialization of iOS Native components when JS View configs are enabled and Fabric is disabled. This new mechanism is executed as part of the creation of views and it's ONLY going to be executed when the user navigates to a NON-FABRIC screen, JS ViewConfigs are enabled and the component is not initialized yet.
The extra cost should be minimal or zero.
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D25387014
fbshipit-source-id: fe3bc42f803a805192b419bfb4b7a6b5b1b71b60
Summary:
Instead of doing a "containsKey then get", just get the rootViewTag and see if it's non-null. Theoretically, since it's a
concurrent data-structure, it could be removed from the ConcurrentHashMap between "containsKey" returning true and the "get".
This does not fix any known, existing problems.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25378703
fbshipit-source-id: 62a44e68e4443dac5a557263cc4bb33de9eea993
Summary:
There is an optimization in FabricUIManager.surfaceActiveForExecution that ensures it returns the same value (true or false)
for a given SurfaceId for a single frame (the value is cached until the next frame).
It seems like this can be causing a few different crashes, in a couple different ways:
1) If StopSurface is called off the UI thread, in the middle of a batch of operations (probably less likely to cause problems)
2) If StopSurface is called on the UI thread, in between different operations; the latter operations will still execute because the `true` value of `surfaceActiveForExecution` was cached.
I don't think that this optimization was providing much for us, and could be causing crashes. Remove it for now and we'll analyze impact on crashes and perf.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25379970
fbshipit-source-id: 2c15c971bd0c828e1d38a34662d93293271041b2
Summary:
The `BlobCollector` native module stored a `jni::global_ref` as a member,
and its destructor automatically destroys it.
However, as noted in JSI documentation, there is no guarantee that the destructor
is run on a JVM-registered thread. The destructor knew this and used a `jni::ThreadScope`
to do some other JNI behavior, but the global_ref needs to be destroyed during
that ThreadScope as well.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D25372698
fbshipit-source-id: f4eba0b2da154c6eac54d7faeb9ea5bb9260bec9
Summary:
The `index` parameter for UpdateMutation is optional, and is normally just -1. It's not useful, so remove it. `parentShadowView` is also not relevant and is not used; in some existing use-cases the actual parent view of the updated view is available, and in some contexts the parent view is not set.
The function now will always set the index to -1 for UpdateMutations, and `{}` for ParentShadowView.
This should have no impact on iOS or Android, as this parameter is not used. It could theoretically have an impact on lifetimes of objects retained (now not retained) by not passing parentShadowView into the mutation. For example, any shared props or state associated with the parent will not be retained in the Update mutation now.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25342943
fbshipit-source-id: 0ddbef76a6e2eefc2629c9729f721d8674d7737e
Summary:
UserFlow API now takes configuration parameter, which is required. It contains of 2 arguments:
* triggerSource
* cancelOnBackround
Reviewed By: swillard13
Differential Revision: D25094721
fbshipit-source-id: 64a468c2168265ade9f8d4cea4beb911637544fa
Summary:
Props are transferred from C++ to Java using ReadableNativeMaps. The current implementation of ReadableNativeMaps creates an internal HashMap the first time one of its methods is executed.
During the update of props ReadableNativeMaps are consumed only once and they are accessed through an Iterator. That's why there is no reason to create the internal HashMap, which is inefficient from performance and memory point of view.
This diff creates an experiment that avoids the creation of the internal HashMap during prop updates, additionally it removes a lock that was being used in the creation of the internal HashMap. I expect this change to have a positive impact in TTRC and memory (in particular for ME devices)
This diff reduces the amount of ReadableNativeMaps's internal HashMaps created during initial render of MP Home by ~35%.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D25361169
fbshipit-source-id: 7b6efda11922d56127131494ca39b5cec75f1703
Summary:
Add missing examples to ScrollView for RNTester.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Added] - Add missing examples to ScrollView for RNTester.
Pull Request resolved: https://github.com/facebook/react-native/pull/30454
Test Plan: There are a lot of examples that have been added that affects the UI (see RNCore Excel sheet for details).
Reviewed By: sammy-SC
Differential Revision: D25310613
Pulled By: rickhanlonii
fbshipit-source-id: 64a771aa8d3c3683eed983b0c36625078e5533fe
Ramanpreet Nara
Will Holen
Joshua Gross
Ron Edelstein
Samuel Susla
Peter Argany
Aditya Kumar
Emily Janzer
Hans Halverson
Kevin Gozali
Su Min Kim
David Vacca
Evan Gilbert
Dulmandakh
Dmitriy Shishkin
Martin Sherburn
Riley Dulin
Dmytro Voronkevych
Scott Ngan
