Summary:
This is the second step in creating a new DevSupportManager impl with more async-friendly APIs for bundle loading, which I'll use in bridgeless mode. This diff creates a new interface, AsyncDevSupportManager, and two implementations, mirroring what we currently have.
This new interface doesn't define any methods yet.
Changelog: [Android][Changed] Specify DevSupportManager.setPackagerLocationCustomizer in DevSupportManager impls
Reviewed By: mdvacca
Differential Revision: D19870812
fbshipit-source-id: 042a43e1a3055aba6d7325f948060300b5bf17f3
Summary:
This is the first step for adding my own async APIs for DevSupportManager to use in bridgeless mode.
To avoid having to add these APIs to the DevSupportManager interface + both of its implementations, I'm instead splitting DevSupportManager into a base class + final impl so I can more easily share logic with the new impl I'll create.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D19846619
fbshipit-source-id: c67b0231f4e6581fb484f9a4899ed0b7f08fb684
Summary:
Looks like there could be cases when the NativeHirearchyManager may be asking if it should animate on a view that has been removed. Adding a null check
Changelog:
[General] [Fixed] - Check null values in shouldAnimate
Reviewed By: makovkastar
Differential Revision: D20063054
fbshipit-source-id: 5b3b1c27b9aba57a592bd8d4e27a970cf0912b5d
Summary:
Run clang-format and add .clang-tidy with `clang-diagnostic-*` to several more directories in order to catch any problems.
Changelog:
[Internal]
Reviewed By: shergin
Differential Revision: D19860169
fbshipit-source-id: 7785aab010c8e6945cc6b5c9b68cb8ee0cdbb7fa
Summary:
We were already doing this for ViewCommands sent with integer IDs; we should do the same for now with String commands. Otherwise, screens with TextInputs are unusable during development because these exceptions are thrown very often around reload and navigation.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20127446
fbshipit-source-id: a5d65ff6ae5b520fd0efffa5c325b5cca3bd53a0
Summary:
For backwards-compatibility with Paper, we're implementing a feature in Fabric that will allow TextInputs to use the default padding from the theme in Android.
Note that this uses some pretty ugly hacks that probably shouldn't be used inside of components at all: looking directly at rawProps, overriding props/Yoga styles in the component descriptor, etc. I would (personally) really like to kill this feature entirely unless and until we can find a more elegant solution.
Changelog: [Internal]
TextInputs are still not pixel-perfect with Paper, but they're much closer, and the underline visual glitchiness is no longer an issue.
Reviewed By: mdvacca
Differential Revision: D20109605
fbshipit-source-id: 543282843e0a9f03a504d72d7a014431099bd64c
Summary:
This diff:
1. Updates `update-specs.js` to also check in the JNI TurboModules codegen output.
2. Updates all the checked in OSS codegen.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19907536
fbshipit-source-id: 179e01aff05f4c970c20f1482f096dbca10caed3
Summary:
This diff disables the rendering of TextInlineViews in ClassicRN when the users is running with Fabric enabled.
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20087254
fbshipit-source-id: b4664b17b4c845d212f72e75eee58860fe31abee
Summary:
This diff changes the Fabric measure API in order to support attachments parameters
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20087252
fbshipit-source-id: 20e1526aaa3695d38d0805416df8a32adb8296ad
Summary:
Changelog: [Android] [Changed] - Internal storage now will be preferred for caching images from ImageEditor.
Now we try to write to internal cache directory first.
If that fails (due to no memory error or other IOException), we attempt to write to external storage (if that is allowed).
I introduced additional configuration flag, `allowExternalStorage` which is true by default.
And i updated documentation for new behaviour - see
`ImageEditor.cropImage(..)` comment.
Reviewed By: makovkastar
Differential Revision: D19878158
fbshipit-source-id: 7e338ce68f535f74c62b5eecd5a94af7e7396f8b
Summary:
Until now, there were two measure functions that differ in only one parameter (rootTag). The rootTag is used to use the context associated to the tag as part of the calculation of layout, otherwise it just uses the ReactApplicationContext.
This diff unifies both method into an unique method that
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20081281
fbshipit-source-id: b1f6a6cedbf78f36f36fd0f93407c23c6996d76b
Summary:
I think this NativeModule was converted before we checked in the Java codegen output for TurboModules. I'm making `DeviceInfoModule` extend `NativeDeviceInfoSpec` to properly make it a TurboModule.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D19911145
fbshipit-source-id: fcec8c5b991bd9fd991e690dfa51f1bd36117e5f
Summary:
We recently updated React Native's docs site to have its own domain reactnative.dev and needed to update the URLs in the source code
CHANGELOG:
[INTERNAL]
Reviewed By: hramos
Differential Revision: D20072842
fbshipit-source-id: 1970d9214c872a6e7abf697d99f8f5360b3b308e
Summary:
This diff disables preallocation of virtual nodes, I'm doing this as an intermediate step to eradicate virtual nodes from the android mounting layer.
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20048996
fbshipit-source-id: 8fe0b03bcfcfd83a3093d1503ac93a20a5e9a57e
Summary:
This diff extends the MountingManager to not fail when trying to update event emitter of a non created view. This is necessary as intermediate step to remove virtual nodes out of the RN Fabric Android
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20048998
fbshipit-source-id: c2a3633400ac67c2f46ec52ed3ad80289ff6aeb9
Summary:
This diff cleans up mobile config and ReactFeatureFlags that are not used anymore
changeLog: [internal]
Reviewed By: JoshuaGross, makovkastar
Differential Revision: D20026794
fbshipit-source-id: 3d941db195075a9cf49b7ecc0bf1ee839fcca189
Summary:
This diff enables support for TextInlineViews with dynamic sizes by default, removing old code and calls to MCs.
changelog: [internal]
Reviewed By: JoshuaGross, makovkastar
Differential Revision: D20026795
fbshipit-source-id: 48adf356b418866d937be9b478d9186342a07de8
Summary: Switching SwipeRefreshLayout to use the bridgeless-friendly API for getting the EventDispatcher.
Reviewed By: mdvacca
Differential Revision: D20016310
fbshipit-source-id: 2f674f45768640fb6219df690fa34f74206fdf19
Summary: Right now, animations don't work on Android in bridgeless mode because NativeAnimatedModule directly uses the UIManagerModule for various things. Previously, I added a bridgeless check to the module's `initialize()` method to avoid adding a listener on the UIManager; in this diff, I'm moving that check so that we also skip adding the lifecycle listener on the context in bridgeless mode, too. I'll remove this check once we come up with a replacement for the UIManagerModule API.
Reviewed By: JoshuaGross
Differential Revision: D19964171
fbshipit-source-id: 7c461f535e370b0e607c28905c505239cce0e157
Summary:
Fabric debugging.
I also have an agenda of removing all instances of `ReactConstants.TAG`, because it's overly broad and not helpful during debugging.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20016401
fbshipit-source-id: 91e5cd7e8eb662b1a4a887c1e4e66a31ec741b46
Summary:
motivation: there are cases where one'd like to control the radius of the ripple effect that's present on TouchableNativeFeedback - in my case, I want to make sure that both icons and text have the same ripple appearance, but that's currently not possible as far as I can tell.
Currently (afaik) the only way to set (upper) ripple limits is by specifying width, height and border radius ( + `overflow: hidden`), and this works well for icons which can usually be bounded by a square, but not for text which can have rectangular shape.
This PR adds `rippleRadius` parameter to `SelectableBackground()`, `SelectableBackgroundBorderless()` and `Ripple()` static functions present on `TouchableNativeFeedback`. It can make the ripple smaller but also larger. The result looks like this:
added to RNTester:
difference from the other ripples:
I'm ofc open to changing the api if needed, but I'm not sure there's much space for manoeuvring. While I was at it, I did a slight refactor of the class into several smaller, more focused methods.
It's possible that in some cases, this might help to work around this issue https://github.com/facebook/react-native/issues/6480.
## Changelog
[Android] [Added] - allow setting custom ripple radius on TouchableNativeFeedback
Pull Request resolved: https://github.com/facebook/react-native/pull/28009
Test Plan: I tested this locally using RNTester
Reviewed By: TheSavior
Differential Revision: D20004509
Pulled By: mdvacca
fbshipit-source-id: 10de1754d54c17878f36a3859705c1188f15c2a2
Summary:
Right now, `requestFocus()` is a no-op if the EditText view thinks it's already focused. In certain cases, though, we still want to focus the view even if it's already focused - for example, if TalkBack is enabled and you dismiss the keyboard, you want to be able to tap on the TextInput again to bring back the keyboard, even though the View never thinks it lost focus.
What I'm doing instead is basically disregarding the View's current focus state if we *would* focus the TextInput, which is in 3 circumstances:
- When the view is attached to a window, if autofocus is true
- When the focus is being requested by JS
- When the focus is being requested by an accessibility action from the OS
Changelog: [Android][Fixed] Change how TextInput responds to requestFocus to fix a11y focus issue
Reviewed By: mdvacca
Differential Revision: D19750312
fbshipit-source-id: 30b9fab40af4a083fa98f57aba7e586540238bea
Summary:
Migrates internal calls from ignoreWarnings to ignoreLogs so we can remove YellowBox.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D19813781
fbshipit-source-id: 16c7b3f2cd38cba1901eccb4d5b9a2396a37ba1b
Summary:
Both the UIManagers use ReactConstants.TAG currently, so certain logs are ambiguous. Use FabricUIManager's tag instead for all logs to disambiguate.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19945587
fbshipit-source-id: 0a9d62b5c0276688b2ad3acf8d893b523c26560a
Summary:
https://github.com/facebook/react-native/pull/22166 removed inline styles from TextInputTestModule but applied the incorrect style to some of the TextInputs - instead of setting the text color, it set the margin. This caused the test to fail because no color was applied.
Changelog: [Android] [Fixed] Fixed style in TextInputTestCase
Reviewed By: zackargyle
Differential Revision: D19912362
fbshipit-source-id: d5068114b726ee7583842e5f6f323862b0c28e44
Summary:
We must use FLog instead of android.util.log, this diff moves the current callsites of android.util.log to FLog
changeLog:[internal]
Reviewed By: JoshuaGross
Differential Revision: D19884741
fbshipit-source-id: 300f7d691961aa51f0b525c37da7ae3d64fe5131
Summary:
# Problem
`UIManager::getRelativeLayoutMetrics` returns incorrect `frame.origin.y` value.
Just quick reiteration how calculation of `frame.origin` works. We take frame of the target shadow node, travers hierarchy to the root and keep adding `frame.origin` of each ancestor to target shadow node's origin.
One more important piece of information, to calculate scroll view's `frame.origin`, we need to have its contentOffset which gets passed to Fabric core through state.
# So where does it go wrong?
Problem is that on Android, calling view command `scrollTo` doesn't set its internal state correctly. So when we calculate the layoutmetrics, scroll view's `frame.origin` is off by whatever value was used in `scrollTo`.
# The fix
In `ReactScrollView`, correctly set state after `scrollTo` is called on it.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D19835549
fbshipit-source-id: d56e7b0b05023c0497e52c8b46fdcf58ca78b4a5
Summary:
Add debug logs for T62192299, which will hopefully tell us why RN is being destroyed in otherwise useless logs.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19866793
fbshipit-source-id: 6656c305c8ef567335ea7fe82e4e1c68092a49d2
Summary:
New release with some fixes for RN consumers. See
https://github.com/facebook/SoLoader/releases/tag/v0.8.2
## Changelog
[Android] [Chore] Update SoLoader to 0.8.2
Reviewed By: cpojer
Differential Revision: D19856837
fbshipit-source-id: 77a8fe1aa62db951413931e8a7d5e05325beb24e
Summary:
Just released a new version. No changes impacting us here.
Changelog: [Android] [Chore] Upgrade soloader targets
(Note: this ignores all push blocking failures!)
Reviewed By: cpojer
Differential Revision: D19856603
fbshipit-source-id: bab56be19fe231ac70040fca772ce3bc77269692
Summary:
This adds support for `adjustsFontSizeToFit` and `minimumFontScale` on Android. The implementation tries to match closely the behaviour on iOS (hardcoded 4px min size for example). It uses a simpler linear algorithm for now, opened to improving it now if it is a deal breaker or in a follow up.
See https://twitter.com/janicduplessis/status/1171147709979516929 for a more detailed thread about the implementation
## Changelog
[Android] [Added] - Implement `adjustsFontSizeToFit` on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/26389
Test Plan: Tested by adding the existing `adjustsFontSizeToFit` example from the iOS text page to android. Also added a case for limiting size by using `maxHeight` instead of `numberOfLines`.
Reviewed By: mdvacca
Differential Revision: D17285473
Pulled By: JoshuaGross
fbshipit-source-id: 43dbdb05e2d6418e9a390d11f921518bfa58e697
Summary:
This method is being stripped in release builds because it's used directly from C++ and not referenced in Java. Adding `DoNotStrip` to prevent this.
Changelog: [Internal]
Reviewed By: PeteTheHeat, mdvacca
Differential Revision: D19708826
fbshipit-source-id: a572f0295ab3b49e5884d0a6c723d65e4bbc9226
Summary:
It turns out that in release builds, proguard is doing something weird with inner classes, so that getSimpleName() is actually returning "OuterClass$InnerClass" in some cases. We have logic to handle this case already in JavaScriptModuleRegistry, so I'm moving that out to a static method that I can access in bridgeless mode.
Also adding tests for it.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19701703
fbshipit-source-id: 625737bfb50ca8ba2bd26034e2a74c682783ba8a
Summary:
Easy diff to add extra logging when Fabric tries to add a view inside a view that is not a ViewGroup
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D19737506
fbshipit-source-id: ecb858820de7befc385e725c45b537359e39c0e7
Summary:
Adding a `.clang-tidy` to a bunch of dirs under `react-native-github/ReactAndroid` and `react-native-github/ReactCommon`.
I don't want to add a single `.clang-tidy` at the root because we'll need more fine-grained control over what checks are enabled in different parts of the codebase; for example, fabric will and TM will probably have more checks enabled than older parts of the codebase that we're not actively modernizing, and the Hermes team probably wants its own config to be consistent with the rest of their codebase.
Starting off each `.clang-tidy` by only enabling clang-diagnostic; this is just to test that it's working. In the future, we'll work with the community to gradually enable more checks.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19705749
fbshipit-source-id: 979cea053b645ac4a9790340033bfcfb49ca0f97
Summary:
This diff refactors Text and Text input components in Fabric to support customizable emojis
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D19679391
fbshipit-source-id: 358aa97064209d28d317ba4ca5fff84245c9b1bb
Summary:
This diff refactors support of emojis in RN classic in order to make it easy to extend support for text input and fabric (as part of this stack)
changelog:[internal]
Reviewed By: JoshuaGross
Differential Revision: D19679394
fbshipit-source-id: 45eff49800b3db281721088f107494005d390fff
Summary:
Follow up to https://github.com/facebook/react-native/issues/27803. To keep consistency between the implementations this also implements autoFocus natively on Android. This will allow removing the JS auto focus logic completely.
## Changelog
[Android] [Fixed] - Implement native TextInput autoFocus on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/27924
Test Plan: Test using the TextInput example in RN tester.
Differential Revision: D19674506
Pulled By: TheSavior
fbshipit-source-id: 9cbb517fc69bccd11f5292a1ccb4acea2e3713e9
Summary:
This diff changes the behavior of UIImplementation.resolveViewManager() to return null instead of throwing an exception when trying to find an unexistent viewManager during the computation of constants for view Managers.
The C++/JS code manages exceptions and null results when a view manager doesn't exists, this diff simplifies the way this method operates.
changeLog: [internal]
Reviewed By: rickhanlonii
Differential Revision: D19624423
fbshipit-source-id: df31dcfae9a588bf325b61d529cec6ead59fb19d
Summary:
I hit a crash when testing bridgeless mode in a release build:
Error: Exception in HostFunction: java.lang.NoSuchMethodError: no non-static method "Lcom/facebook/react/modules/core/JavaTimerManager;.createTimer(IJZ)V"
It turns out that `JavaTimerManager.createTimer()` is getting stripped from release builds because it's not referenced in Java at all. Adding `DoNotStrip` annotation to keep it around. The other methods in JavaTimerManager don't need this because they're referenced by TimingModule - this is the only method that's only used directly from C++ by bridgeless mode.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19655519
fbshipit-source-id: 8b9862475986bb84b12d81f73f677cc2e4860c67
Summary:
Previously, users of the TurboModuleManager system would have to `TurboModuleManager.installBindings()` themselves, which synchronously attached the `__turboModuleProxy` function on the JS `global` object.
After these changes, the TurboModuleManager, when created will schedule work on the JS thread to install the global `__turboModuleProxy` function. As long as you create the TurboModuleManager before you run the bundle, we'll install the bindings before any TurboModules are accessed.
Changelog:
[Android][Fixed] - Install TM Bindings on JS thread
Reviewed By: ejanzer
Differential Revision: D19335956
fbshipit-source-id: 967ac2d3a0510392f6f0e42efe79b1a0ff6768c4
Summary: Migrate ReactTextinputManager to support bridgeless mode by accessing the EventDispatcher through the UIManagerHelper instead of from ReactContext.
Reviewed By: mdvacca
Differential Revision: D19614184
fbshipit-source-id: 5dd4945223d10785f8fe171e06d6f7ef42f9d834
Summary:
## Description
You're not supposed to hold on to JSI objects (ex: `jsi::Function`) past the point where their `jsi::Runtime` is deleted. Otherwise, we get a dangling pointer crash, like this: T60262810! Historically, this cleanup problem has always been really tricky to get right. With this diff, I hope to fix that problem once and for all by deleting all `jsi::Function`s when we delete the global `__turboModuleProxy` function.
## Current Setup
- The TurboModules infra uses weak references to `CallbackWrapper`s to hold on to the `jsi::Function`s passed from JS to ObjC.
- The LongLivedObjectCollection holds on to strong references to `CallbackWrapper`s. This ensures that the `jsi::Function`s aren't deleted prematurely. This also means that we can use `LongLivedObjectCollection` to delete all `CallbackWrappers`.
- `TurboModuleBinding` is the abstraction we use to install the global `__turboModuleProxy` function. It is owned by `TurboModuleManager`, and `TurboModuleManager` uses it to clear all references to `jsi::Function`s, when we delete all NativeModules.
## Solution
1. Transfer ownership of `TurboModuleBinding` from `TurboModuleManager` to the `__turboModuleProxy` function.
2. Clear the `LongLivedObjectCollection` when `TurboModuleBinding` is deleted.
Changelog:
[iOS][Fixed] - Clear all held jsi::Functions when jsi::Runtime is deleted
Reviewed By: JoshuaGross
Differential Revision: D19565499
fbshipit-source-id: e3510ea04e72f6bda363a8fc3ee2be60303b70a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/27841
Follow up from https://github.com/facebook/react-native/pull/27539 - adding back in the optimization that Detox has in TimersIdlingResource to avoid iterating over the entire timers queue if the next timer is already within the specified range.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19522346
fbshipit-source-id: 32609f434d1ca575a5a49ad630e288c43fa90864
Summary:
Migrate ReactTextinputManager to support bridgeless mode by accessing the EventDispatcher through the UIManagerHelper instead of from ReactContext.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19456326
fbshipit-source-id: 5e9643793cd764e29964f565db24cdea683ac032
Summary:
Migrating ReactImageView to use the new API for accessing the EventDispatcher (UIManagerHelper.getEventDispatcherForReactTag) that supports bridgeless mode.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D19190765
fbshipit-source-id: a958dfc9c48845270e99f8d378ce034cddc8036f
Summary:
Collecting Telemetry is a crucial part of building a performant UI framework; we do that but we need to improve it to make the data more reliable, actionable and trustful.
Now we collect time points as the number of milliseconds from the start of the CLOCK_MONOTONIC epoch. That's fine but it also has problems:
Sometimes a millisecond is an eternity. We have only 16 (or fewer) of them on each frame. What if some operation takes 1ms (according to telemetry) but we have to run it a dozen times? Does it mean that it's 12 ms in total? So, we lack precision.
This is not type-safe. Do you know how many milliseconds in a microsecond? I don't. We multiply that on magical constants hoping that we copied that from some other place right.
The current implementation is not cross-platform. We have ifdefs for iOS and Android and Unix and Windows (which is now implemented).
So, this diff replaces that with using `std::chrono` which is part of the standard library that designed to fix all those concerns. We also define our type-aliases on top of that to express our concrete constrains:
We use `std::chrono::steady_clock` as the base clock which is according to the standard using `clock_gettime(CLOCK_MONOTONIC, ... )` if available. So, it's fast and compatible (the same under the hood) with Android infra.
We use nanoseconds when we store time durations (TelemetryDuration type).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D19184569
fbshipit-source-id: 7a44688f4bb3bfc6e3009874f0075c531c8569a1
Summary:
Based on [this](https://stackoverflow.com/a/5259004), header names are not case sensitive.
That means that it's valid to pass a header `Origin` or `origin`.
With the current implementation. on Android only, if you pass `Origin`, it will get overwritten by the default origin.
This made me waste a lot of time debugging a problem while trying to connect to a websockets server that required an `origin` header and my implementation was working fine in iOS but not on Android, so I'm suggest changing the logic a little bit to take that into account.
## Changelog
[Android] [Fixed] - Support for case insensitive "Origin" headers for Websockets
Pull Request resolved: https://github.com/facebook/react-native/pull/27827
Test Plan:
Here's a screenshot of that shows the issue before the fix (`Origin` header set, but getting overridden)
The fix is not that easy to test since it requires a public websocket server that checks for a custom Origin header, but I think the code changes are very small and clear.
Differential Revision: D19578860
Pulled By: cpojer
fbshipit-source-id: d854e887d1b9e8e54da662b2da2ebe08ce65fdbc
Summary:
make ReactTestHelper always return a test object set to use
Hermes.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D19566604
fbshipit-source-id: 3c8fc680afbae000adb96bfcd079104d86cf06bd
Summary:
It seems like DisplayMetricsHolder doesn't have any thread safety policy, but in practice it only updates DisplayMetrics from the main thread. Let's formalize that by adding some annotations to that effect.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19417331
fbshipit-source-id: f1d464f228776197fd0df2978c9e8edbaab67850
Summary:
We should have been calling this already. Trivial fix. The intent of the view command was always to update selection, I just forgot to add it. See test videos.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19548178
fbshipit-source-id: 14a1bdc11d84c05f2435c48c3bb96b64e8c68cb4
Summary:
Since migrating to Turbomodules (8fe04cf) the addMenuItem method crashes because the NativeEventListener methods are missing from the codegen flow type. Added the same methods based on what we do in AppState which is another native module that extends NativeEventListener.
## Changelog
[Internal] [Fixed] - Add missing NativeEventListener methods to NativeDevSettings
Pull Request resolved: https://github.com/facebook/react-native/pull/27838
Test Plan:
|Before|After|
|{F226978596}|{F226978628}
Differential Revision: D19518474
Pulled By: PeteTheHeat
fbshipit-source-id: acddba9f18dd558df1d6df78b539689fdfd0062f
Summary:
Changelog: [Internal]
The inspector API doesn't really need a `HermesRuntime`, all it needs is a `jsi::Runtime` and a `Debugger &`.
Change the return type of `RuntimeAdapter::getRuntime` to be `jsi::Runtime`.
This will allow the inspector to use the tracing runtime instead of the direct hermes runtime.
Reviewed By: willholen
Differential Revision: D18973867
fbshipit-source-id: 6809e52452a35e62be9ca8143aeaba8964c98eaa
Summary:
This diff refactors the UIManagerHelper.getUIManager to allow the caller determine if it should return null when catalyst Istance is not active.
This is necessary in order to keep backward compatibility for the getEventDispatcher method.
changelog: [internal]
Reviewed By: makovkastar
Differential Revision: D19383063
fbshipit-source-id: 8a46b61d212480be91ea78929bbfa7248d5f3ad9
Summary:
A previous PR broke toggling between visible and non-visible password (basically once a password field was made visible, future updates to the keyboardType were effectively ignored, so the password would always be visible).
Original PR: https://github.com/facebook/react-native/pull/27523
Changelog: [Internal]
Reviewed By: mdvacca, rodrigos-facebook
Differential Revision: D19527245
fbshipit-source-id: a5ab343c8a0c6a608171dbfa5afc7536ff241826
Summary:
This diff refactors the usages of UIManagerHelper.getUIManager() to make sure we always consider null objects.
Some of the callsites were throwing a NullPointerExcetpion, now they throw a more explicit exception.
changelog: [internal]
Reviewed By: makovkastar
Differential Revision: D19383064
fbshipit-source-id: 1806a37528e80cab1c8fdff5eb631aaf47bde819
Summary: On iOS we don't emit the didUpdateDimensions event in JS when the first React Native screen is rendered, so let's keep the behavior the same on Android.
Reviewed By: mdvacca
Differential Revision: D19506829
fbshipit-source-id: d0122d18be79177318c3f059ed396f990eeabcb7
Summary:
This is a trivial cleanup of an unused variable.
changelog: [internal]
Reviewed By: makovkastar
Differential Revision: D19383062
fbshipit-source-id: 937c8bb6de3aeebefb07940809340104654619fc
Summary:
This is an easy refactor of constants in ImageResizeMode
changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D19509348
fbshipit-source-id: 2bed9e35f0c7daa04c64ec7fba6975517633bfa7
Summary:
This PR makes it possible for subclasses of `ReactTextInputShadowNode` to control the construction of the "dummy" `EditText` instance that `ReactTextInputShadowNode` internally uses to determine the expected height of the view. This PR does not change the default behavior, it just opens up that default to being overriden.
This is useful in the case of custom views that have different behavior from a "default" `EditText` instance (`new EditText(context)`). For example, it might have a different style applied.
As a side benefit, this change also makes it easy to have subclasses not apply the default theme, which can allow the custom view to avoid a longstanding crash issue (https://github.com/facebook/react-native/issues/17530).
## Changelog
[Android] [Added] - Allow overriding `EditText` construction in `ReactTextInputShadowNode`
Pull Request resolved: https://github.com/facebook/react-native/pull/27782
Test Plan: All tests pass.
Reviewed By: mdvacca
Differential Revision: D19450593
Pulled By: JoshuaGross
fbshipit-source-id: 8d2ce6117246fc3e2108623312b38583af5722b3
Summary:
This fixes a build failure with buck introduced with https://github.com/facebook/react-native/issues/27729. The internal and external buck overlays diverged in how fbjni was imported. The Buck re-export here ensures that the targets resolve both internall and externally.
## Changelog
[Android] [Fixed] - RNTester Buck Build
Pull Request resolved: https://github.com/facebook/react-native/pull/27826
Test Plan:
buck fetch rntester
buck build rntester
Reviewed By: jknoxville
Differential Revision: D19496769
Pulled By: passy
fbshipit-source-id: d699a5f64f691ed375cfc7a9d6a5a6f6e36ba283
Summary:
This is an incomplete effort to migrate from libfb to libfbjni. This is needed to restore the compatibility with Flipper and other FB Android projects that make use of FBJNI. Effectively, the outcome is that `fbjni` no longer has a checked-in copy here, but instead relies on the public artifacts published at github.com/facebookincubator/fbjni that can be deduplicated at build-time.
**A non-exhaustive list of tasks:**
* [X] Gradle builds the SDK and RNTester for Android.
* [X] Buck build for rntester works in OSS.
* [ ] Move from `java-only` release to full `fbjni` release. This requires finding a solution for stripping out `.so` files that the old `Android.mk` insists on including in the final artifacts and will clash with the full distribution.
* [ ] Import this and fix potential internal build issues.
* [ ] Verify that the changes made to the Hermes integration don't have any unintended consequences.
## Changelog
[Android] [Changed] - Migrated from libfb to libfbjni for JNI calls
Pull Request resolved: https://github.com/facebook/react-native/pull/27729
Test Plan:
- CI is already passing again for Gradle and Buck in OSS.
- After applying the following patch, RNTester builds and works with the latest Flipper SDK:
```
diff --git a/RNTester/android/app/build.gradle b/RNTester/android/app/build.gradle
index b8a6437d7..eac942104 100644
--- a/RNTester/android/app/build.gradle
+++ b/RNTester/android/app/build.gradle
@@ -170,10 +170,19 @@ dependencies {
debugImplementation files(hermesPath + "hermes-debug.aar")
releaseImplementation files(hermesPath + "hermes-release.aar")
- debugImplementation("com.facebook.flipper🐬0.23.4") {
+ debugImplementation("com.facebook.flipper🐬+") {
exclude group:'com.facebook.yoga'
- exclude group:'com.facebook.flipper', module: 'fbjni'
- exclude group:'com.facebook.litho', module: 'litho-annotations'
+ exclude group:'com.facebook.fbjni'
+ }
+
+ debugImplementation("com.facebook.flipper:flipper-network-plugin:+") {
+ exclude group:'com.facebook.yoga'
+ exclude group:'com.facebook.fbjni'
+ }
+
+ debugImplementation("com.facebook.flipper:flipper-fresco-plugin:+") {
+ exclude group:'com.facebook.yoga'
+ exclude group:'com.facebook.fbjni'
}
if (useIntlJsc) {
```
Reviewed By: mdvacca
Differential Revision: D19345270
Pulled By: passy
fbshipit-source-id: 33811e7f97f44f2ec5999e1c35339909dc4fd3b1
Summary:
LocalData isn't used by any components. We've moved towards State.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D19250737
fbshipit-source-id: 10bf0b62ffad01ad10b07d029e84df4f312780a1
Summary:
This diff ensures the measurement and rendering of FB emojis is correnct in RN Android.
Before this commit we were customizing Spannable object with FB emojis right before rendering the text into the TextView, this diff ensures that the Spannable is "customized" as soon as it is created, ensuring the measurement of the Text.
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D19354107
fbshipit-source-id: 92e07cf30503404f7820f25eaa9efdc02f6bddbd
Summary:
After some more testing, I discovered a problem in D19395326 because the native map that DeviceInfoModule was storing in `mPreviousDisplayMetrics` had been consumed when the event was emitted to JS. This caused the comparison to fail, so it would emit the event again when the dimensions hadn't changed.
In this diff, I'm storing a Java-only copy of the native map before emitting the event to JS so this shouldn't happen.
Changelog: [Android][Fixed] Fix bug in updating dimensions in JS
Reviewed By: mdvacca
Differential Revision: D19462861
fbshipit-source-id: 2e47479df93377b85fe87f255972dd31e874e3a8
Summary:
ReactRootView currently caches the last seen DisplayMetrics so we can compare them against the current values in DisplayMetricsHolder to determine if the screen dimensions have changed. (If they have changed, we emit an event to notify JS of the new dimensions).
However, ReactRootView initializes these member variables with empty DisplayMetrics, which means that the first time we check against them in onGlobalLayout, we will *always* emit an event to JS.
This seems reasonable if you only have one ReactRootView, but if you create a new RRV for each RN screen in your app, then you're going to get updated dimensions on each navigation event, even though the screen dimensions have probably not changed.
In this diff, I'm no longer storing the DisplayMetrics in ReactRootView at all, but instead am using temporary variables to check the new DisplayMetrics values against the old.
Changelog: [Android][Fixed] Only update dimensions in ReactRootView if they've changed
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D19395326
fbshipit-source-id: c01aee73064764503c9b49208032c790b83a1d29
Summary:
For some reason, I think this method is being optimized away, which is really strange considering that it's being used in getModule.
Changelog:
[Internal]
Reviewed By: ejanzer
Differential Revision: D19454855
fbshipit-source-id: 414b4888f7aacf730dd22939e2e2140b94dff4e7
Summary:
We should also call `TurboModuleManager.getLegacyCxxModule('foo')` when we call `TurboModuleManager.getModule('foo')` is called.
This fixes a Marketplace crash. See: D19432594
Changelog:
[Android][Fixed] - Ensure TMM.getModule also queries CxxModuleWrappers
Reviewed By: ejanzer
Differential Revision: D19434549
fbshipit-source-id: cff741cf1587d2a0dbcdc5eb95016c8aa283b727
Summary:
This converts all NativeModules excluding the following into TurboModules:
```
// Deleted
"fbsource/fbandroid/java/com/facebook/catalyst/modules/relaynativecache/RelayNativeCacheReaderModule.java"
// Owners of FBC will migrate these by themselves
"fbsource/xplat/fbc-mobile-app/android/app/src/main/java/com/fbc/i18n/FBCi18nAssetsModule.java"
"fbsource/xplat/fbc-mobile-app/android/app/src/main/java/com/fbc/react/CellScanResultsModule.java"
"fbsource/xplat/fbc-mobile-app/android/app/src/main/java/com/fbc/react/WiFiScanResultsModule.java"
// Don't have Buck owners
"fbsource/xplat/js/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/FBAccessTokenModule.java"
"fbsource/xplat/js/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/FBGraphRequestModule.java"
"fbsource/xplat/js/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/FBLoginManagerModule.java"
"fbsource/xplat/js/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/FBShareAPIModule.java"
"fbsource/xplat/intl/oss-fbt/__github__/react-native-fbt-android-native-module/android/src/main/java/com/reactlibrary/FbtAndroidNativeModule.java"
```
This should conclude the Android TurboModule migration.
Changelog:
[Android][Added] - Make remaining NativeModules TurboModule-compatible
Reviewed By: PeteTheHeat
Differential Revision: D19383442
fbshipit-source-id: 71beaee087f6436b197a65f0d68527d9964bb6ce
Summary:
For every untyped NativeModule Java file, we ensure that its owner depends on the owner of its JS spec.
Changelog:
[Internal]
Reviewed By: PeteTheHeat
Differential Revision: D19382937
fbshipit-source-id: 0a1d840bff2f9e8db0f06c910448e9b25415d18c
Summary:
This diff fixes the redbox error: Views nested within a <Text> must have a width and height
This error is reproducible when rendering a View with no fixed size, inside a <Text>. e.g.
```
function PlaygroundContent(props: {}) {
return (
<View style={styles.container}>
<Text>
<View>
<Image source={fbicon.filled('chevron-down', 10)} />
</View>
</Text>
</View>
);
}
```
changelog: Add support to render <View> with no fixed size nested within a <Text>
Reviewed By: shergin
Differential Revision: D19387760
fbshipit-source-id: a9cee8410e56a2d362d6b8f993e602719c416925
Summary:
In D15393464, we introduced `NativeHeapCapture`, but it had a few problems:
1. It required `JSCHeapCapture` by doing `TurboModuleRegistry.get<Spec>('HeapCapture')`, when it should have done `TurboModuleRegistry.get<Spec>('JSCHeapCapture')`.
2. It had an additional method `captureHeap`, which didn't exist on the Android NativeModule.
This diff corrects those mistakes.
Changelog:
[Both][Fixed] - Fix JSCHeapCapture
Reviewed By: PeteTheHeat
Differential Revision: D19383511
fbshipit-source-id: 30e69afbcdba673f3f32c16bde4f0342568ab97d
Summary:
Ran `arc f` against some CPP files to be modified with the next diff
to reduce the churn on it.
## Changelog
[Android] [Changed] - Formatted cpp/h code with clang-format
Reviewed By: javache
Differential Revision: D19371785
fbshipit-source-id: b7f7b92c4cb9ec7f8da728bb577db29cf11fbb39
Summary:
In D14244606 I "fixed" `Platform.isTesting()` in JS. By fixed, I made it return true when running SSTs.
People in OSS complained about this in discord and [github](https://github.com/facebook/react-native/issues/27010). The problem is that this call returns true whenever an RN project references Detox in the build.gradle file. In practice, this has been really annoying, because it has disabled animations in debug builds, due to D13811035.
The fix is to be more specific, and look for the exact screenshot test activity. I haven't explicitly verified this doesn't trigger from Detox, but it shouldn't. I'll coordinate on the github issue to verify.
Changelog: [Android][Fixed] Fix animations in OSS debug builds by modifying `Platform.isTesting()` behaviour
Reviewed By: TheSavior
Differential Revision: D19384098
fbshipit-source-id: 22c885219f2c00f5dcc3b930b068bfd2ad7e4b8e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/27539
Detox currently relies on reflection to inspect the private timers queue in the Timing module to check if React Native is idle or not. This broke when I renamed TimingModule and moved the queue to JavaTimerManager in D17260848 and D17282187. A better solution to this problem is for us to expose a public API for checking the timers queue from TimingModule, so that Detox doesn't need to access private fields.
Using similar logic to Detox's TimersIdlingResource: 4f81a77bae/detox/android/detox/src/main/java/com/wix/detox/reactnative/idlingresources/TimersIdlingResource.kt (L95)
Changelog: [Android] [Added] Added an API for checking if there are busy timers to TimingModule
Reviewed By: makovkastar
Differential Revision: D19128786
fbshipit-source-id: 835ae214eba58879c8343255bba680a81801ce03
Summary:
Fix for https://github.com/facebook/react-native/issues/27510.
Setting the `InputType.TYPE_CLASS_TEXT` flag when `keyboardType` is null or default breaks autoCapitalize. Handle the case when `keyboardType` is null, default, or invalid type.
## Changelog
[Android] [Fixed] - Fix setting keyboardType from breaking autoCapitalize
Pull Request resolved: https://github.com/facebook/react-native/pull/27523
Test Plan:
Added keyboardType prop to RNTester as so
```
<TextInput autoCapitalize="words" keyboardType="default" style={styles.default} />
```
Reviewed By: makovkastar
Differential Revision: D19132261
Pulled By: JoshuaGross
fbshipit-source-id: be66f0317ed305425ebcff32046ad4bff06d367f
Summary:
NativeAnimatedModule registers itself as a listener on UIManagerModule, which doesn't exist in bridgeless mode. We now have an API on ReactContext to detect if we're in bridgeless mode, so let's just bail out when that's the case (for now).
In the future, we'll need a replacement for this API on FabricUIManager (or somewhere).
Changelog: [Internal]
Reviewed By: PeteTheHeat, mdvacca
Differential Revision: D19185762
fbshipit-source-id: 1cf53304ab58a5b985c8f4806544da51f09e8ba5
Summary:
In bridgeless mode, we use BridgelessReactContext, which overrides some methods on ReactApplicationContext like `getJSIModule` and returns true for `isBridgeless`. This is needed for things like getting the EventDispatcher, which is currently accessed from the UIManagerModule (which doesn't exist in bridgeless mode).
However, when we create Views in React Native we don't use the ReactApplicationContext directly; instead, we create a ThemedReactContext, which holds a reference to the RAC. It also initializes itself with the RAC's CatalystInstance, so that when you call methods on the TRC it can access native modules, etc.
This doesn't work in bridgeless mode, because the methods are overridden on the RAC, *not* the TRC. So in order for this work as expected, we need to delegate these methods to the RAC member variable. In this diff I'm just doing this for `isBridgeless` and `getJSIModule` so that accessing the EventDispatcher works.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D19190760
fbshipit-source-id: 6dc38560edc1061aec782707306590fa1012d5cb
Summary:
This should resolve some of the crashes in T9871006. It's unclear if these events are being emitted before Catalyst is set up or after it's torn down, but it's likely a race between teardown and some other event.
Should be safe to just log and continue / fail silently, if this is happening after teardown.
Also upgrading logs to error so that these get logged to logviews.
Changelog: [Internal], will fail silently in a marginal number of existing edge-case crashes for events sent before startup or after shutdown
Reviewed By: mdvacca
Differential Revision: D19269891
fbshipit-source-id: 30fc28693c0be7a15bfc5b5bc7eb88e10c7b4a5a
Summary:
This diff back out the migration of events on ScrollView to be bridgeless (D18862857)
This is causing the bug: T59882485 and the migration is not necessary in production yet.
Heads-up ejanzer this diff will affect events for scroll in Venice, I will create another diff to figure it out the root cause. But we need the land and pick this diff in v252
Changelog: [internal]
Reviewed By: ejanzer
Differential Revision: D19269906
fbshipit-source-id: d61e67975d508cddafc3af34b0f7dfe83bda6bd7
Summary:
react-native-cookie-store wants the ability to set custom cookies on Android. We use ForwardingCookieHandler to mange the cookies. Exposing the `addCookies` method will allow the module to provide the same functionality on Android.
https://github.com/safaiyeh/react-native-cookie-store/issues/1
## Changelog
[Android] [Changed] - Expose addCookies method
Pull Request resolved: https://github.com/facebook/react-native/pull/27512
Test Plan: N/A
Differential Revision: D19236309
Pulled By: cpojer
fbshipit-source-id: bf1a0730165456c34c5bf432ac370176a881cbcf
Summary:
This diff fixes the rendering of TextInput component for Android 4 devices.
This bug was caused by D18196901, when we changed the base class of ReactEditText from EditText to AppCompatEditText.
The root of the problem is that AppCompatEditText wraps the ReactContext received as a parameter in the construction of the View into a ContextWrapper object. This break the implicity assumption that the method View.getContext will return the same context that was used during the construction of the view.
https://android.googlesource.com/platform/frameworks/support/+/dd55716/v7/appcompat/src/android/support/v7/widget/AppCompatEditText.java#55
Changelog: [internal]
Reviewed By: ejanzer
Differential Revision: D19204032
fbshipit-source-id: eefb562b1da22e6cc58c75845c87dd032d727f49
Summary:
This diff disables accessibility state changes of the focused view for Android API < 21.
This is necessary because the method view.isAccessibilityFocused was introduced in Android API 21
Users in Android API < 21 will not be able to hear accessibility state changes of the focused view (feature introduced by D17903205)
Changelog: disables accessibility state changes of the focused view for Android API < 21, see PR: 26624
Reviewed By: fkgozali
Differential Revision: D19199096
fbshipit-source-id: 12b349f0ac94b77e9e7328ae40e1ae1a278e8b24
Summary:
## Problem
For efficiency reasons, we'd only check whether the current class or its superclass implemented the `TurboModule` interface. However, it's possible for NativeModules to exist that use inheritance, and have their base class extend a code-generated spec. In this case, the superclass of the superclass of the NativeModule will implement `TurboModule`.
## Solution
To fix this problem, I'm relying on the `Types.isAssignable` API and checking whether the NativeModule can be assigned to the `TurboModule` interface. This is a more reliable way of knowing whether a NativeModule is a TurboModule or not.
**Note:** Had to adjust the buck dependencies of FrescoModule to make the `mTypes.isAssignable` check work.
Changelog:
[Android][Fixed] - Correct TurboModule detection logic in ReactModuleSpecProcessor
Reviewed By: fkgozali
Differential Revision: D19183671
fbshipit-source-id: ad21881453fe7027d9432048108f6ba344fd7e63
Summary:
## Problem
`DebugCorePackage` is a `TurboReactPackage`. To register a `TurboReactPackage`s NativeModules, the `NativeModuleRegistryBuilder` loops over all `ReactModuleInfo`s in the package's auto-generated `ReactModuleInfo` list. This list is generated from the `ReactModuleList` annotation of the package using our annotation processors. Because `JSDevSupport` was in its package's `ReactModuleList` annotation, we generated a `ReactModuleInfo` object for it. Therefore, `NativeModuleRegistryBuilder` registered `JSDevSupport` twice (once in `DebugCorePackage` and twice in `Fb4aReactPackage`).
## How did this work before?
`JSDevSupport` was always a part of the `ReactModuleList` annotation of `DebugCorePackage`. However, before D18974084 landed, there were two key things that made this work:
1. `DebugCorePackage` was a `LazyReactPackage`,
2. The `DebugCorePackage.getNativeModules()` did not return a `ModuleHolder` for `JSDevSupport`.
For `LazyReactPackage`s, `NativeModuleRegistryBuilder` calls `LazyReactPackage.getNativeModuleIterator()` to register NativeModules. The iterator returned from `LazyReactPackage.getNativeModuleIterator()`, in this case, loops over the NativeModules returned from `DebugCorePackage.getNativeModules()`. Therefore, we don't register any NativeModules that aren't in `DebugCorePackage.getNativeModules()`. Since `DebugCorePackage.getNativeModules()` didn't contain `JSDevSupport`, it wasn't registered for the second time.
Changelog:
[Android][Fixed] - Unregister JSDevSupport from DebugCorePackage
Reviewed By: ejanzer
Differential Revision: D19187664
fbshipit-source-id: 34141c60542179567d75705937ba09ec8a3dfc2b
Summary:
The header role is being said twice in android. Stopped that from happening.
## Changelog
[General] [Added] - removed code that would cause accessibility header role to be spoken twice
Pull Request resolved: https://github.com/facebook/react-native/pull/27496
Test Plan:
Test plan is testing in RNTester making sure the examples work
## Note:
generatedComponentApiDocs.js was modified by lint commands. I can submit a PR without it if preferred.
Differential Revision: D18973520
Pulled By: hramos
fbshipit-source-id: 9a7cc2d3fac1d0fc79dedb443d5ca365026b3b15
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
Emily Janzer
Ram N
Héctor Ramos
Joshua Gross
Ramanpreet Nara
David Vacca
generatedunixname89002005287564
Nikita Kraev
Rachel Nabors
Joshua Selbo
Rick Hanlon
Vojtech Novak
Marc Horowitz
Sidharth Guglani
Samuel Susla
Andres Suarez
Pascal Hartig
Janic Duplessis
Pasquale Anatriello
Rick Ratmansky
Valentin Shergin
Bruno Barbieri
Christoph Nakazawa
Nikita Shanin
Riley Dulin
Matt Chowning
Kudo Chien
Pascal Hartig
Oleksandr Melnykov
Peter Argany
Jason Safaiyeh
Jesse Katsumata
Kevin Gonzales
sunnylqm
Mehdi Mulani
David T. Nguyen
Dulmandakh
Anandraj Govindan
Eli White
