Summary:
Removing logs related to T62192299 that we don't need anymore.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21773629
fbshipit-source-id: d16c01f87be3ed7512fe90b6e261b4c7efbd3068
Summary:
All ReactViewPager functionality should now be possible by using a ScrollView.
Changelog: [Internal] ReactViewPager has been deprecated on Android and was removed from core as part of LeanCore
Reviewed By: mdvacca
Differential Revision: D21751774
fbshipit-source-id: 292475b9ffe7788b745329d13fd88dc3b613819e
Summary:
After the experiment in D21198302 ships to 100% and that code is deleted, we no longer need ViewPagerAndroid anywhere in FB so it can be deleted.
This is distinct from deleting the native side of the component, which resides in open-source.
Changelog: [Internal]
Differential Revision: D21211134
fbshipit-source-id: 610e09792b079d34acbfcec836fde58a0b3648a7
Summary:
This diff extends the measurement of Text components in order to support empty strings.
This is required for parity with Paper.
I created a follow up task to analyze support of empty string as part of the Text infrastructure of Fabric in the future.
changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D21761171
fbshipit-source-id: d2aa074052b09732af5d35723f19014090fcabbf
Summary:
As a followup to D21750097 and D21735940, it seems that ANY uses of childCount will be incorrect as they are "often" reported, incorrectly, as just 0.
This is likely due to exotic cases like (1) the ViewManager childCount being overridden, or (2) special ViewManagers like BottomSheet where the childCount may actually be 1/0 even though many children are inserted.
Anyway, as a more generic fix, let's only rethrow an existing Exception with additional diagnostics instead of trying to detect when this /would/ crash.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21756178
fbshipit-source-id: 17ffb2ed531978bae8d4db19d7b87ec62397e44b
Summary:
We cannot call `parentView.getChildCount()` directly, we must get the child count through the ViewManager:
A simple `Log.e` call shows:
```
MountingManager: parentView.getChildCount(): 0 // viewGroupManager.getChildCount(parentView): 7
```
This difference does not occur for ALL views, but it occurs for... enough that this will crash on basically ~every screen, at least on navigation when all views are removed.
Theory about why this is happening: some ViewGroup types compute childCount differently, especially if we do some sort of custom child management for some view type? By coercing to `T` which the ViewManager does, we call getChildCount on the correct class type. This is just a hypothesis, though. But the failing views are all `View`s and it does look like `ReactClippingViewManager` has custom `getChildCount` logic, so that's likely the answer.
There's no such thing as an easy diff!
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21750097
fbshipit-source-id: 3d87d8f629a0c12101658050e57e09242dfc2a8c
Summary:
I have a theory that T53114059 can be caused by (1) other crashes, and/or (2) reloads. Clear out the ID of a RootView when it is detached.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21732066
fbshipit-source-id: 5e607f34cf42ca26bdf199d5d3024fd49a60dc1e
Summary:
This changes how we access the EventDispatcher from the FabricUIManager in bridgeless mode.
Currently, we have implemented a similar API to what we use for Fabric (used in UIManagerHelper): `BridgelessReactContext.getJSIModule(UIManager).getEventDispatcher()`. However, `getJSIModule` does not have a nullable return type, which means that we have to throw an exception if the UIManager can't be found - if, for example, the instance is not initialized yet (or has been destroyed). This is causing crashes when a view tries to access the EventDispatcher before the instance is initialized, which takes longer for Venice because we include JS bundle loading as part of initialization (we may need to revisit that).
Ideally, we'd like to create a first-class API for `getEventDispatcher()`, and make sure that it never crashes if the instance is destroyed, because we don't care if JS events aren't delivered at that point. However, there are some obstacles to making this change for the bridge - mostly related to avoiding circular dependencies between the bridge module and the uimanager module. (Also, this might be a behavior change for the bridge, because I think we currently start queueing events before it's initialized? and product code might be relying on that).
Reviewed By: mdvacca
Differential Revision: D21672949
fbshipit-source-id: a38e96cd40c6f70124b7ca2a5c9722988fe7fcf4
Summary:
Error messages like P131885276 don't help debugging, even when all mount instructions are logged to logcat. This log would help identify the incorrect mount instruction.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21735940
fbshipit-source-id: 16ff315c11ccafdd75d0ad9c7c60b7be2cd73202
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28983
Creating an interface for EventDispatcher so I can implement it from a dummy/no-op EventDispatcher to use in bridgeless mode when the instance isn't alive.
Changelog: [Android] [Changed] Renamed EventDispatcher to EventDispatcherImpl and created EventDispatcher interface; calls to EventDispatcher contstructor need to be updated
Reviewed By: makovkastar
Differential Revision: D21695401
fbshipit-source-id: 46066a467efcf03a5f484bb9fb58c662d46a2c4e
Summary:
This is the second part of a rewrite of D15390384, which allows Animated timing to be driven by Paper or Fabric.
The intuition is: we don't care which one drives the animation. We will expect one or both of them to issue a callback that operations are about to be executed, and the first one wins. The blocks will only execute once, the second time will be a noop.
I don't think there's a 100% safe way of reimplementing Native Animated Module for Fabric/Venice (without a new API and implementing in C++) since it's inherently disconnected from the commit process and the tree. This gets us slightly closer to visual functionality, though.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21698192
fbshipit-source-id: c11d3cebd12cfc8acf4b63c87ccbe62cdbd8b672
Summary:
This is (part of) a rewrite of D15390384.
This implements the lifecycle interface only for Fabric to signal to NativeAnimatedModule when preOperations are about to run / operations are about to be dispatched.
We will likely want to remove this mechanism entirely and rewrite NativeAnimatedModule in C++ for Fabric/Venice, but for now, I'm not sure of a better solution to unblock.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21698193
fbshipit-source-id: a13d445073911fd63d896202a7a1bfbe1167038a
Summary:
This is the V1 implementation of Fabric Core LayoutAnimations.
The intention is to structure this in such a way that it's easy for each platform to customize the "AnimationDriver" class (to do platform-specific optimizations) without changing the KeyFrameManager at all.
In the future, this structure and architecture should allow us to iterate faster on new animation APIs.
Changelog: [Internal] Support for LayoutAnimations in Fabric
Reviewed By: mdvacca
Differential Revision: D21675808
fbshipit-source-id: b3ef44729bb8b6217f90760aec9737276c9601d1
Summary:
Turn on Fabric LayoutAnimations on Android.
I will gate this change behind a QE before landing.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21583122
fbshipit-source-id: 82eacb7192f7c59d2809a67a619cb950293aaace
Summary:
This is the V1 implementation of Fabric Core LayoutAnimations.
The intention is to structure this in such a way that it's easy for each platform to customize the "AnimationDriver" class (to do platform-specific optimizations) without changing the KeyFrameManager at all.
In the future, this structure and architecture should allow us to iterate faster on new animation APIs.
TODOs:
- Use std::chrono for timekeeping
Changelog: [Internal] Support for LayoutAnimations in Fabric
Reviewed By: shergin
Differential Revision: D17486030
fbshipit-source-id: 95c72cf9fc2b4bf3fe652fbd249cf2ad113033c7
Summary:
While working on recent PRs regarding ripple radius in TouchableNativeFeedbaack and ripple support in Pressable I noticed `ReactDrawableHelper` uses a [discouraged](https://developer.android.com/reference/android/content/res/Resources#getIdentifier(java.lang.String,%20java.lang.String,%20java.lang.String)) way to obtain resources.
The attribute names (strings) `'selectableItemBackground'` and `'selectableItemBackgroundBorderless'` are used here
https://github.com/facebook/react-native/blob/4a48b021d63a474f1570e92616988384957d4273/Libraries/Components/Touchable/TouchableNativeFeedback.js#L105
And passed to `context.getResources().getIdentifier()` in `ReactDrawableHelper`. Since we know the attribute names beforehand I figured we can obtain the resources by id (fast) instead of by name (slow). I made it so that the slow code path is taken in case the attribute name does not match what is expected, as a fallback.
Note that I did not do any measurement of the effect of this, I'm just offering this as a PR. You'll notice that this PR relies on the fact that the string in JS is the same as the string in Java (it is duplicated). While I could export the strings from Java and use them in JS, I wasn't sure where to export them. But note that even before, the JS code depended on the `'selectableItemBackground'` and `'selectableItemBackgroundBorderless'` strings to exist on the native side, in the android SDK, I just made the dependency explicit.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Android] [Changed] - get ripple drawables by id
Pull Request resolved: https://github.com/facebook/react-native/pull/28600
Test Plan: tested manually in RNTester
Differential Revision: D21241773
Pulled By: shergin
fbshipit-source-id: 1b8314f99616095cb6ed557c62095cf3200f53b6
Summary:
LocalData was fully replaced by State, this diff removes dead code thas was previously used to update local Data
changelog: [Internal] Internal cleanup on Fabric Android code
Reviewed By: shergin
Differential Revision: D21621481
fbshipit-source-id: a3e38300a54a85adff9145cdeea1e89dad09103f
Summary:
This diff uses a new MC to Start Fabric surfaces using layoutMetrics or not.
The motivation is to verify if the new initialization of fabric surfaces is regressing in production
changelog: [Internal] Internal change in fabric
Reviewed By: JoshuaGross
Differential Revision: D21606971
fbshipit-source-id: ed1f6937ffd0f1e6c54e3ebc34595d75b6c5f6e1
Summary:
EZ diff to expose a new ReactFlag that will be used to configure the initialization of Fabric
changelog: [Internal] Internal change in fabric
Reviewed By: JoshuaGross
Differential Revision: D21606972
fbshipit-source-id: 53d6bac673b95f0fae93262ff52b815d76bb59ab
Summary:
In the previous diff I made a few more things "Retryable" exceptions, where previously only strictly ViewCommand-related code would throw Retryable exceptions. This change is to prevent FabricUIManager from swallowing these exceptions if they happen outside of the context of ViewCommands.
Changelog: [Internal] Fabric
Reviewed By: mdvacca
Differential Revision: D21607324
fbshipit-source-id: b3bad4694d2399db447a9117cc31169104b36de5
Summary:
This diff integrates the logging of Binding class using a MC
changelog: [Internal] Internal change to control logging of Fabric
Reviewed By: JoshuaGross
Differential Revision: D21574813
fbshipit-source-id: e7b2acbaa4cb8a8e748db91af5c6960cd47b520e
Summary:
This diff implements the eager initialization of fabric based on the param created in previous diffs
changelog: [Internal] Internal change in Fabric
Reviewed By: JoshuaGross
Differential Revision: D21574815
fbshipit-source-id: 1dfd2611ce8c8529ce5f6a7a8c48f8bee19be256
Summary:
This diff exposes a new react feature flag to eager initialize fabric
changelog: [Internal] Internal change in Fabric
Reviewed By: JoshuaGross
Differential Revision: D21574814
fbshipit-source-id: c74fb316963fe92e43ce0ca6262cb73a6a4acb7f
Summary:
For Fabric LayoutAnimations, we need to support interpolating the Transform property (which really ends up just being interpolation of ScaleX, ScaleY, or ScaleXY transforms - not arbitrary matrices).
To support that, we need to be able to convert Transform back to folly::dynamic, and on the Java side we need to support accepting arbitrary matrices instead of transform maps of properties.
Changelog: [Internal] Fabric-only changes
Reviewed By: sammy-SC
Differential Revision: D21564590
fbshipit-source-id: b137f659b27e4b8fae83921a28ccf46035e18651
Summary:
Ez diff that revisits deprecated methods in UIManagerModule and update javadoc
Motivation: I'm cleaning up my fabric backlog before lockdown
changelog: [Android] Update documentation of UIManagerModule methods
Reviewed By: JoshuaGross
Differential Revision: D21487609
fbshipit-source-id: 896ae21e02d5b1aa57b7158d714986fd1f8c9c5c
Summary:
This diff deletes the deprecated PlayTouchSound method from UIManagerModules.
I verified there are no callsites of this method in Facebook sourcecode
changelog: [BREAKING][Android] Deletes the method PlayTouchSound method from UIManagerModule, this method was moved to the SoundManagerModule class.
Motivation: I'm cleaning up my fabric backlog before lockdown
Reviewed By: JoshuaGross, TheSavior
Differential Revision: D21487612
fbshipit-source-id: f630e2b7f927e0b607a30b9f4904feb63a561ab9
Summary:
This diff extends the ReactShadowNode API to expose flex props, this is going to be used by some components that require access to it
changeLog: [Android][Added] Exposed getFlex method as part of ReactShadowNode API
Reviewed By: JoshuaGross
Differential Revision: D21554663
fbshipit-source-id: 26c9a3fe5f72a84120b16b553ab08231817c0efa
Summary:
TextInlineViews in Android was incorrectly converting values to from float to int, this produced to loose precision and to render incomplete texts in some components.
This diff changed the types from int to float, avoiding loose precision.
The impact of this bug is not that high because in the conversion to int we were using Math.ceil(), which was already rounding the result to the next pixel.
changeLog: [Android][Fixed] Fix precision of TextInlineViews in Fabric Android
Reviewed By: JoshuaGross, shergin
Differential Revision: D21541159
fbshipit-source-id: 4741ab96964c35af1c1b7d3e821e505ecef2efce
Summary:
Adds the package name (Android) / bundle ID (iOS) as a new URL parameter named `app` in the bundle URL. This currently has no effect on Metro, which will ignore it for bundling / caching purposes.
Changelog: [General] - Add package name / bundle ID to bundle URL in development
Reviewed By: cpojer
Differential Revision: D21429764
fbshipit-source-id: 394fe50dba72219f7594ebeac9486a8264a836a6
Summary:
ReactViewManager uses the bridge (CatalystInstance) to access the UIManagerModule in its onClick method. This doesn't work in bridgeless mode, so I'm replacing this callsite with the new API, which uses UIManagerHelper + the reactTag to look up the appropriate UIManager (Paper or Fabric), and get the EventDispatcher from that.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D21510243
fbshipit-source-id: c2c6111e73c49ca6bf873819db8ece71c66417e4
Summary:
This early return is a very minor perf optimization, and it complicates things on Fabric: if scroll perf logging is disabled, the scroll position in C++ (State) doesn't get updated for the scrollview.
Just remove it. Always run the Runnable, no matter what.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D21503695
fbshipit-source-id: 13dfe232d692ff544bff725a2344a66b572f5444
Summary:
This issue fixes https://github.com/facebook/react-native/issues/27649.
By using 2d decomposition that transforms a skewX into a rotate/scale/rotate, the skewX issue on Android was still there which made me suspect that the issue came from the decomposition algorithm. Then I noticed that the bug existed in the JavaScript decomposition as well which led me to a fix on the JS and therefore on the Android side most likely.
## Changelog
[Android] [Fixed] skewX transforms
Pull Request resolved: https://github.com/facebook/react-native/pull/28862
Test Plan:
Check that skewX works on Android.
On JS, making sure that processTransform() doesn't skip, you can try the following sequence:
```tsx
const matrix = processTransform([{ skewX: `${Math.PI / 3}rad` }]);
const result = MatrixMath.decomposeMatrix(matrix);
console.log({ result });
```
Differential Revision: D21493021
Pulled By: shergin
fbshipit-source-id: 89f7aca5fbfd0f0f8c6f90a26bd76bf8550acaa5
Summary:
Problem: ScrollView offset was not being reported to the C++ ScrollView side of Fabric.
This results in taps not working correctly, for example if you tap a button inside scroll view after you scrolled, the tap might not trigger anything.
The root cause of this is our implementation of detecting whether scroll view has stopped scrolling.
To make this more robust, I now require that multiple "frames" have not scrolled because it's easy to trigger race conditions by scrolling very fast.
We also explicitly call `updateStateOnScroll` in a couple more places.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21496396
fbshipit-source-id: 2e565dd2fc4fc1ce582daa8a449c520e7cb19be0
Summary:
This diff refactors the FrescoModule in order to receive an ImagePipeline as a parameter. This is necessary to ensure the same ImagePipeline is used by every RN module
changelog: [Internal][Android]
Reviewed By: JoshuaGross
Differential Revision: D21428346
fbshipit-source-id: 70a6cc57c8585fe74b6d0b0d1fd86c539974ec23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28851
This diff creates a RuntimeExecutor that uses the bridge and exposes it on CatalystInstanceImpl.
Changelog: [Internal]
Reviewed By: mdvacca, RSNara
Differential Revision: D21051949
fbshipit-source-id: b3977fc14fa19089f33e297d29cedba0d067526d
Joshua Gross
David Vacca
Emily Janzer
Jacek Burys
Ishan Khot
generatedunixname89002005287564
Vojtech Novak
Kevin Gozali
Ram N
Samuel Susla
Moti Zilberman
Lulu Wu
William Candillon