Summary:
Fixes a NPE in debug mode. This will only impact developers who have explicitly turned this debug flag on, so it's a very low-pri fix.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D24410825
fbshipit-source-id: 08c8a0c6d0e0fb7c132725ad6af9460b91a7edf3
Summary:
This diff creates the new TransparentImmersiveReactActivity in FB4A, the intention is to help integrate TransparentReactActivity with Fb4A
Changelog: [Deprecated][Android] Deprecated method UIManagerModule.getUIImplementation. This method will not be part of the new architecture of React Native.
Reviewed By: stashuk
Differential Revision: D23324543
fbshipit-source-id: 35395fe410790a9611a4637361b888678eb0a836
Summary:
Make sure to check incoming state values before calling SetState, or we call back and forth forever.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D23389355
fbshipit-source-id: 9cf6110cf654fe93f555a6fbfd9b20f112214e0a
Summary:
This diff extends test-react-native-oss-android-legocastle to test the build of RNTester with fabric enabled in Sandcastle
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23141524
fbshipit-source-id: 396dae1c0a23ce03db1053de1627eacb09a6df94
Summary:
Update FabricViewStateManager so that the caller can bail out of updates by returning null.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22966024
fbshipit-source-id: 31cd9ec8a9a9918fbb94844e30ed1a2fcc61997d
Summary:
iOS will need to be implemented separately, but the shared C++ bits are in place.
Explanation: there is currently no way for the View layer to /know/ if an UpdateState call has succeeded or failed. Generally we just assume it succeeds, but if it fails we have no way of knowing or retrying.
This can cause some UI bugs. To mitigate this, I'm introducing a "failure" notification callback mechanism. The JNI bridging for this is a little complicated to avoid passing Runnable across the JNI, but it
should be much simpler on iOS.
In development this seems to make View components much more reliable.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22940187
fbshipit-source-id: 917f2932ae22d421f91fe8f4fca3f07dc089f820
Summary:
With BackgroundExecutor+State Reconciliation, it is pretty common to have races where View layer UpdateState calls are thrown away.
Theoretically this is /always/ possible since C++ doesn't retry failed UpdateStates, we just try once and then bail. This is part 1 of improving our mechanisms for ensuring that State stays up-to-date from the View layer.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22933927
fbshipit-source-id: 77b3b87402f772e3f149be0f9200e673bbed7b57
Summary:
This diff fixex a NoSuchMethodException when calling DisplayMetricsHolder.initDisplayMetrics in Android API level <= 16.
changelog: [Android][Fixed] Fix NoSuchMethodException when calling DisplayMetricsHolder.initDisplayMetrics in Android API level <= 16
Reviewed By: fkgozali
Differential Revision: D22630603
fbshipit-source-id: d2a95445beb5745a89ee1eefdf0d24ce3e0b8893
Summary:
Changelog: [Internal] Fabric-specific internal change.
This diff introduces a new value for `YGPositionType`: `YGPositionTypeStatic`.
No part of Yoga, RN, Litho or CK uses this value yet. `relative` and `static` values behave the same way for now. We also do not change any defaults. So, it should be fine.
Reviewed By: SidharthGuglani
Differential Revision: D22386732
fbshipit-source-id: 39cd9e818458ac2a91efb175f24a74c8c303ff08
Summary:
This diff fixes a ConcurrentModificationException that is thrown when registering events in React Native.
This bug was introduced by D22483508 (https://github.com/facebook/react-native/commit/80f13412e548c8666b6ad770e6d3d5c54a717bc2), before event listeners were registered in the NativeModule Thread, now they are registered in the UI Thread.
As part of this diff I change the type of mListeners variable to use CopyOnWriteArrayList instead of ArrayList because this variable is accessed from different threads. This will prevent the exception to happen, but additionally we need to verify if the change of threading made in D22483508 (https://github.com/facebook/react-native/commit/80f13412e548c8666b6ad770e6d3d5c54a717bc2) will cause any other issue (e.g. events not being delivered becuase the listeners are registered too late in the UI Thread)
changelog:[Internal]
Reviewed By: JoshuaGross
Differential Revision: D22599747
fbshipit-source-id: 5c5e46710c4a559badbd713f536e6e6e464fda23
Summary:
`UIManagerHelper.getUIManager()` relies on the bridge (CatalystInstance) to get the proper UIManager depending on which renderer is being used. Unfortunately, this means it will always return null in bridgeless mode, where the CatalystInstance doesn't exist. This diff replaces the implementation of `BridgelessReactContext.getJSIModule()` to return the FabricUIManager from the ReactHost/Instance.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22480968
fbshipit-source-id: 640e3f22a5b39b315ed2f0397be3cba39e80529a
Summary:
Expose `resolveCustomDirectEventName` from UIManager interface for Bridgeless Mode+NativeAnimatedModule.
We cannot remove the interface from the Non-Fabric UIManagerModule yet, as it would break downstream open-source dependencies, so I just marked it deprecated.
Note that this still doesn't totally fix issues with Bridgeless mode: generally I have to navigate to a Bridgeless surface, exit it, and then navigate back, and only on the 2nd navigation does everything seem to work properly...
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22483508
fbshipit-source-id: 685126e7e51aa5d0fd60ad5d4ecc44e8c6c3029d
Summary:
The previous assumption was that any animations would result in `addAnimatedEventToView` being called. That's not true in all cases, so sometimes we never subscribed to Fabric lifecycle events, preventing animations from working on some screens and for Venice.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22483509
fbshipit-source-id: c97576675902b4b9e1d4e659c7c1e24c5fe92946
Summary:
This PR adds support for the `shadowColor` style on Android.
This is possible as of Android P using the `setOutlineAmbientShadowColor` and `setOutlineSpotShadowColor` View methods. The actual rendered color is a multiplication of the color-alpha, shadow-effect and elevation-value.
## Changelog
`[Android] [Added] - Add support for shadowColor on API level >= 28`
Pull Request resolved: https://github.com/facebook/react-native/pull/28650
Test Plan:
- Only execute code on Android P
- Added Android `BoxShadow` tests to RNTester app
Reviewed By: mdvacca
Differential Revision: D21125479
Pulled By: shergin
fbshipit-source-id: 14dcc023977d7a9d304fabcd3c90bcf34482f137
Summary:
In https://github.com/facebook/react-native/commit/0b63c9464872fed9ff3eb388e32850f2f8c69561, I shipped "Early ViewCommand Dispatch" everywhere but didn't provide a good summary in the commit message.
Here it is:
The "Early ViewCommand Dispatch" experiment was a success, leading to improved UI responsiveness and fewer overall crashes.
Ship to all Fabric and non-Fabric users, and clean up the code a bit.
# Context: what?
ViewCommands are now used in React Native to do things like scroll ScrollViews to a certain position; focus or blur a TextInput; control the value of controlled TextInputs; and much more. These used to be done using setNativeProps, but we're moving everything to ViewCommands, and most of that migration has already finished.
# Context: Why?
Because Fabric does not support setNativeProps, there has been an effort to move all setNativeProps callsites to ViewCommands. Since these callsites are in JS where we can't tell if we're running in Paper or Fabric, both Paper and Fabric callsites are being migrated (mostly already done) to ViewCommands. One such example is Android TextInput, which has been using ViewCommands instead of setNativeProps for several months.
This migration was largely without issues, except TheSavior and I noticed early on that certain things were just... slower with ViewCommands. It was definitely noticeable, but we determined it to be acceptable and moved on.
Recently, it became clear to me that the perf regression may not be acceptable, but there might be an "easy" solution.
# Why are ViewCommands slower than SetNativeProps?
So, a couple things. SetNativeProps on Paper would actually cause a layout pass; the same is not true for ViewCommands, so they should actually be much faster. But they're not! The reason is that ViewCommands are treated as regular mount items, and they are queued up /after/ all other mount items. That means if you're trying to interact with the UI while some part of it is updating, your ViewCommands must wait for portions of the screen to finish rendering before they execute.
In some cases, those views may even disappear before the ViewCommand executes, causing increased exceptions as well as speed degredations.
# Proposal
This experiment that ran with successful results was: to execute ViewCommands /before/ all other types of mount instructions (by maintaining a separate queue). That means if you tap on a TextInput to focus it while the screen is doing some heavy rendering, the next time the UIManager executes a batch of instructions, it will execute the focus operation out-of-order, at the very beginning. From a user perspective this is actually quite noticeable, and works much better than the older behavior.
# Why it's Not That Dangerous
* Is it possible that we'll execute instructions after the corresponding view has disappeared? This was already possible, and is actually less likely now, since it's more likely that the ViewCommand will execute before the Delete instructions executes.
* Is it possible we'll execute instructions BEFORE the view is created? Yes, this is possible and I actually found a repro for it. My solution: allow ViewCommands to be retried, exactly once. If they throw an exception the first time, we requeue which will cause the command to be executed after the current batch of mount items. Interestingly, this seems to be unnecessary in Fabric, so the logic there is a bit simpler (probably because on Android we do view preallocation under Fabric, so views are created way before they're inserted into the view hierarchy, and apparently before ViewCommands have a chance to execute).
* ViewCommands are already an imperative feature that exists outside of the normal React commit cycle. So they're already dangerous. This doesn't change that, but it does make dangerous code *faster*, so that's good.
Changelog: [Android][Changed] ViewCommands on Android now execute earlier, as a perf optimization.
Reviewed By: mdvacca
Differential Revision: D22343648
fbshipit-source-id: 310d94977ac8ca3140ee8aa272272f660efafa36
Summary:
Early ViewCommand dispatch: ship the experiment everywhere on Android.
Since ViewCommands are totally divorced from the commit cycle currently, and since they are inherently unsafe, we can create a separate queue for them
and retry them if they fail with a specific category of exceptions.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22173050
fbshipit-source-id: 494b7c6b5dfd2aec8ba77ae35d0d58d4d727b9b4
Summary:
This diff fixes a race condition that caused a flicker during initial rendering of TextInput in Fabric
The root cause is that the TextInput's State is sometimes initialized with no information from the Theme, this causes text input to be rendered with 0 padding. Later ReactTextInput manager updates TextInput state with theme data and the TextInput is re-rendered with the correct padding information.
changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D22034849
fbshipit-source-id: a2fa91f34a8340878f2ec8d231ef6c86cee08f05
Summary:
Similar to D21756178, we cannot rely on childCount since it can return zero when there are actually valid children. This both causes more exceptions than necessary when the operation would work, and pollutes error messages since the information is not strictly reliable.
Instead, we just try to get a View and thrown an exception when it's null, or in loops, loop until we hit a null child. `getChildAt` doesn't throw exceptions, it just returns null when we're out-of-bounds.
This can impact custom ViewGroups like BottomSheets, and other ViewGroups that might do interesting/weird things with children, including ReactClippingViewManager.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22035569
fbshipit-source-id: 43e98d81178faaf720face98fc84e78743f292c3
Summary:
This diff migrates usages of RCTEventEmitter.class to EventDispatcher.dispatchEvent.
RCTEventEmitter is not compatible with Fabric, now we need to use EventDispatcher.dispatchEvent instead.
changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D21982549
fbshipit-source-id: 9ea2d9a00f063a03c2e401fc1e328ce26bcf48df
Summary:
This diff exposes receiveEvent on the UIManager class. This is necessary to support backward compatibility between Fabric and classic RN
changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D21979687
fbshipit-source-id: 1ec75896687d55e699f79c520e21f05fac368ee6
Summary:
In the past, in Fabric (Android), we never called stopSurface. Ever! This is bad for memory and can cause other issues, so... let's not do that.
Instead, when the ReactRootView is being torn down, we check the View ID to see if it's a Fabric RootView, and if it is, we call Fabric's stopSurface method.
Fabric stopSurface only has impact on (1) Fabric mount instructions being executed after that point and (2) tells JS to stop running the surface, on the JS thread, asynchronously.
Anecdotally it looks like all the MountItems involved in deleting and removing views from the hierarchy are executed before stopSurface is called.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21965837
fbshipit-source-id: 5169c5a1e339fd9e016ae1234d8389b2bd30be70
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:
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 (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:
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:
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:
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:
This diff fixes a NullPointerException thrown when calling measureLayout function on a virtual node.
changelog: [Android] Fix measureLayout function for VirtualTexts
Reviewed By: JoshuaGross
Differential Revision: D21435030
fbshipit-source-id: aba6d81f333464e49d2d769b111842e7ae8ce769
Summary:
This diff refactors the initial render of Fabric in order to set the layout metrics as we start the surface.
This prevents to create an additional fabric commit during initial render. Also this migth help fixing T63495589 (I wasn't able to repro T63495589 again when using this diff)
changelog: [Internal][Android] Internal change to reduce the amount of commits during initial render of Fabric
Reviewed By: JoshuaGross
Differential Revision: D21330072
fbshipit-source-id: 758c49b52ea4c12d5623b7c7d68c7318f4a6cd83
Summary:
This diff reduces exposure of UIManagerModule in the NativeAnimatedNodesManager class, this is necessary to enable NativeDriverAnimations in Venice
changelog: [Internal][Android] Internal change to enable native driver animations in RN bridgless mode
Reviewed By: ejanzer
Differential Revision: D21317629
fbshipit-source-id: 81cd4ade296de4757acefe566e1466154d6b4e4b
Summary:
This is the codemod portion of the parent diff.
I modified all call-sites to `ReactContext.getNativeModule` to do a null check on the returned NativeModule.
Changelog:
[Android][Fixed] - Check if NativeModules returned from CatalystInstanceImpl.getNativeModule are null before using them.
Reviewed By: JoshuaGross
Differential Revision: D21272028
fbshipit-source-id: 6bd16c6bf30605f2dfdf4c481352063712965342
Summary:
On Android, when using split-screen mode, the Window-relative position of a native View is not calculated properly when the app is running on the right (or bottom) half of the screen. The coordinates are currently calculated only based on View.getLocationOnScreen() with subtracting status bar height. Scenarios, where the window does not fill the entire screen (such as split-screen mode) are not supported.
We need to use a more general solution to subtract the actual position of the window from position of the view within the screen. This PR fixes the issue by subtracting coordinates of the Window retrieved from View.getWindowVisibleDisplayFrame(), which covers all scenarios when Window can be in a different position than the screen (incl. status bar offset).
## Changelog
[Android] [Fixed] - Calculating view position within the window in split-screen mode
Pull Request resolved: https://github.com/facebook/react-native/pull/28449
Test Plan:
1. Run an app in split-screen mode on the right half of the screen
2. Call UIManagerModule.measureInWindow() from JS to fetch a position of a View within a Window
3. Observe the wrong coordinates returned
4. Try the same with the fix
Reviewed By: mdvacca
Differential Revision: D21246297
Pulled By: shergin
fbshipit-source-id: 1f54b1a5d6610be17bf05521200304db2ba263ab
Summary:
Changelog: [Internal]
Flip text alignment in case layout direction is RTL.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D21130371
fbshipit-source-id: cf56ca052c17a48e321803b0f99f8a4baaa0e67b
Summary:
Easy diff to add a TODO to refactor `sendAccessibilityEvent` to use ViewCommands
This was orginally added D17142507
changelog: [Internal] Internal change
Reviewed By: JoshuaGross
Differential Revision: D21137348
fbshipit-source-id: aff38ccad8dfbb222f83161e2bd5da82f543e5db
Summary:
This diff adds a temporary Feature Flag to control a fix in TextInlineView (see previous diffs of the stack)
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20812920
fbshipit-source-id: 90fece9b29ba173546d96e4d9baf1ccabb3031b2
Summary:
This diff cleans the variable NativeViewHierarchyOptimizer.mTagsWithLayoutVisited right after all the view updates for a rootShadowNode have been processed by the UIImplementation class.
This intends to fix the bug reported in the task: T61185028, which root cause seems related to the fact that the variable NativeViewHierarchyOptimizer.mTagsWithLayoutVisited is not cleaned up when updating multiple rootShadowNodes as part of the same batch
changelog: [Android][internal] internal bug fix
Reviewed By: JoshuaGross
Differential Revision: D20812921
fbshipit-source-id: 28067ee29a931d7a9e9c33c90aceb4e3512dac1a
Summary:
Remove unused feature flag. This is not used within Facebook and I'm not aware of usage outside of FB.
Changelog: [Removed] Removing Android feature flag: lazilyLoadViewManagers
Reviewed By: mdvacca
Differential Revision: D20788210
fbshipit-source-id: 435316e3de7830d7cb7f14537351883e4fc6eeaa
Joshua Gross
David Vacca
Valentin Shergin
Emily Janzer
Hein Rutjes
Luna Wei
Kevin Gozali
Ram N
Lulu Wu
William Candillon
Ramanpreet Nara
Jakub Kinst
Samuel Susla
