Summary: I think this array is copied when we call the function over the JNI, and that we need to free the local copy we make.
Reviewed By: mdvacca
Differential Revision: D17377077
fbshipit-source-id: 82fe4ec89e95335a329f4ce562441561dbe88693
Summary:
Collapse many Remove/Delete mount items into a single batched item.
Since a delete is always preceded by a remove mountitem, we can batch these into one instruction. Since deletes tend to come in large blocks, it might make sense to batch many into a single instruction.
Reviewed By: mdvacca
Differential Revision: D17254631
fbshipit-source-id: abfd54cdb0bbb9a4c0880ec8e8bbd681367aecd4
Summary: Retain reference to reactNativeConfig to allow feature checks within core. This also rearranges the members of Binding to make them private instead of public.
Reviewed By: mdvacca
Differential Revision: D17275344
fbshipit-source-id: 67ad00aeebd3534a45a6ea8a28e14b7fcd9eb2e5
Summary: We were using an alias_ref which is like a raw pointer (not managed/retained); as it turns out, everywhere (?) else we accept an alias_ref we convert it to a global_ref (see Binding.cpp, JMessageQueueThread). We've just gotten lucky to not have already hit use-after-free errors.
Reviewed By: mdvacca
Differential Revision: D17275200
fbshipit-source-id: 581a51da36e96c353ed1117e9e0f428e65d36d69
Summary:
Log every item in a BatchMountItem. There's a lot of useful debug information being hidden there currently.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D17254629
fbshipit-source-id: c72f0aa8506059da5225ebead24d3f8ead5bdebd
Summary:
We probably don't always need to crash in these cases.
This should replace all prod/dev crashes with logged SoftExceptions.
Note that this is currently only used for Fabric.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D17170459
fbshipit-source-id: 70757ae88deb8c893b36971d879174e25a194fb9
Summary: Support for `sendAccessibilityEvent` in the FabricUIManager.
Reviewed By: shergin
Differential Revision: D17142507
fbshipit-source-id: 5c131d7caa1e4189fd41ecfb558d0027394b6a15
Summary:
The purpose of `EventBeat` is handling an asynchronous callback to itself which is being delivered on some different thread. That brings a challenge of ensuring that the `EventBeat` object stays valid during the timeframe of callback execution. The concept of Owner helps with that.
The owner is a shared pointer that retains (probably indirectly) the `EventBeat` object. To ensure the correctness of the call, `EventBeat` retains the owner (practically creating a retain cycle) during executing the callback. In case if the pointer to the owner already null, `EventBeat` skips executing the callback.
It's impossible to retain itself directly or refer to the shared pointer to itself from a constructor. `OwnerBox` is designed to work around this issue; it allows to store the pointer later, right after the creation of some other object that owns an `EventBeat`.
Reviewed By: JoshuaGross
Differential Revision: D17128549
fbshipit-source-id: 7ed34fd865430975157fd362f51c4a3d64214430
Summary: This diff implements the JSResponderHandler methods in the core of RN (scheduler API and friends)
Reviewed By: ejanzer
Differential Revision: D16543437
fbshipit-source-id: dac03e30c4330d182ecf134f3174ba942dbf7289
Summary:
This diff adds the new API required to implment JSResponderHandler in FabricUIManager
The new API differs from the old API, but since setJSResponder is called ONLY from JS it's not necessary to have this method as part of UIManager interface.
Reviewed By: JoshuaGross
Differential Revision: D16543440
fbshipit-source-id: ca4bd4c1e4df706cda0eb16798e01f3350558d06
Summary: This fixes the lint that was broken by D16543439
Reviewed By: fkgozali
Differential Revision: D16607092
fbshipit-source-id: 70c3989d25f446ffe0877e58253acef5ada8e010
Summary:
View Pooling is not currently being used in Fabric Android, this diff removes all the extra abstractions that are being used becuase of the unused ViewPooling.
We might add this in the future when we re-implement view correctly.
Reviewed By: JoshuaGross
Differential Revision: D16543439
fbshipit-source-id: f41b6e02fddc36c7ef7a1052399d2e6b2041fcfb
Summary: For Litho interop and to resolve T47926405, always pass props and state to Create mount item so that any ViewManager can create view instances with knowledge of initial props and state.
Reviewed By: mdvacca
Differential Revision: D16554082
fbshipit-source-id: 3b19a43347b0fa201a054eec60e82fb77cad3625
Summary: I think it's possible that there's a race condition between creating the scheduler and setting the delegate leading to bugs like T47272192.
Reviewed By: mdvacca
Differential Revision: D16537737
fbshipit-source-id: 9c579537658be5a9aeed37c0e4935c997cabb6aa
Summary: I'm only renaming the new `addRootView` that I added (which takes the moduleName, and uses startSurfaceWithConstraints), since the other one implements the UIManager interface method that's shared with paper.
Reviewed By: shergin
Differential Revision: D16432425
fbshipit-source-id: 392af42690052551504676df776bac6d1a968785
Summary: Right now RuntimeExecutor is only used in Fabric. Moving it out of Fabric's uimanager/primitives.h and into react/utils so we can use it more broadly.
Reviewed By: shergin
Differential Revision: D16385366
fbshipit-source-id: 96063e536e1480bac078a9376fe55f7d8750477e
Summary: Easy diff to add extra debug information in the CreateMountItem class. This will be useful to debug bugs in Fabric
Reviewed By: JoshuaGross
Differential Revision: D16381362
fbshipit-source-id: 22073df228908b6c88e6423c4917fc6d64c73f98
Summary: Supporting View Manager Commands on the new UIManager in Fabric. This is needed for things like scrollTo on ScrollView.
Reviewed By: JoshuaGross
Differential Revision: D16175575
fbshipit-source-id: a74effdf7e47b56a150a4e3fb6c4d787659e0250
Summary: Right now we register ReactFabric as a callable module with the bridge so that we can call `ReactFabric.unmountComponentAtNode` in `ReactInstanceManager.detachViewFromInstance`. In bridgeless mode we don't have callable modules, so I'm just setting a global variable that can be called from C++ instead. Using this in a new `unmount` method in FabricUIManager.
Reviewed By: shergin, mdvacca
Differential Revision: D16273720
fbshipit-source-id: 95edb16da6566113a58babda3ebdf0fc4e39f8b0
Summary:
The method MountingManager.removeRootView is not used anymore D16275118, I'm deleting from MountingManager
motivation: cleanup as I'm fixing other bugs in Fabric
Reviewed By: ejanzer
Differential Revision: D16350582
fbshipit-source-id: 488cf2aa2feda78e6660a854af5da2718f9905de
Summary:
FabricUIManager.removeRootView() isn't currently used, removing it from the UIManager interface.
It looks like this is called from JS in paper renderers, but not Fabric, so we should be good to delete it.
Reviewed By: shergin, mdvacca
Differential Revision: D16275118
fbshipit-source-id: b8f3ae1dc7574ce17d8cc9e7fee72ef5dcc9b323
Summary:
Step 1 in removing the dependency on ReactContext from GuardedRunnable and other related classes. These are extensively by native modules and view managers, so in order to remove the bridge dependency from those modules we'll need to first decouple these classes from ReactContext. It turns out they only need ReactContext for its handleException method, which delegates out to product code. For backwards compatibility I'm exposing another NativeModuleExceptionManager in ReactContext that simply wraps its handleException method (since this interface already does everything we need).
I figured I'd keep around an extra constructor that still uses ReactContext for now instead of trying to migrate everything over at once.
Reviewed By: makovkastar
Differential Revision: D16270995
fbshipit-source-id: c9a8714bea7ac2a98e78234a0bae49140c00980d
Summary: This diff makes the Binding.commitMutex_ recursive, for more context see: D15995971
Reviewed By: shergin
Differential Revision: D16187220
fbshipit-source-id: 559d06e1e4a83d7beee13f41b4549db2b91983e5
Summary:
This diff migrates the usages Nullable and NonNull annotations to AndroidX instead of javax.
The purpose of this change is to bring consistency in the annotations used by the core of RN
Reviewed By: makovkastar
Differential Revision: D16054504
fbshipit-source-id: 21d888854da088d2a14615a90d4dc058e5286b91
Summary: Now, the signature of `updateState` method practically copies the signature of `updateLocalData`. We need that to support all features that `updateLocalData` does support now (to migrate from it).
Reviewed By: mdvacca
Differential Revision: D15962377
fbshipit-source-id: 61e0af6c191e0c6a358c5859613e9c512f91d29a
Summary: Originally, moving the mount instruction generation under the `if` was a perf optimization but now, since we converge `LocalData` and `State`, this is no longer possible (because we need to treat State as LocalData in some cases).
Reviewed By: mdvacca
Differential Revision: D15962378
fbshipit-source-id: 37f9fadb72ac53450c2d499452610d9835f2964d
Summary: This diff prevents the execution of MountItems without mounting instructions
Reviewed By: JoshuaGross
Differential Revision: D16063571
fbshipit-source-id: 97ff93c6880c7d8857f61d4998df4327f41fafdd
Summary: The method FabricUIManager.scheduleMountItems receives only one MountItem, is makes more sense to be called FabricUIManager.scheduleMountItem
Reviewed By: JoshuaGross, makovkastar
Differential Revision: D16062749
fbshipit-source-id: a27063be33b644af83ede6a9198edbfb1c3296e1
Summary: This diff exposes LayoutDirection as part of UpdateLayoutMountItem
Reviewed By: JoshuaGross
Differential Revision: D16060521
fbshipit-source-id: 163bf2a0bdca62dcecb03a8aaa2f4bf595b18c8f
Summary: This diff ensures only one thread access the Binding.schedulerDidFinishTransaction method
Reviewed By: shergin
Differential Revision: D15995971
fbshipit-source-id: 31f03803e8829480dd30b9b9148fd09b218ebeab
Summary:
This diff formats the Java class files inside xplat/js/react-native-github. Since google-java-format was enabled in D16071401 we want to codemode the existing code so that users don't have to deal with formatter lint noise at diff-time.
```arc f --paths-cmd 'hg files -I "**/*.java"'```
drop-conflicts
Reviewed By: cpojer
Differential Revision: D16071725
fbshipit-source-id: fc6e3852e45742c109f0c5ac4065d64201c74204
Summary:
Right now JS triggers a view manager command with the following code:
```
UIManager.dispatchViewManagerCommand(
ReactNative.findNodeHandle(this),
UIManager.getViewManagerConfig('RCTView').Commands.hotspotUpdate,
[destX || 0, destY || 0],
);
```
As we want to get rid of calls to UIManager, we need to stop looking for the integer defined in native from JavaScript. We will be changing methods like this to be:
```
UIManager.dispatchViewManagerCommand(
ReactNative.findNodeHandle(this),
'hotspotUpdate',
[destX || 0, destY || 0],
);
```
We need to support ints and Strings to be backwards compatible, but ints will be deprecated.
Reviewed By: shergin
Differential Revision: D15955444
fbshipit-source-id: d1c488975ae03404f8f851a7035b58a90ed34163
Summary: Removing the UiThread annotation from MountingManager.addRootView() because it doesn't seem like it's needed.
Reviewed By: mdvacca
Differential Revision: D15945819
fbshipit-source-id: 0cb9bfb2fe2889001f1c061a07518cf9734f0c16
Summary: This diff adds extra logging in FabricUIManager, this will be useful to debug production issues
Reviewed By: JoshuaGross
Differential Revision: D15907520
fbshipit-source-id: 94e16444af3c023b6c4837c4797404d3debe8e95
Summary: Previously, we didn't provide any LayoutContext to the very first commit (aka startSurface); apparently it causes problems.
Reviewed By: mdvacca
Differential Revision: D15891472
fbshipit-source-id: b2a785bdad5764eb97b41f5bf5679807107bd8a0
Summary: I added this function in D15810990, not sure why lint didn't complain about this...
Reviewed By: zackargyle
Differential Revision: D15880129
fbshipit-source-id: 4d207ba26be46186dc3904c82d82a4a83d4d4eb7
Summary:
It is possible that race conditions exist in access of scheduler and UIManager in Binding.cpp, such that deallocated or null schedulers/UIManagers could be passed as arguments into various functions, causing strange and exotic crashes down the line once garbage memory (or null pointers) are dereferenced.
I think it's possible that navigating away from a Fabric screen while there's high memory pressure could cause things to get deallocated more aggressively and cause scheduler and/or UIManager to disappear while mounting instructions are being created, for instance.
Reviewed By: mdvacca
Differential Revision: D15863193
fbshipit-source-id: a85cb71d88ea54826b40f44e788931dfc422f045
Summary: This diff forces the method: scheduler.constraintSurfaceLayout to run on the JS thread.
Reviewed By: JoshuaGross
Differential Revision: D15845768
fbshipit-source-id: de2aa69f301770aaf6cb7c3f5670548a3b6110df
Summary: Scheduler.startSurface accepts LayoutConstraints and LayoutContext, but for some reason we don't use these on Android. This diff adds new methods to Binding and FabricUIManager to start a surface with the provided measurespecs. I created new methods to avoid affecting the functionality of any surfaces already using Fabric, but if we want this behavior everywhere then I can just add it to the existing `addRootView` and `startSurface`.
Reviewed By: JoshuaGross, shergin
Differential Revision: D15810990
fbshipit-source-id: 6cd9a58b125461f91253458905405298cfb723ce
Summary: Just adding a few systrace sections to add perf visibility in a few more areas.
Reviewed By: ejanzer
Differential Revision: D15823394
fbshipit-source-id: 6ac1773cbd8e01a747ad015726e16c0bf0e8596b
Summary: Easy diff to create a ReactFeatureFlag to enabled logging in Fabric
Reviewed By: JoshuaGross
Differential Revision: D15803582
fbshipit-source-id: d735f24850bddf43c27b97d006100cbb8f0cc6e3
Summary:
... and slighly new behaviour for one of them.
The method does nothing if given `key` already exists in the container.
This diff finishes the transition of ContextContainer from an internal bag of things with unclear yet ownership into a legit dedicated dependency injection container for the product code.
The original names of methods imply that the container can have only one object of a given type which is no longer true. The new API is much more generic and idiomatic to C++, it mimics `std:map` API which is intuitive to anyone who familiar with C++ containers.
Besides the naming, `insert` method changed the semantic a bit; now it does nothing in case of inserting an object with a key that already exists. That might seem counterintuitive for "normal" people, but C++ has some wired reasons for that and, hopefully, it's expected behavior in the C++ community.
Fun fact: We need this to fix hot-reload.
Reviewed By: sahrens
Differential Revision: D15681736
fbshipit-source-id: 194f342528446a911eaf072ba3a94a5d8af3cb52
Joshua Gross
Valentin Shergin
David Vacca
Emily Janzer
Eli White
Oleksandr Melnykov