Summary:
This diff adds a NativeLogBox module implementation on Android to manage rendering LogBox the way we render RedBox, except rendering a React Native component instead of a native view.
The strategy here is:
- initialize: will create a React rootview and render it.
- show: will add the rootview to a dialog and display the dialog.
- hide: will remove the rootview from it's parent, dismiss the dialog, and release the reference to the activity to prevent leaks.
Most of this is copied from the way RedBox works, the difference here is that we eagerly initialize the rootview with the `initialize` function so that it's warm by the time the dialog needs to render.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18768517
fbshipit-source-id: 2510d6c186ccf73153ef9372c736c9e0c71bbc7d
Summary:
This diff adds a NativeLogBox module implementation on iOS to manage rendering LogBox the way we render RedBox, except rendering a React Native component instead of a native view.
The strategy here is:
- initialize: will create a hidden window (the way redbox does) and render the LogBox to it
- show: will show the window
- hide: will hide the window
Most of this is copied from the way RedBox works, the difference here is that we eagerly initialize the window with the `initialize` function so that it's warm by the time LogBox needs to render.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D18750008
fbshipit-source-id: 013e55ded55c8572bb08e0219ff4cd0060ebe0da
Summary:
UpdateLocalData and UpdateState return an `extra data` object, which in the case of TextInput contains padding. In Paper, the padding was always set on this object; in Fabric, it generally is not. However, the ViewManager was unconditionally setting the padding on the view, regardless of whether or not padding was set. We just check the padding values before setting now. This fixes an issue where the padding would be reset when the user started typing in Fabric.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18875261
fbshipit-source-id: d7cb87c07f47ab522e32cd34a4ca6ed5fea2e832
Summary:
In Paper this call causes Yoga to remeasure the tree. We don't need to do this in Fabric, and all the data contained in `ReactTextInputLocalData` is already set on the underlying EditText View.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18870491
fbshipit-source-id: a982a708b810d45f70ad4981a963bb4ae798c83c
Summary:
There are some code in native modules which currently throws exception when the host activity is not a FragmentActivity, even if the native module is not used. This change avoids the throw and fail the promise instead.
## Changelog
There are some code in native modules which currently throws exception when the host activity is not a FragmentActivity, even if the native module is not used. This change avoids the throw and fail the promise instead.
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/27425
Test Plan: We've tested the change on MS Office applications, which currently don't use FragmentActivity.
Differential Revision: D18873012
Pulled By: mdvacca
fbshipit-source-id: 1b7c9efba5a59b2051487510da9ef7e1232877a5
Summary:
Returning null from a NativeModule method that has a return type of `java.lang.Double` causes the program to crash. This diff instead makes that method call return `null` to JS. TurboModules already has this behaviour.
Changelog:
[Android][Fixed] - Support nullable returns NativeModule methods returning Boxed Primitives
Reviewed By: PeteTheHeat
Differential Revision: D18866872
fbshipit-source-id: 6049c4df6908f1d276c5674b7e06eb5e002a7976
Summary:
## Context
`NativeModuleRegistryBuilder` calls `TurboReactPackage.getNativeModuleIterator()` to access ModuleHolders for all the NativeModules in the `TurboReactPackage`. We then filter out the ModuleHolders that contain `TurboModules`, before using that list to make create the `NativeModuleRegistry`.
## Problem
Creating `ModuleHolders` has the side-effect of actually creating the NativeModule if it requires eager initialization. See [ModuleHolder.java](https://fburl.com/diffusion/4avdtio0):
```
class ModuleHolder {
// ...
public ModuleHolder(ReactModuleInfo moduleInfo, Provider<? extends NativeModule> provider) {
mName = moduleInfo.name();
mProvider = provider;
mReactModuleInfo = moduleInfo;
if (moduleInfo.needsEagerInit()) {
mModule = create(); // HERE!
}
}
```
So, we need to filter out TurboModules before we even create ModuleHolders.
Changelog:
[Android][Fixed] - Refactor TurboModule filtering in NativeModuleRegistryBuilder
Reviewed By: PeteTheHeat, mdvacca
Differential Revision: D18814010
fbshipit-source-id: a120d2b619b9280ba70e21d131dccc5a9fc6346d
Summary:
The TurboModuleManagerDelegate now supports a `getEagerInitModuleNames()` method, which is supposed to return a `java.util.List` containing the names of all NativeModules that require eager initialization. The NativeModuels are created when the `TurboModuleManager` is created. This happens inside `ReactInstanceManager.createReactContext` slightly after the NativeModuleRegistry is created, which is when our legacy NativeModules are eagerly initialized.
All NativeModules declared in `TurboReactPackages` that are wired into the `TurboModules` infra via `ReactPackageTurboModuleManagerDelegate` can use the `ReactModule(needsEagerInit = true)` annotation. Our build pipeline should correctly process the annotation into a `ModuleInfo`, and `ReactPackageTurboModuleManagerDelegate` should correctly forward the eagerly initialized module names to TurboModuleManager.
Changelog:
[Android][Added] - Implement TurboModule eager initialization support
Reviewed By: mdvacca
Differential Revision: D18819552
fbshipit-source-id: b2009a3b8f4e064362d2abeb5281637962531678
Summary:
When the TextInput is updated on the Java side, make sure C++ State gets updated. We do this by making sure that the AttributedString data-structured in mirrored in Java and in C++.
In practice, the AttributedString is copied into Java a few times during initialization, and then after then, 99% of the time Java is writing without receiving updates from C++. This means that we should optimize the Java-to-C++ update path most aggressively in the future.
However, it turns out that for now, at least, we can't reuse NativeWritableMaps/NativeWritableArrays because they're consumed on the C++ side and can't be modified after that. This is a perf improvement for the future.
This allows us the user to edit any fragments, and the changes will flow through C++ State. This also allows us to edit across multiple Fragments.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18785960
fbshipit-source-id: 97b283ec411081eca4d2d7a4cce2b31b5e237c42
Summary:
Fix and simplify `AndroidTextInputShadowNode::getAttributedString` so that it (1) works, and (2) is aligned with the equivalents in the old Java code.
The issue is that we weren't picking up `text` attributes since we're only traversing children and not the TextInput node itself. If a `text` attribute is present it needs to be treated as its own Text node.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18739830
fbshipit-source-id: 4b3bc81dbe8c241c2e06fe5be1f9b50e49132890
Summary:
Motivation: TextInput.js frequently sends commands to views as they're disappearing (`blur`, for instance).
We should fix that in the future, if possible. For now, just log the issue and continue. It shouldn't cause any user-facing issues since 1) it appears that TextInput knows the underlying view is gone; 2) the View has already disappeared so the user can't interact with it, so commands can go safely into the void.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18821448
fbshipit-source-id: 980dbbce8cdb2cc0bb4bf60b3bccc90869208f01
Summary: Making the open source NetworkingModule TM-compatible.
Reviewed By: mdvacca
Differential Revision: D18770987
fbshipit-source-id: 64966f91308e31bdcf9bfa959381d4e40ccb2753
Summary:
There are multiple `DoNotStrip` in Yoga java binding, they aren't needed.
##Changelog:
[Internal][Yoga] Allow redex to optimize more of yoga by removing unneeded DoNotStrip marks
Reviewed By: SidharthGuglani
Differential Revision: D17519844
fbshipit-source-id: 8b26800d720f34cae87754d85460abf88acbe713
Summary:
## Step 1
I'm going to make every Java NativeModule type-safe and TurboModule-compatible. The first step is to make sure that every type-unsafe NativeModule has a dependency on its spec's codegen target.
## Input
Module -> owner(Module): P123320255
Module -> name(Module): P123320256
Module -> owner(spec(name(Module))): P123320257
### Excluded NativeModules
NativeModules without Specs: P123320644
Java only NativeModules: P123320645
Changelog:
[Internal] - Add buck dependencies for NativeModule specs
Reviewed By: mdvacca
Differential Revision: D18781629
fbshipit-source-id: 89f39017b8224355d9d7b43bf6c162b0957760ee
Summary:
Changelog: [Internal] Remove Hermes heap tripwire cooldown parameter.
Delete all references to the cooldown parameter for Hermes's GCConfig, it is no longer
used (instead, the tripwire callback is called at most once per Runtime).
Reviewed By: JoshuaGross
Differential Revision: D18768200
fbshipit-source-id: e7a02ed59ad45e8e4d1b32b37d752076c40caf0b
Summary: Removing the methods I recently added for storing/retrieving an instance key on a ReactContext.
Reviewed By: PeteTheHeat, mdvacca
Differential Revision: D18710637
fbshipit-source-id: d34683ec660bd999db8112865e15392606fc9237
Summary:
When SourceCode was converted to a TurboModule in D17586276, we had to check in `NativeSourceCodeSpec` into the codebase. Since all the OSS NativeModule base classes are now checked into `react-native-github`, it's no longer necessary to keep `NativeSourceCodeSpec`. So, I'm deleting it.
Changelog:
[Android][Removed] - Delete com.facebook.react.modules.debug.NativeSourceCodeSpec
Reviewed By: PeteTheHeat, mdvacca
Differential Revision: D18732997
fbshipit-source-id: 6026b4bcb9ebb9c4d7ba556bc644698eb550a9de
Summary:
Added method which checks if value(methodId, fieldId, class ...) returned by JNI functions (getMethod, getField, getClass ...) is valid or not and throw exception if they are not valid
##Changelog:
[Internal][Yoga] Add defensive check for result returned after JNI calls
Reviewed By: astreet
Differential Revision: D18745718
fbshipit-source-id: 2af26eda15fbe7834e1c9b274deeed4f106274ab
Summary:
## Changelog:
[Internal][Yoga] Add YogaJniException class to be used later for jni exceptions
Reviewed By: astreet
Differential Revision: D18745609
fbshipit-source-id: 53503b54dbc59e9fe47f599dee6be9cb68134cb2
Summary:
Eventually, we want these to extend the abstract base class code-generated from the NativeModule spec. That base class extends `ReactContextBaseJavaModule`. So, this is a step in the right direction.
Changelog:
[Internal] Make ExceptionsManagerModule extend ReactContextBaseJavaModule
Reviewed By: PeteTheHeat, mdvacca
Differential Revision: D18718061
fbshipit-source-id: 70ba5c45b3ef1dd7602e1186763c8bc7ab5d4f42
Summary:
This diff re-throw and logs exceptions in the animated module of RN Android
Changelog: internal
Reviewed By: JoshuaGross
Differential Revision: D18694124
fbshipit-source-id: bb4cb56dce99f09c56b0bc62733e8264f2df5a3f
Summary:
This diff adds extra logging in the method that handles exceptions for RN Android
Changelog: internal
Reviewed By: JoshuaGross
Differential Revision: D18694123
fbshipit-source-id: e275445b65473ed55eec9d4b823938e32fa805e5
Summary:
In AndroidTextInput, support codegen'd ViewCommands in native and add three commands that will eventually replace usage of setNativeProps on Android.
TextInput will use these commands in a future diff.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D18612150
fbshipit-source-id: 5d427040686e8c5ab504dd845bc8ef863f558c35
Summary:
Use a similar setup as Paragraph, and support in Fabric:
- Correct measuring of AndroidTextInput
- Correct display of AndroidTextInput attributed strings
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18669957
fbshipit-source-id: 84e0ad8021c9edf8219e0c673c781276ca29787d
Summary:
We need to make our ExceptionsManagers into TurboModules. To do so, we need to first make them type-safe. This requires extending the base class code-generated from the NativeModule JavaScript spec. That base class extends `ReactContextBaseJavaModule`, which requires `ReactApplicationContext` to instantiate. Unfortunatley, our ExceptionsManagers need to be created before the `ReactInstanceManager`. This means that the `ReactApplicationContext` isn't available by the time they're created.
In this diff, I make the `ReactContextBaseJavaModule` have a 0 argument constructor that simply sets its ReactApplicationContext to null. This will allow us to eventually migrate our ExceptionsManagers to the TurboModule system.
Changelog:
[Android][Added] - Give ReactContextBaseJavaModule a 0 arg ctor
Reviewed By: mdvacca
Differential Revision: D18717908
fbshipit-source-id: 203ffc49f2ec0b32a809402801795879d3b3a64b
Summary:
R8 shows warning that **com.facebook.react.bridge.JavaScriptModule**, **com.facebook.react.bridge.NativeModule** are interfaces so proguard rules must use implements instead of extends. This PR changes proguard rules to fix the warnings.
## Changelog
[Android] [Changed] - Fix R8 warning
Pull Request resolved: https://github.com/facebook/react-native/pull/27291
Test Plan: RNTester builds and runs as expected.
Differential Revision: D18658704
Pulled By: mdvacca
fbshipit-source-id: a679643542bc55b89141f58c3236a29cf83c20d2
Summary:
We hope that will help us to understand more.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18599164
fbshipit-source-id: 431f83de707fc7113e04abd3dd5b59ee5c9cc675
Summary:
We recently realized that `JNativeRunnable` instances that RN uses to pass C++ callables to Java land actually are GC managed objects. That makes their lifetime quite unpredictable (longer than necessary). Normally, it's fine but some C++ code explicitly relies on deallocation order.
To make the behavior of `JMessageQueueThread` more predictable, now we clear/reset stored `std::function` object right after an invocation to explicitly free all associated resources (`JNativeRunnable` still holds some wrapper but that wrapper holds nothing).
Changelog: [INTERNAL]
Reviewed By: JoshuaGross
Differential Revision: D18603390
fbshipit-source-id: 362f6cc0901cbe14d3360b928c98e204d277b1aa
Summary:
We are rolling out exact-by-default syntax to xplat/js.
I had to manually move around some comments to preserve proper placement.
Changelog: [Internal]
Reviewed By: jbrown215
Differential Revision: D18633611
fbshipit-source-id: 48f7468dcc55b1d00985419d035a61c6820b3abe
Summary:
This diff introduces a new ReactFeatureFlag that will be used to enable / disable a custom implementation of getChildVisibleRect in the classes ReactViewGroup, ReactHorizontalScrollView and ReactScrollView.
The new ReactFeatureFlag is disabled by default bevause of T57363204
This is disabling the code landed as part of D17782658 / https://github.com/facebook/react-native/pull/26334
Changelog: Introduce ReactFeatureFlag to disable custom implementation of getChildVisibleRect (disabled by default)
This will disable the custom algorithm created on https://github.com/facebook/react-native/pull/26334
Reviewed By: yungsters
Differential Revision: D18621042
fbshipit-source-id: 35ca3417b596117b47edab29515a824c1726c2ce
Summary:
https://github.com/facebook/react-native/commit/4a69b3e636c479f39a997aec37f716afb3ab6150 changed the way the cpp files for yogajni are included but it doesn't work. I looked at other places where we are using `wildcard` and we need to add `LOCAL_PATH` otherwise the base path will be where this file is included initially, in this case the `react/jni` folder. This causes no cpp files to be included and the jni bindings are not initialized.
## Changelog
[Internal] [Fixed] - Fix yogajni build with gradle
Pull Request resolved: https://github.com/facebook/react-native/pull/27275
Test Plan: Tested that it builds properly and doesn't crash because of missing native implementation.
Differential Revision: D18633950
Pulled By: mdvacca
fbshipit-source-id: e229fffb53bc335d441060da3c5d4fd840a3c5b0
Summary:
RCTDevLoadingView wasn't hooked up to the codegen. This diff makes RCTDevLoadingView type-safe and also makes it TurboModule-compatible.
Changelog:
[iOS][Added] - Make RCTDevLoadingView TurboModule-compatible
Reviewed By: PeteTheHeat
Differential Revision: D16969764
fbshipit-source-id: 47e6682eea3fc49d3f0448c636b5f616d5bce220
Summary:
Changelog: [Internal]
Introduce native command `setNativeRefreshing`, it has the word Native in order to avoid name conflict with setRefreshing in Android implementation. Even this component is iOS only, it would make it easier to merge them in the future.
Introduce `RCTRefreshableProtocol` and make `RCTRefreshControl` and `RCTPullToRefreshViewComponentView` to conform to the protocol so view manager can forward command to both, Paper and Fabric component.
Reviewed By: mmmulani
Differential Revision: D18475804
fbshipit-source-id: 4c19225784efc931b7b8f2d2671cc839bce429bf
Summary:
Modifying ImageLoaderModule to be TM-compatible by extending the generated abstract class and fixing the conflicting method signatures (int -> double).
Changelog: [Android] [Changed] Changing method signatures for ImageLoaderModule to accept double for requestId
Reviewed By: mdvacca
Differential Revision: D18435628
fbshipit-source-id: bc2a82bda49e339d1feebfe917b0862a1af15a1f
Summary:
We read from / write to `CatalystInstanceImpl.mTurboModuleRegistry` from multiple threads. To ensure that we directly read/write from memory, and not a stale cache, we should make this variable `volatile`.
Changelog:
[Android][Fixed] Make TurboModuleRegistry in CatalystInstanceImpl.java volatile
Reviewed By: fkgozali
Differential Revision: D18542954
fbshipit-source-id: 0a47f05e0653b4f7f58503c678bdf31c68eab9bf
Summary:
This diff deprecates the constructors and getter method exposing CallerContext in ReactImageManager.
This will be replaced by the ReactCallerContextFactory class
Changelog: Deprecation of constructors and methods that expose CallerContext in ReactImageManager class
Reviewed By: JoshuaGross
Differential Revision: D18474012
fbshipit-source-id: d8190f938e00da0499bfef7e81522dc8022a8836
Summary:
This diff exposes the ReactContextContainerFactory class on ReactImageViewManager and it customize ChainContext to improve Fresco logging
Changelog: Expose new ReactContextContainerFactory class as part of ReactImageViewManager
Reviewed By: JoshuaGross
Differential Revision: D18474013
fbshipit-source-id: 143461da22966694e5b1e2c3b5b39e3d6be91fd6
Summary:
This diff exposes the surfaceID as part of ReactRootView.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18474014
fbshipit-source-id: 98f651b211d3cc4df88c6b1eb257bc12129eff57
Summary:
Document which methods can be called on UI thread or ANY thread.
In the future we should see if we can use only `ThreadConfined` or the AndroidX annotations instead of using both / choosing between them at each site.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18532542
fbshipit-source-id: 3b5406ea5035615a0ebf83484bf8ec0747a6b6f7
Summary:
This diff extends ThemeReactContext class to store the surfaceID field
The getSurfaceID method is being exposed as a public method
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18474015
fbshipit-source-id: ee1f859a802d36c51dec537fa91d90022523e88d
Lorenzo Sciandra
Rick Hanlon
Joshua Gross
Anandraj Govindan
Ramanpreet Nara
Eli White
Emily Janzer
Amir Shalem
Sidharth Guglani
Riley Dulin
Oleksandr Melnykov
David Vacca
Sergey Ryabov
Dulmandakh
Valentin Shergin
George Zahariev
Janic Duplessis
Samuel Susla
Emily Janzer