Summary:
[Android] [Fixed] - LayoutAnimations cause invalid view operations
The dating team has found a consistent repro where following an order of steps will get you the following exception:
https://lookaside.facebook.com/intern/pixelcloudnew/asset/?id=2113362972287761
The exception is due to the fact that the following operation
`delete child tag 17 from parent tag 481 which is located at index 2`
cannot be performed because parent tag 481 only has 2 children.. and they also happen to not have the tag 17 as a child. Somehow the operations and the tree they act upon are out of sync.
RN receives operations from React via the native module `UIManagerModule`. The operations use tags (an identifier for a view) and indices to determine what view is updated. These operations (grouped together as a batch) are then passed to the UI thread where we perform them on the platform views.
LayoutAnimations are implemented per batch in RN. When LayoutAnimations are on, qualified view updates are animated. Because the delete operation is animated, RN doesn't remove the view from the platform view hierarchy immediately but asynchronously -- after the animation is complete. This is problematic for other view operations that rely on an index on where to insert or delete a view because during the creation of those operations, it was assumed all prior operations were performed synchronously.
This is what was occurring in the repro and there were silent view errors occurring before the exception was thrown.
This diff proposes a solution to track all pending delete operations across operations.
We introduce a map that is keyed on view tags and has a value of a sparse array that represents child index -> count of views that are pending deletion.
`{11: [0=1], 481: [2=1]}` where this would be interpreted as for index 0 under view tag 11, there is one async view deletion that has not completed and under tag 481 there is one async view deletion at index 2.
We use the map to adjust indices on add / delete operations. We also update the count when the deletion animation is complete and remove the tag from the map when it is deleted.
Regarding worst case sizing of the map => O(# of platform views rendered)
Reviewed By: mdvacca
Differential Revision: D14529038
fbshipit-source-id: 86d8982845e25a2b23d6d89ce27852fd77dbb060
Summary:
setNativeProps ends up calling UIManager.updateView which fails to find the view tag in the Paper UIManager and crashes.
This diff simply checks if the tag is managed by fabric, and calls `fabricUIManager.synchronouslyUpdateViewOnUIThread` if it is.
Not the ideal fix, but it generally works (js-driven animations work as well as in Paper) and it's better than crashing or not working at all.
Reviewed By: JoshuaGross
Differential Revision: D14414523
fbshipit-source-id: 0acd404f55094f8ce8eda39cb87ab58c727fb068
Summary:
Changes our property access pattern to iterate through props once and pass the Object value directly rather than looking the value up in the map with the key.
Note some ViewManagers methods (especially yoga related ones on shadow nodes) expect a `Dyanamic`, so this diff also creates Dynamic's only when needed by the hand-written code, and introduces a new `DynamicWithObject` to create them that simply wraps the underlying object (as opposed to `DynamicWithMap` which wraps the map and does a lookup any time the `Dynamic` is accessed.
Reviewed By: mdvacca
Differential Revision: D14453300
fbshipit-source-id: df98567b6eff1e6b7c611f179eb11e413fb94e5d
Summary:
This diff migrates RN to AndroidX.
As part of this diff I disabled few tests in RNAndroid OSS that will be re-enabled this week. As part of the refactor of BUCK files in OSS
Reviewed By: shergin
Differential Revision: D14200097
fbshipit-source-id: 932fcae251d1553e672acd67ecd0e703dcb364aa
Summary:
1. add role description for heading
2. add talkback navigation support for link and header
Fixes#22440
Pull Request resolved: https://github.com/facebook/react-native/pull/22447
Differential Revision: D14205822
Pulled By: cpojer
fbshipit-source-id: 86bfc3bfc851f3544b1962012abaf8d1a357a9d2
Summary:
Add nullable annotations to BaseViewManager and ViewManager methods. This will improve Kotlin developer experience and help Android Studio to offer better autocomplete.
[Android] [Changed] - add nullable annotations to BaseViewManager and ViewManager methods. Might break ViewManagers in Kotlin.
Pull Request resolved: https://github.com/facebook/react-native/pull/23610
Differential Revision: D14198630
Pulled By: mdvacca
fbshipit-source-id: c596c88254e1d02f0af233a466f685200fac8917
Summary:
Instead of using measure specs to set certain yoga properties on the root node (like max width, auto width, specific width), use yoga's calculateLayout(width, height) instead. The measure specs will be stored in the shadow node. This allows us to remove duplicated code that processes the measure specs and allows us to remove other logic like the enableLayoutCalculation() method.
This diff also removes MeasureSpecProvider. MeasureSpecProvider was originally introduced to pass previously measured view measure specs to the initial creation of the root shadow node, but it turns out that this is unnecessary. We can update the root layout specs from the root view instead.
Reviewed By: mdvacca
Differential Revision: D9729744
fbshipit-source-id: 79b0b27ca879758f5dc3fc7cc8a0d38856a6cc79
Summary: This task fixes an AssertionError in EventDispatcher class, this is produced by a race condition.
Reviewed By: JoshuaGross
Differential Revision: D14134907
fbshipit-source-id: 7b670ee35e47c0d8a9f7f7b68a3b8f7193b7de54
Summary:
@public
Switches instance creation from `new YogaNode()` to `YogaNode.create()`.
This allows for experimentation with different implementations, while maintaining API + ABI compatibility internally at FB, as well as for dependent projects in open source and elsewhere.
Reviewed By: amir-shalem
Differential Revision: D14122975
fbshipit-source-id: f194b146b7cd693dba1a7dafdf92d350e54cb179
Summary: Use the new copyright header format used elsewhere in the React Native repository.
Reviewed By: shergin
Differential Revision: D14091706
fbshipit-source-id: b27b8e6bcdf2f3d9402886dbc6b68c305150b7d5
Summary: This allows using this annotation when Buck has `java.abi_generation_mode = source_only` set.
Differential Revision: D14119311
fbshipit-source-id: 020e709924e70adb8a160069a1da9b209b99befa
Summary:
This diff refactors JNI methods used by the Binding.cpp class in order to use ReadableMap instead of ReadableNativeMap
This will be helpful to provide a different implementation of ReadableMap from C++
Reviewed By: shergin
Differential Revision: D14077762
fbshipit-source-id: 595b0c2d3a2d6070112257b65c1141a8af36f0e1
Summary: SizeMonitoringFrameLayout was used to set layout contraints on the root shadow node when the native view's size changes. Since then, we introduced ways for the root node to use proper layout contraints using the root view's measure specs, which provides more accurate constraints for the root node, so SizeMonitoringFrameLayout is no longer needed. This ends up making a lot of UIManagerModule's method signatures cleaner
Reviewed By: mdvacca
Differential Revision: D9565720
fbshipit-source-id: c569cd15991a09987cc01e89612dc9193ad99b45
Summary:
Fix lint errors and warning, which might be a cause of various crashes on older Android OS, using Android Support Library.
```bash
./gradlew :ReactAndroid:lint
```
[Android] [Changed] - fix lint error/warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/23333
Differential Revision: D14019322
Pulled By: mdvacca
fbshipit-source-id: 74c98da269c318cf3b114c8d9c876186369f2b8c
Summary:
React Native's minSdkVersion is 16, or we support Android versions 16 (Jelly Bean) and above. But in the code we have many checks if Android is Jelly Bean or newer, which are unnecessary. This PR removes unnecessary Android version checks, also uses Android version names instead of numbers.
[Android] [Changes] - remove unnecessary Android version checks
Pull Request resolved: https://github.com/facebook/react-native/pull/23277
Differential Revision: D13955909
Pulled By: cpojer
fbshipit-source-id: 6b1caa5ef4fe42273d3c69a6617fff140a697b5c
Summary:
There is a variation in iOS and Android output while performing perspective transformation. The variation exists even when used in Android devices with different screen density.
Pull Request resolved: https://github.com/facebook/react-native/pull/18302
Differential Revision: D13877483
Pulled By: cpojer
fbshipit-source-id: e48be047a8047c7562722923a67666cb098243d8
Summary:
Equivalent of this iOS PR: https://github.com/facebook/react-native/pull/20915
Motivation:
----------
Whenever a user changes the system font size to its maximum allowable setting, React Native apps that allow font scaling can become unusable because the text gets too big. Experimenting with a native app like iMessage on iOS, the font size used for non-body text (e.g. header, navigational elements) is capped while the body text (e.g. text in the message bubbles) is allowed to grow.
This PR introduces a new prop on `<Text>` and `<TextInput>` called `maxFontSizeMultiplier`. This enables devs to set the maximum allowed text scale factor on a Text/TextInput. The default is 0 which means no limit.
Pull Request resolved: https://github.com/facebook/react-native/pull/23069
Differential Revision: D13748513
Pulled By: mdvacca
fbshipit-source-id: 8dd5d6d97bf79387d9a2236fa2e586ccb01afde9
Summary: This diff reuses the ViewManager registry between UIManagerModule and Fabric, previously View Managers were being initialized twice (one for each UIManager), increasing Fabric TTI by ~77ms
Reviewed By: shergin
Differential Revision: D13640912
fbshipit-source-id: d7a9591084c66e4a2fc2384b2dae1b7fc5a228d0
Summary:
This diff moves the dispatching of views to the React Choreographer, this help to sort the mount of views following the order specified in the ReactChoreographer class.
This also enables synchronous and correct order for mounting of views that are dispatched in the UI Thread.
Reviewed By: sahrens
Differential Revision: D13444487
fbshipit-source-id: d8a43f473b07c9ccf7ea3bc9ab90545ec3c9ecee
Summary: It was pointed out to me in https://github.com/facebook/react-native/pull/22508 by raphael-liu that the error message refers to the wrong tag. I didn't merge the PR because I don't have good insight into the effects it could cause, but we should at least fix the error message.
Reviewed By: TheSavior
Differential Revision: D13564266
fbshipit-source-id: fa76f0888364df329d052dbcc2050f906d39dcef
Summary:
This diff fixes a NPE that can occur when we force the dispatching of events when the EventDispatcher is not initized.
The fix consists on avoid posting the frame callback, if the internals of EventDispatcher are not initialized yet (same behavior used by the dispatchEvent method)
Reviewed By: fkgozali
Differential Revision: D13549147
fbshipit-source-id: ef3baeb536e8772fbd83024352a37af01c21d589
Summary: If a children of a root node is being removed and the Root Node is empty, it was likely already removed and cleaned previously, likely due to a race condition caused by RN's async nature. In those cases, let's avoid crashing the app and instead silently ignore the root view removal.
Reviewed By: fkgozali
Differential Revision: D13405817
fbshipit-source-id: 0179d10a88a2d19f1db5ea35b48cb83d9d7429a6
Summary: This diff ensures that Events delivered from the C++ side are actually processed. This is done forcing the execution of AsyncEventBeat.beat() in these cases
Reviewed By: shergin
Differential Revision: D13313955
fbshipit-source-id: b2785647913a640c2d557f4fa08d447845a540e9
Summary: I want the same instrumentation we did for the JS thread for the NM thread. This diff adds thread cpu time.
Reviewed By: alexeylang
Differential Revision: D13328876
fbshipit-source-id: 7b310956c52907ffbd881f864e1f8e774853d7f5
Summary: This diff adds support to cache the Spannable objects that are created during measure() and updateLocalData() for text
Reviewed By: shergin
Differential Revision: D13188599
fbshipit-source-id: 6547d8ce2bb8b1dfb3c91e64facff3ba0cd97472
Summary: This diff refactors the types used when Yoga requires to measure the size of a View in C++
Reviewed By: shergin
Differential Revision: D13124086
fbshipit-source-id: 89dfe80bb41b4fb2eaba84af630d52ef2509b1e1
Summary: This diff adds support for layout constraint when measuring text
Reviewed By: shergin
Differential Revision: D13111434
fbshipit-source-id: 0c8689e9ac8ce2281b03386f275d2a8e034f88d8
Summary: Scrolling with multiple fingers produced a redbox in Fabric
Reviewed By: shergin
Differential Revision: D13108544
fbshipit-source-id: 7b70b3f55f325448191adc48c782f2014b502ad6
Summary: These methods and variables were used by Android implementation of Fabric, these are not used anymore.
Reviewed By: shergin
Differential Revision: D13108547
fbshipit-source-id: d169eb58ba20f3bfe117a124f0494ff3a4fb5dce
Summary: If a root node is being removed and has an id of NO_ID, it was likely already removed previously, likely due to a race condition caused by RN's async nature. In those cases, let's avoid crashing the app and instead silently ignore the root view removal.
Reviewed By: mdvacca
Differential Revision: D13055140
fbshipit-source-id: ec10f4c79f2ba21614f52f57557f6b3d734c9461
Summary: There are cases where we're trying to drop a view that is not associated with a ViewManager. This is likely caused by race conditions that can occur if we're dropping a view from JS (when it's no longer used) but at the same time dropping it from native (when layout animation ends, when the rootview gets unmounted). In either of those cases, it should be safe to ignore the drop operation because the view was likely dropped already.
Reviewed By: mdvacca
Differential Revision: D13036643
fbshipit-source-id: 260ffb56d32a0d670ad08f449b8df165b2533195
Summary:
This diff refactors the exeuction of 'AsyncEventBeat.induce()' as part of the delivery of events of Fabric Android implementation.
The first part of the refactor moves the exeuction of onBatchEventDispatched out of the synchronization block for mEventsToDispatchLock. This lock is accessed from the UI Thread and executing the induce inside this synchronization block will affect UI,
The second part of the refactor is to ensure that the exeuction of the C++ method AsyncEventBeat.induce() always happen in the JS Thread.
Reviewed By: shergin
Differential Revision: D12861387
fbshipit-source-id: e1cd03467274a1c5fcd04b0ac7efdbe7169b14c3
Summary: This diff ensures that JS uses rootTags during navigation. A redbox will be rendered in debug mode when a non-rootTag is used during navigation. This change enables proper navigation for Fabric.
Reviewed By: shergin
Differential Revision: D10855198
fbshipit-source-id: a82aaa706cd62ce92143fa86d0a422c1ae439a50
Summary:
It works great on iOS, and mostly works on Android, and is now OTA'able as part of the screen config! Haven't done template view yet. One remaining issue:
Layout is borked on Android. I'm guessing the issue has to do with the timing of setting the constraints in `updateRootLayoutSpecs` and calling `mBinding.startSurface` which actually builds the shadow tree. If I try to call `updateRootLayoutSpecs` earlier, it just crashes immediately. Here's the layout it spits out, which clearly has -440 for the x of 420006, which is the RCTText component, causing it to get cut off on the left of the screen:
```
updateLayoutMountItem for reactTag: 420006 x: -440, y: -13, width: 931, height: 78
updateLayoutMountItem for reactTag: 420010 x: 26, y: 79, width: 0, height: 1651
updateLayoutMountItem for reactTag: 420012 x: 0, y: 26, width: 0, height: 158
updateLayoutMountItem for reactTag: 420016 x: 0, y: 210, width: 454, height: 454
updateLayoutMountItem for reactTag: 420018 x: 454, y: 210, width: 455, height: 454
updateLayoutMountItem for reactTag: 420022 x: 0, y: 690, width: 454, height: 454
updateLayoutMountItem for reactTag: 420024 x: 454, y: 690, width: 455, height: 454
updateLayoutMountItem for reactTag: 420028 x: 0, y: 1171, width: 454, height: 454
updateLayoutMountItem for reactTag: 420030 x: 454, y: 1171, width: 455, height: 454
updateLayoutMountItem for reactTag: 420032 x: 0, y: 1651, width: 0, height: 0
```
Reviewed By: mdvacca
Differential Revision: D12813192
fbshipit-source-id: 450d646af4883ff25184141721351da67b091b7c
Summary:
AndroidManifest.xml file in UIManager only defines minimum SDK version for whole namespace "com.facebook". But it is always redefined by build.gradle file because Gradle file has precedence.
https://github.com/facebook/react-native/blob/master/ReactAndroid/build.gradle#L273
Anyway Gradle is prefered way to define it. So i think it should be removed if it is not used for another purpose.
Pull Request resolved: https://github.com/facebook/react-native/pull/22044
Differential Revision: D12898251
Pulled By: hramos
fbshipit-source-id: 087b5cc45495109b5626c9cb232d0546c53fb709
Summary: Adds copyright headers to all files that are missing them.
Reviewed By: hramos
Differential Revision: D12837494
fbshipit-source-id: 6330a18919676dec9ff2c03b7c9329ed9127d930
Summary: Alternative to D10499861. If an app does not have an exception handler, context.handleException will still hard crash. Since this error is just saying that we're reusing an unexpected RootView, it might be safe to continue execution. Let's remove the exception for now while we investigate further
Reviewed By: mmmulani
Differential Revision: D10560413
fbshipit-source-id: 6c08a16cd250a019d2aef5afcaf3ba61534d29f7
Summary:
This is a bandaid fix to address a crash with a stack trace involving
```
com.facebook.react.uimanager.IllegalViewOperationException: Trying to add a root view with an explicit id already set. React Native uses the id field to track react tags and will overwrite this field. If that is fine, explicitly overwrite the id field to View.NO_ID before calling addRootView.
0+com.facebook.react.uimanager.NativeViewHierarchyManager.addRootViewGroup(NativeViewHierarchyManager.java:546) [inlined]
1+com.facebook.react.uimanager.NativeViewHierarchyManager.addRootView(NativeViewHierarchyManager.java:538) [inlined]
2+com.facebook.react.uimanager.UIViewOperationQueue.addRootView(UIViewOperationQueue.java:678) [inlined]
3+com.facebook.react.uimanager.UIImplementation.registerRootView(UIImplementation.java:216) [inlined]
4+com.facebook.react.uimanager.UIManagerModule.addRootView(UIManagerModule.java:355)
5+com.facebook.react.ReactInstanceManager.attachRootViewToInstance(ReactInstanceManager.java:1032)
6+com.facebook.react.ReactInstanceManager.attachRootView(ReactInstanceManager.java:726) [inlined]
7+com.facebook.react.ReactRootView.attachToReactInstanceManager(ReactRootView.java:524)
8+com.facebook.react.ReactRootView.startReactApplication(ReactRootView.java:377)
```
This crash seems to be happening because the root view's id is set to a non NO_ID value, but further up in the stack trace, UIManager.addRootView() is called which always sets the root view's id to NO_ID. It's not clear how this error is happening, but in this code path it's expected that addRootView should always ensure that the id is always reset. In order to avoid crashing for this, let's remove the exception and log the issue instead.
In the future, we should not be overloading the android view id field with these types of react native implementation details. The react tag should be stored as a view tag instead.
Reviewed By: mmmulani
Differential Revision: D10499861
fbshipit-source-id: 4dffedab4e7a34eee7f64bb43ec8209699521c73
Summary: UIImplementationProvider was removed as part of D8650376, this was a breaking change that caused problems in OSS. This diff introduces the concept of a deprecated UIImplementationProvider again to allow OSS community to upgrade to latest version of RN.
Reviewed By: achen1
Differential Revision: D10456317
fbshipit-source-id: 6817629524f927dfcb5ebc054dbfd983877b7606
Summary:
We're currently getting a redbox in Turkish when we try to convert the string 'easeInEaseOut' to an InterpolatorType. This is because I use toLowerCase() to compare the string without setting a locale; in Turkish, the capital letter 'I' doesn't convert to 'i' when you lowercase it, but rather to 'ı' (http://www.i18nguy.com/unicode/turkish-i18n.html).
Passing in a locale param to `toLowerCase()` fixes it. Also updating the test.
Differential Revision: D10315474
fbshipit-source-id: 54be3ff1d3f91cb2ec765ff705ac364b976b8c6f
Summary: This diff introduces the collapsable props in the viewProps. This prop is used in product code to prevent specific Views to be removed from the view hierarchy
Reviewed By: shergin
Differential Revision: D10254679
fbshipit-source-id: 637665b8998a86e29e839eb6d405a0fac354c8d3
Summary: Simplifying our OSS enums (remove private variables and methods) so that redex can more easily optimize them for us.
Reviewed By: achen1, Feng23
Differential Revision: D9812796
fbshipit-source-id: 11a8272db41ff04399d1cdf366e28ddf1b07b7be
Summary: D10138128 had some shamefully wrong boolean logic to determine whether we should customize the accessibility delegate. Previously, we did it if BOTH the accessibility label AND role were present. We should actually do it if EITHER are present.
Reviewed By: mdvacca
Differential Revision: D10182135
fbshipit-source-id: 209a8ab43f5869762843fe878cfd59a7b9b5ab1a
Summary: This diff introduces the concept of EventBeatManager, this is a class that acts as a proxy between the list of EventBeats registered in C++ and the Android side.
Reviewed By: shergin
Differential Revision: D10127857
fbshipit-source-id: a1956ca42d4c470fbc11cc9f30336a182fe7910c
Summary:
Second attempt at landing D9930713. Notes about the previous issue is mentioned as an inline comment below.
===========
We are currently iterating through each view manager to get its class name to pass to JS. JS uses this list to define lazy property accesses for each view manager to grab the constants synchronously. This results in each view manager's class loading immediately -- causing a small perf hit.
Let's avoid this view managers list entirely. JS is able to access each view manager directly by calling getConstantsForViewManager(name)
Reviewed By: axe-fb
Differential Revision: D10118711
fbshipit-source-id: 78de8f34db364a64f5ce6af70e3d8691353b0d4d
Summary:
The current accessibility implementation tries to generalize every view's accessibility node info by setting an accessibility delegate on every view -- regardless of whether or not any accessibility properties are set. This delegate however doesn't correctly set the appropriate accessibility node fields for every view. For example, ScrollViews needs AccessibilityNode.setScrollable(true) set, but the generic delegate does not account for this. For now let's avoid unnecessarily
setting an accessibility delegate on views that don't have any accessibility props set, which will likely fix the majority of these issues.
Reviewed By: mdvacca
Differential Revision: D10138128
fbshipit-source-id: b999b41e7256e3dce94cd70e9b944979d52f74fd
