Summary:
After animation has been finished using Native driver there is no final value passed from the native to JS side. This causes a bug from https://github.com/facebook/react-native/issues/28114.
This PR solves this problem in the same way as `react-native-reanimated` library. When detaching it is calling native side to get the last value from Animated node and stores it on the JS side.
Preserving animated value even if animation was using `useNativeDriver: true`
Fixes https://github.com/facebook/react-native/issues/28114
## 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
-->
[Internal] [Fixed] - Save native Animated node value on JS side in detach phase
Pull Request resolved: https://github.com/facebook/react-native/pull/28841
Test Plan: Unit tests for added getValue method passed. Green CI
Reviewed By: mdvacca
Differential Revision: D22211499
Pulled By: JoshuaGross
fbshipit-source-id: 9a3a98a9f9a8536fe2c8764f667cdabe1f6ba82a
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 avoids accessing window and activities object that has dissapear
changelog: [Android][Fix] Fix crash when updating RN dialog props after the activity disappeared
Reviewed By: JoshuaGross
Differential Revision: D22264672
fbshipit-source-id: 89c9895c8c6b6fec383a0e160847e5059616e265
Summary:
This diff avoids calling to the method setStateListAnimator for users running in Android API < 21 (This method did not exist in Android API < 21)
changelog: [Android][Fix] Fix crash while measuring ReactSlider in Android API < 21
Reviewed By: lunaleaps
Differential Revision: D22164574
fbshipit-source-id: 8163f99eeb78302fc75e2c4938330c699ca8d363
Summary:
Searching for details and maybe a fix for T68843308 crashing in disconnectFromView, "Attempting to disconnect view that has not been connected with the given animated node".
May be related to recent refactoring but it's not clear. Change logic slightly and add more diagnostic information.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D22153179
fbshipit-source-id: b95dbaf01ae8bca154c61442898b0f9d3aebb4de
Summary:
This diff refactors the theme management for text input in order to avoid extra state updates.
changelog:[Internal]
Reviewed By: JoshuaGross
Differential Revision: D22149754
fbshipit-source-id: 8a6dbe63c8d532986dbf785c7b16323e0a980669
Summary:
This is a useful debugging tool that will not be compiled by default, and we have some protection to only compile it in Debug builds so it's less likely to accidentally slip into production.
This has been useful for debugging C++ LayoutAnimations, since Remove/Insert mutations are delayed and fiddled around with a little.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22148853
fbshipit-source-id: 05609507cdf06b73fd3edf5cf7bc95e124ff1135
Summary:
It is possible (most recently, if there are bugs in LayoutAnimations, but also in general) to issue a `removeViewAt` MountItem that removes the incorrect view if, for whatever reason, the View hierarchy has become "corrupt"
and Views are out of order. I added two heuristics to catch if that happens: check the tag of the View being removed if possible, and ensure that all deleted views do not have a parent. This will turn weird visual glitches into
hard crashes, which we want once the UI has become corrupt.
My only concern here is with perf; maybe we could put these behind a debug-only flag or something, but it's probably not a huge deal.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22130186
fbshipit-source-id: 0942b019c3449d68edfb9db1fe8130ea351d1d8f
Summary:
Adjusts the behavior of `blurRadius` for `Image` on Android so that it behaves more closely to other platforms (web and iOS).
Changelog:
[Android][Changed] - Effect of `blurRadius` now more closely matches other platforms.
Reviewed By: shergin
Differential Revision: D22118680
fbshipit-source-id: c6d14aef29b4a086e43badfa78407bfa07f9fee2
Summary: This diff updates the loading banner text and color on Android to match its style on iOS.
Differential Revision: D22066823
fbshipit-source-id: 7f8d6cf1a6c4c48babe919995044978d7a81c674
Summary:
If UIManager disappears, it's likely due to (1) teardown due to memory pressure, (2) teardown due to crash, (3) normal teardown.
In all of those cases, I would just want NativeAnimatedModule to stop executing and fail silently ASAP.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22079209
fbshipit-source-id: 21650abdfdb119a6f4abccd6962d0c09f7c7c6cd
Summary:
Adds support for the `onProgress` event on `Image`, for Android.
Since Fresco does not provide a progress listener on `ControllerListener`, this uses a forwarding progress indicator `Drawable` to pass along values from `onLevelChange`.
Caveat: The ratio between `loaded` and `total` can be used, but `total` is currently always 10000. It seems that Fresco does not currently expose the content length from the network response headers.
Changelog:
[Android][Added] - Adds support for the `onProgress` event on `Image`
Reviewed By: mdvacca
Differential Revision: D22029915
fbshipit-source-id: 66174b55ed01e1a059c080e2b14415e7d268bc5c
Summary:
Changes the `onLoad` and `onError` events on `Image` to be consistent with each other and with the `ImageSource` type.
Changelog:
[Android][Breaking] - On `Image`, `onLoad` and `onError` event objects will no longer have an extra `uri` property.
[Android][Breaking] - On `Image`, `onLoad` event objects' `source.url` is now renamed to `source.uri`.
[iOS][Breaking] - On `Image`, `onLoad` event objects' `source.url` is now renamed to `source.uri`.
Reviewed By: mdvacca
Differential Revision: D22023565
fbshipit-source-id: 5ea7904c697f87e01118bdb81ed50ab0a5aecdce
Summary:
Cleans up `ImageLoadEvent` to minimize constructor confusion and to make the dispatching logic more predictable.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D22023141
fbshipit-source-id: 17e66de867f51121a3f9a6b782dbad700a54231a
Summary:
Since we were not busting the `surfaceActiveForExecution` cache, it is very possible (likely, even!) that a surfaceId is invalidated in between UI ticks but we keep executing items for that surface at the next tick.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22055303
fbshipit-source-id: 351c13535e85b30e00684fe35fc4aa79ccb5961c
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:
This diff changes the order of execution for the "updatePadding" mount item
Padding mountItems must be executed before layout props are updated in the view. This is necessary to ensure that events (resulting from layout changes) are dispatched with the correct padding information.
This fixes a 'flickering' bug in Marketplace Vehicles (see test plan)
changelog:[internal]
Reviewed By: JoshuaGross, sammy-SC
Differential Revision: D22034850
fbshipit-source-id: 222fa9412dd01f65a1a034f53e1eb0e7b774ec1f
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:
In particular, NativeAnimatedModule relies on having some signal of when there's a commit from ReactJS. In Fabric, this is the only reliable signal. Failing to call scheduleMountItems even when there's no changes to the tree will result in certain animation operations being delayed way longer than necessary.
I pass nullptr instead of empty arrays in some cases to hopefully improve perf.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22008981
fbshipit-source-id: 6bdeb46e03b5138dbfa5b077952ec0fa3dfe1eb3
Summary:
Switch between "Fabric" and "Non-Fabric" modes based on which types of native Views are being attached to animations. Don't allow non-Fabric to drive Fabric animations and vice-versa.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21985411
fbshipit-source-id: fb9bef1e38375b384430b4e0275e7b6d62eda7a4
Summary:
This diff refactors ReactTextView to use uiManager.receiveEvent instead of ReactEventEmitter. ReactEventEmitter.class should be replaced for uiManager.receiveEvent.
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D21982548
fbshipit-source-id: 4ed5825f62c761564aa533f4e8bb1155036df7e2
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:
Because of the previous diffs there's an increased chance of race conditions between JS executing and queuing up PreAllocateViewMountItems for surfaces that are stopped. Make sure those are ignored if they're queued up and a surface has been stopped.
Currently stopSurface only happens on the UI thread; PreAllocateViewMountItems can be queued from any thread, but are only executed on the UI thread. So once a batch of items starts executing, there's no race between teardown and execution: we just need to make sure we check that the surface is still running initially.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21965839
fbshipit-source-id: 0241dc171022cc923b7e38dcd110d664096dde79
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 diff disables the state list animator from the ReactSlider object used to measure ReactSlider.
The motivation is to fix T63030542, which it seems to be caused by the state list animator being accessed and modified from different threads
We don't have a way to reproduce, but based on my analysis this diff will fix T63030542.
I would like to land this diff and then keep tracking production data for the crash reported on T63030542
Changelog:
[Android][Fixed] Fix intermittent crash of ReactSlider on Android
Reviewed By: fkgozali
Differential Revision: D21920698
fbshipit-source-id: 54af388043d5041c4bf981c81364780d3f52d818
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28875
Update Fabric's Android binding to use a RuntimeExecutor instead of the `jsContext`, which is actually just the runtime pointer. This diff uses the RuntimeExecutor from CatalystInstanceImpl (in the previous diff) which uses the bridge under the hood.
Changelog: [Android][Changed] Modified Fabric's public-facing API on Android
Reviewed By: mdvacca
Differential Revision: D21051975
fbshipit-source-id: 9c17ad1986f90c12af457d88a5035553e0e7ceb0
Summary:
Introduce SurfaceId to the BatchMountItem. Do not execute it if the associated Surface has gone away.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21895452
fbshipit-source-id: 5df56720ce9b4293693884ebe105bda1dc87700e
Summary:
As a simple refactor, I want to 1) have `synchronouslyUpdateViewOnUIThread` only catch exceptions for the specific MountItem being synchronously executed, 2) not assume that scheduleMountItem will always cause synchronous execution.
I think this makes the logic here a little more clear and it scopes how we swallow exceptions, which could be swallowing too many errors right now actually.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21911804
fbshipit-source-id: 1b1a465cadd60c72c69b556469276c9ee6b2dfcc
Summary:
Changelog: [Internal]
# Problem
`MountingCoordinator` holds a pointer to instance of `MountingOverrideDelegate` which becomes invalid.
# Solution
Use `std::weak_ptr` instead of raw pointer so it is possible to tell whether the pointer is expired.
Reviewed By: JoshuaGross
Differential Revision: D21905351
fbshipit-source-id: c7bf9635742a6ec086a03ba83202e46e1f1f373f
Summary:
These logs are no longer necessary, because data indicates that the TurboModule eager init crash was fixed.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D21852743
fbshipit-source-id: ddeefd6396283ee5e15980a33fb006cb83a81532