Summary:
I stumbled on this comment where the task was closed
Changelog: [Internal]
Reviewed By: lunaleaps, RSNara
Differential Revision: D18933260
fbshipit-source-id: 8d35e0fa19dc9aec7b811131318858c27c34accd
Summary:
This implements propagation of ScrollView's contentOffset value on Android. That allows `LayoutableShadowNode::getRelativeLayoutMetrics` (and some measure functions) return values that take that info into account.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D19027433
fbshipit-source-id: 023ff9642d023971b3d24d5cc5f7c2f4b443031e
Summary:
When in debug mode, PlatformConstants doesn't have a `ServerHost` constant. This wasn't captured by `NativePlatformConstants`.
Changelog:
[Android][Fixed] - Make sure ServerHost is optional in NativePlatformConstants.js
Reviewed By: rickhanlonii
Differential Revision: D19091270
fbshipit-source-id: 4b3ac73a4ab6111b3e433ecca01cc769e8cdec6b
Summary:
@public
With this, you can determine the packager location at run time before we even try to load the bundle.
Changelog: [Android] [Added] - Packager location can be determined at run time
Reviewed By: makovkastar
Differential Revision: D18940087
fbshipit-source-id: fac99f28e119a4e7a2961b5504cfe7d2d409e8f7
Summary:
We currently have a method in ReactContextBaseJavaModule that logs a warning if the native module is trying to access a ReactContext without an active Catalyst instance (because if you try to access it directly, it throws).
For bridgeless mode, we never have a CatalystInstance, but it's safe to call certain methods on the context that would normally require one. For this case, let's just return the context when the context is in bridgeless mode.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D19133988
fbshipit-source-id: cae0bd397aa24d9ad416491cbc32676870cc70b0
Summary:
The class was deprecated in 2016 and is blocking an upgrade to fbjni
which no longer supports the `Countable` class this extends.
Changelog:
[Android] [Removed] - NativeRunnableDeprecated
Pull Request resolved: https://github.com/facebook/react-native/pull/27529
Test Plan: No references to it in this codebase.
Reviewed By: mdvacca
Differential Revision: D19087074
Pulled By: passy
fbshipit-source-id: a4ee73be7c13cedf1d86d2643f8e788ad4a2e31f
Summary:
This diff fixes the redbox that is currently affecting initial render of RN Android apps
More details: https://fb.workplace.com/groups/rn.support/permalink/3125289967519597/
Changelog: [internal]
Reviewed By: JoshuaGross, ejanzer
Differential Revision: D19132862
fbshipit-source-id: 6833a32bae2e0dda254f1bd09520551aa41fa822
Summary:
All these NativeModules are now: (1) type-safe, (2) TurboModule-compatible.
**Note:** We still need to update `{Catalyst,Work,Fb4a}TurboModuleManagerDelegate` to understand these TurboModules. I'll most likely write up that diff and stack this one on top of it.
Changelog:
[Android][Added] - Make NativeModules TurboModule-compatible
Reviewed By: mdvacca
Differential Revision: D18888735
fbshipit-source-id: 34df64dc70e3f3a0a0303c049861205f9d3fd2ed
Summary:
For NativeModules that don't need to be accessed from JS, we can just have them implement the TurboModule interface. This is enough to make them be instantiated via the TurboModule system.
Changelog:
[Android][Added] - Make Java only NativeModules TurboModule-compatible
Reviewed By: ejanzer
Differential Revision: D18787789
fbshipit-source-id: d513006ffd736621adbd41146ed6280a60a7437e
Summary:
`Fb4a` and `Workplace` use only one product-specific `ReactPackage`, but `ReactInstanceManager` also installs `CoreModulesPackage` and `DebugCorePackage`. These two packages have NativeModules that got converted to the TurboModule system. So, I've added them to the `Fb4aReactPackagesTest` and `WorkReactPackageTest` to ensure that NativeModule conversions in framework-provided packages are also tested.
Changelog:
[Internal]
Reviewed By: PeteTheHeat
Differential Revision: D18974083
fbshipit-source-id: a98ec28a882ce51597a068ddecf43f5fbb6bfdc6
Summary:
The NativeModules in DebugCorePackage are now TurboModule-compatible. Therefore, we must make this extend `TurboReactPackage`.
Changelog:
[Internal] - Make DebugCorePackage a TurboReactPackage
Reviewed By: fkgozali
Differential Revision: D18974084
fbshipit-source-id: 648b54fefe7f8952666d5a23a9d81cc6bb167b31
Summary:
We're going to migrate our NativeModules to the TurboModule system soon. Therefore, it's no longer safe to assume that all NativeModules are not TurboModules. Also, it's not a good idea to hard-code this stuff if we can calculate the correct values on the fly.
Changelog:
[Internal]
Reviewed By: PeteTheHeat
Differential Revision: D18980859
fbshipit-source-id: 399a75a72d7f57998b217502ff79d7d911cc5a1c
Summary:
Google recommends to extend AppCompat widgets, and Android Studio suggests the change. This PR changes ReactEditText to extend AppCompatEditText.
## Changelog
[Android] [Changed] - ReactEditText extends AppCompatEditText
Pull Request resolved: https://github.com/facebook/react-native/pull/27039
Test Plan: CI is green
Reviewed By: mdvacca
Differential Revision: D18196901
Pulled By: hramos
fbshipit-source-id: 1484ae3da1be5776d0431dab3d4bb7ddbe5b8b7c
Summary:
This diff refactors ReactContext to use IllegalStateException instead of RuntimeException when applicable.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18901845
fbshipit-source-id: 51ec36824c8402fa2c17e76c55578be44ec8aa15
Summary:
This diff migrates a couple of events callsites of ReactRootView and ScrollView to be compatible with Bridgeless React mode
Changelog: [internal]
Reviewed By: ejanzer
Differential Revision: D18862857
fbshipit-source-id: f8e0d2d684bfaf84e9c138746507bb7728481b18
Summary:
ExceptionManagers are created before the `ReactApplicationContext`. Once we make them all TurboModule-compatible, they'll also subclasses `ReactContextBaseJavaModule`. This means that they'll need to be created with `ReactApplicationContext`. Since one isn't available, we'll have to call `super(null)` in their constructor.
Changelog:
[Android][Changed] - Make ReactApplicationContext nullable as the constructor argument of ReactContextBaseJavaModule
Reviewed By: PeteTheHeat
Differential Revision: D18935950
fbshipit-source-id: a643a10a42cf36a2a2d6fde87795965f16295d43
Summary:
It's possible for us to return no constants from the BlobModule. Therefore, I'm correcting the flow-type.
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D18932328
fbshipit-source-id: 2b415d12effd16eda313d5591825c711a20f9ae3
Summary:
This diff extends the UIManagerHelper class to expose the EventDispatcher associated to a tag / UImanagerType
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18862863
fbshipit-source-id: 14ce7a6a33f20a94a6296320924dbe3544eadd85
Summary:
This diff exposes the getJSIModule on the ReactContext class.
This class already has methods to obtain NativeModules and JSModules, it make sense to expose the getJSIModule method too.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18862858
fbshipit-source-id: 95fe48c065266060c96fc40a002041ba398b3134
Summary:
This method exposes a method to ReactContext to determine if we are running in Bridgeless mode or not
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18901149
fbshipit-source-id: bdd5ba747381f3bde5f592276b42244ca01ccbb9
Summary:
This diff promotes the UIManagerModule.getEventDispatcher() to the interface UIManager and it implements this method in FabricUIManager class.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18862862
fbshipit-source-id: 424f0e601ed1807dbd5d33048daf7dc3bb200dcd
Summary:
`NativeImageEditor` doesn't export any constants. Therefore, `ImageEditingManager` doesn't need a `getConstants()` method. In a subsequent diff (D18888735), I rename all `ReactMethod getConstants()` methods to `Override getTypedExportedConstants()`. This raises an error because the spec for `ImageEditingManager` doesn't contain a `getTypedExportedConstants()` method.
Changelog:
[Internal] - Delete getConstants() from ImageEditingManager
Reviewed By: fkgozali
Differential Revision: D18909419
fbshipit-source-id: 7e4f84f102068aa44bb3d267c66a60c0d0d27404
Summary:
`JSDevSupport.onSuccess` is called in `JSDevSupportModule.getJSHierarchy`:
```
const JSDevSupportModule = {
getJSHierarchy: function(tag: number) {
try {
const {
computeComponentStackForErrorReporting,
} = ReactNative.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED;
const componentStack = computeComponentStackForErrorReporting(tag);
if (!componentStack) {
JSDevSupport.onFailure(
JSDevSupport.ERROR_CODE_VIEW_NOT_FOUND,
"Component stack doesn't exist for tag " + tag,
);
} else {
JSDevSupport.onSuccess(componentStack);
}
} catch (e) {
JSDevSupport.onFailure(JSDevSupport.ERROR_CODE_EXCEPTION, e.message);
}
},
};
```
If you look at the implementation of `computeComponentStackForErrorReporting`, it returns a `string`. The Java NativeModule also accepts a `String` for the argument to `JSDevSupport.onSuccess`. So, I've changed the `NativeJSDevSupport.onSuccess` method signature to match the native implementation (i.e: accept a string).
Changelog:
[General] [Fixed] - Correct argument types of NativeJSDevSupport.onSuccess
Reviewed By: fkgozali
Differential Revision: D18908306
fbshipit-source-id: 1c9a5c6fe5b3a81b25baed520e586ebf7e2514f8
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