Summary:
Now that the PFH node has been renamed this updates the pfh label.
Produced via `xbgs -l -e '"pfh:ReactNative_CommonInfrastructurePlaceholde"' | xargs sed -i 's/"pfh:ReactNative_CommonInfrastructurePlaceholde"/"pfh:ReactNative_CommonInfrastructurePlaceholder"/'`
Reviewed By: jkeljo
Differential Revision: D35374087
fbshipit-source-id: 61590f69de5a69ec3b8a0478f6dd43409de3c70b
Summary:
ModuleDataCleaner.cleanDataFromModules(**ReactContext**) is just like ModuleDataCleaner.cleanDataFromModules(**CatalystInstance**). However, one key difference is that this new method is bridgeless mode compatible. CatalystInstance doesn't exist in bridgeless mode.
Changelog: [Android][Added] Introduce ModuleDataCleaner.cleanDataFromModules(ReactContext)
Reviewed By: sshic
Differential Revision: D35286939
fbshipit-source-id: 1c09a3b34add88f848eab43b42b39ab624f0818b
Summary:
## Rationale
The CatalystInstance exposes a public API that returns a list of all instantiated NativeModules: [CatalystInstance.getNativeModules()](https://www.internalfb.com/code/fbsource/[d9cd2e5dd41fc3e3022bfb777c8b31c92af8c537]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/bridge/CatalystInstance.java?lines=73).
This enables a use-case: process all NativeModules that conform to a particular interface, to, for example, remove sensitive data before logging out.
## Changes
This diff moves that CatalystInstance.getNativeModules() API into the ReactContext. This allows us to migrate NativeModules leveraging this use-case off of ReactContext.getCatalystInstance(), which makes them bridgeless-mode compatible.
Changelog: [Android][Added] Introduce ReactContext.getNativeModules()
Reviewed By: sshic
Differential Revision: D35286940
fbshipit-source-id: 1b64351aa3f65ee59e6438a7a95974e219ccc69c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33535
Hack to support Kotlin functions in Buck compilation: adds Kotlin stdlib as a dependency to make sure upstream targets include Kotlin jvm internal classes.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35284430
fbshipit-source-id: 0d29ad30386514c8df5376d0a6809d3105f0cd0f
Summary:
Aligns naming with `JWritableMapBuffer` and other fbjni classes to indicate that it is a JNI binding.
Changelog: [Internal] - Rename C++ part of ReadableMapBuffer to JReadableMapBuffer
Reviewed By: mdvacca
Differential Revision: D35219323
fbshipit-source-id: a7eb644a700a35dc94fa18e4fb3cc68f2cfa3e99
Summary:
Updates `ReadableMapBuffer` to conform to `MapBuffer` interface, to allow interchangeable use of `Readable/WritableMapBuffer` in the code.
Notable changes:
- MapBuffer.Entry getters are now represented as Kotlin properties and appended `Value` suffix (e.g. `entry.getInt()` becomes `entry.getIntValue()` in Java, or `entry.intValue` in Kotlin)
- `ByteBuffer` is imported in constructor instead of on demand. This method doesn't copy the data as the bytes are read directly from native heap, and benchmarking a 500-byte `MapBuffer` shows no difference in import speed.
- Internal logic of `ReadableMapBuffer` uses `UShort` kotlin type for key retrieval, for more correct representation of values.
- Explicit exception throws are replaced with `require` and `check` methods for `IllegalArgumentException` and `IllegalStateException` (default FB conversion).
The change also updates `ReadableMapBuffer` usages to `MapBuffer` interface where possible (virtually everywhere except JNI methods).
Changelog: [Android][Changed] - Adopt `MapBuffer` interface for `ReadableMapBuffer`
Reviewed By: mdvacca
Differential Revision: D35218633
fbshipit-source-id: 515dd974c27b2978ade325b2e1750ab8f068a20a
Summary:
Creates a `WritableMapBuffer` abstraction to pass data from JVM to C++, similarly to `ReadableMapBuffer`. This part also defines a Kotlin interface for both `Readable/WritableMapBuffer` to allow to use them interchangeably on Java side.
`WritableMapBuffer` is using Android's `SparseArray` which has almost identical structure to `MapBuffer`, with `log(N)` random access and instant sequential access.
To avoid paying the cost of JNI transfer, the data is only transferred when requested by native `JWritableMapBuffer::getMapBuffer`. `WritableMapBuffer` also owns it data, meaning it cannot be "consumed" as `WritableNativeMap`, with C++ usually receiving copy of the data on conversion. This allows to use `WritableMapBuffer` as JVM-only implementation of `MapBuffer` interface as well, e.g. for testing (although Robolectric will still be required due to `SparseArray` used as storage)
Changelog: [Android][Added] - MapBuffer implementation for JVM -> C++ communication
Reviewed By: mdvacca
Differential Revision: D35014011
fbshipit-source-id: 8430212bf6152b966cde8e6f483b4f2dab369e4e
Summary:
While it would be better to be able to do all of the ownership metadata at the Buck macro level, that proved to be more work than expected.
This diff adds the corresponding pfh label to all targets in `xplat/js/react-native-github` that have a Supermodule label. Once the migration is complete the Supermodules labels will be able to be removed.
Reviewed By: cortinico
Differential Revision: D35221544
fbshipit-source-id: d87d5e266dfb5e6ee087251dc34dff5db299bbaf
Summary:
As per commit: https://github.com/facebook/react-native/commit/4f3b17412018a10f9293247c802598d2b94a844b which states that "React Native requires that the RootView id be managed entirely by React Native, and will crash in addRootView/startSurface if the native View id isn't set to NO_ID."
This behaviour can not be guaranteed in **hybrid** apps that have a native android layer over which ReactRootViews are added and the native views need to have ids on them in order to work. **The control of views can jump back and forth between native android and react-native (fabric). As the ReactRootView is added to ViewGroups (or layouts) in Android Fragments and Activities, they contain ids on their views which might get passed down to the reactRootView by features like DataBinding**
Hence this can cause unnecessary crashes at runtime for hybrid apps even when they are not changing the id of the reactRootView object they are adding to their ViewGroups.
Our app is a hybrid app that uses both native android and react-native on different screens and on one such screen that has a Fragment adding a ReactRootView to its FrameLayout to render native android views to render in ReactNative, this crash occurs on pressing the back button as well as on unlocking the screen while staying on the same screen.
The app was running fine on more than a 100 million devices on React Native 0.63.4 but after updating to 0.67.2, that features this commit, it crashes on the very first device it was tested on.
Refer to the issue: https://github.com/facebook/react-native/issues/33121 for more information on the crash
The fragment in which this issues arises is like this:
```binding.frameLayout.addView(getReactRootView())```
where getReactRootView() is like this:
```
private var mReactRootView: ReactRootView? = null
private var mReactInstanceManager: ReactInstanceManager? = null
mReactRootView = ReactRootView(context)
if (activity != null) {
val application = activity?.application
if (application is MainApplication) {
mReactInstanceManager = application.reactInstanceManager
}
}
fun getReactRootView():View?{
return mReactRootView
}
```
So converting this to a soft exception such that pure react-native devs can still see the error while hybrid apps continue to run without crashes.
### Snippet of the change:
```
if (getId() != View.NO_ID) {
ReactSoftExceptionLogger.logSoftException(
TAG,
new IllegalViewOperationException(
"Trying to attach a ReactRootView with an explicit id already set to ["
+ getId()
+ "]. 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."));
}
```
## Changelog
[GENERAL] [ADDED] - A ReactSoftException log instead of a direct exception being thrown:
```
if (getId() != View.NO_ID) {
ReactSoftExceptionLogger.logSoftException(
TAG,
new IllegalViewOperationException(
"Trying to attach a ReactRootView with an explicit id already set to ["
+ getId()
+ "]. 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."));
}
```
[GENERAL] [REMOVED]- Directly throwing an exception even when the code is not responsible for this issue:
```
if (getId() != View.NO_ID) {
throw new IllegalViewOperationException(
"Trying to attach a ReactRootView with an explicit id already set to ["
+ getId()
+ "]. 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.");
}
```
Pull Request resolved: https://github.com/facebook/react-native/pull/33133
Test Plan:
This crash is hard to reproduce but when it occurs, this is the only way to fix it.
If any app used to crash with this exact error, it will no longer crash but show an error log in Logcat for developers to be informed about the issue.
Reviewed By: ShikaSD
Differential Revision: D34304212
Pulled By: cortinico
fbshipit-source-id: f0eaeef2e905a6e0587df088b43cc49cabda397a
Summary: This diff adds flag to `ReactRootView` to control if the touch event is to be dispatched to the JS side. This is needed for subclass of `ReactRootView` to control if the dispatch is needed.
Reviewed By: javache
Differential Revision: D35033684
fbshipit-source-id: febab6988cc3e4259e726d03d797dd0ffc978d24
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33472
Changes native build of ReactAndroid to CMake instead of ndk-build. Removes a few workarounds around AGP issues with ndk-build which seems to be working with CMake by default.
Changelog: [Changed][Android] - Use CMake to build ReactAndroid module
Reviewed By: cortinico
Differential Revision: D35018803
fbshipit-source-id: af477937ed70a5ddfafef4e6260a397ee9911580
Summary:
Aligns two codepaths for measure, making sure we can use both MapBuffer and ReadableMap for measuring components.
Changelog: [Internal] - Align measure interface for MapBuffer experiment
Reviewed By: javache, mdvacca
Differential Revision: D34960317
fbshipit-source-id: a39eb84a0abb4414717463f2f1741e470be3531f
Summary:
The context could be null or is finishing when we create the redbox surface content view. This diff adds the null check and delegate the message in log when context is not available.
Changelog:
[Android][Fixed] - Adding null check for context in redbox surface delegate
Differential Revision: D34930595
fbshipit-source-id: 91508ded7821033abcd893f70bcfe3cc9ee5b5c2
Summary:
sSpannableCache is a significant user of Java heap memory - up to 0.22MB is retained by sSpannableCache.
It turns out sSpannableCache was never hitting as hashCode is different for the same attributedString contents. attributedString.getInt("hash") provides the expected hash code.
This indicates removing spannableCache will not affect perf. Will gate just in case though.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D34900414
fbshipit-source-id: 7563cde6ba9dc153072e7aebede99389ce3153e7
Summary:
Adds CMake files to configure hermes-executor build, with the same setup as we have in Android.mk
Changelog: [Internal] - CMake build config for hermes executor
Reviewed By: cortinico
Differential Revision: D34811909
fbshipit-source-id: 2df6dbaf46131db87a25e26c83b38ba44f29d1d3
Summary:
Sticky headers (via OCScrollTrackerStickyHeader) did not work with RN because overscroll does not trigger onScroll events.
This diff adds a listener to overscroll, which then emits scroll events.
Changelog:
[Internal][Changed] - Changed ScrollEvent's scrollX and scrollY to float
---
# Context
GamingActivity headers are part of the FlatList; on overscroll (when you scroll up when you're already at the top of the FlatList), the header is translated via Animated's native event. The problem on RN is that onScroll is not fired during overscroll (due to how overscroll-decor works - it merely applies a translation on the scroll view itself).
Scroll events propagate to the native animated events as follows:
- ReactScrollView.onScrollChanged -> ReactScrollViewHelper.updateStateOnScrollChanged -> ReactScrollViewHelper.emitScrollEvent -> EventDispatcher.dispatchEvent -> NativeAnimatedNodesManager.onEventDispatch
# Approaches
Two approaches were considered to fix sticky headers:
- [Implemented in this diff] Attach a listener on OverScrollDecor and fire onScroll events. I ran into 2 main issues with this:
- The header clips as the scroll view is translated down. This is fixed via setting clipChildren.
- Move headers out of FlatList, and translate the header only for positive scroll offsets.
- Requires product-side code changes
- Hover outline is cut off by the header
- Click-drag to scroll does not work on the header
Reviewed By: javache
Differential Revision: D34696042
fbshipit-source-id: 15450f31a7042ce67cdffc74614f4f7b9684d0ca
Summary:
We were opening the file multiple times just to read the same couple of bytes.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D34835972
fbshipit-source-id: 9de899f37a9193db4ab72e69e02e8d41e5515da0
Summary:
This Diff moves from specifying a list of files to use file(GLOB) with
CONFIGURE_DEPENDS on several CMakefiles.
I've updates those where we use globbing also inside buck.
Changelog:
[Internal] [Changed] - Setup Globbing with CONFIGURE_DEPENDS inside CMake files
Reviewed By: ShikaSD
Differential Revision: D34826311
fbshipit-source-id: 8fc654626c897cdc4cdd79c699ce19f1e5e1212f
Summary:
When the `snapToOffsets` prop is empty array, the scroll view would crash unexpectly. This diff fixed that by treating empty array prop as null value for `snapToOffsets`.
Changelog:
[Android][Fixed] - Fix crash on empty snapToOffsets array
Reviewed By: makovkastar
Differential Revision: D34802022
fbshipit-source-id: af330512e444081b0cb02b65288ec5cd2bd14205
Summary:
Rearranges folly_futures configuration into a static library only required for `hermes-inspector` + `folly_runtime` which merges `folly_json` and mutex-related implementations `folly_futures` was used for. As `hermes-executor-debug` is removed by `vmCleanup` configurations later, it allows to shave additional 300KB from the release APK size.
Changelog: [Internal] - Rearrange folly build to reduce APK size
Reviewed By: cortinico
Differential Revision: D34342514
fbshipit-source-id: b646680343e6b9a7674019506b87b96f6007caf2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33396
This commit fully unplugs the `ReactAndroid` from using hermes from the NPM package and plugs the usage of Hermes via the `packages/hermes-engine` Gradle build.
I've used prefab to share the .so between the two builds, so we don't need any extra machinery to make this possible.
Moreover, I've added a `buildHermesFromSource` property, which defaults to false when RN is imported, but is set to true when RN is opened for local development. This should allow us to distribute the `react-native` NPM package and users could potentially toggle which source to use (but see below).
Changelog:
[Android] [Changed] - Build Hermes from Source
Reviewed By: hramos
Differential Revision: D34389875
fbshipit-source-id: 107cbe3686daf7607a1f0f75202f24cd80ce64bb
Summary:
This is the first round of CMake files to support the React Native build on Android.
They're supposed to eventually replace the various Android.mk files we have around in the codebase.
So far we're not actively using them. This is the first step towards migrating our
setup to use CMake
Changelog:
[Internal] [Changed] - First Round of CMake files for React Android
Reviewed By: ShikaSD
Differential Revision: D34762524
fbshipit-source-id: 6671e203a2c83b8874cefe796aa55aa987902a3b
Summary:
Proguard seems to keep Fabric methods a bit differently from Redex, with method signature lookup with `MountItem` and `StateWrapperImpl` failing in release RNTester builds because of mangled names. Adding these annotations should keep the classes, ensuring lookup from native is correct.
Changelog: [Internal] - Add DoNotStrip annotations to Fabric related classes
Reviewed By: ryancat
Differential Revision: D34726510
fbshipit-source-id: 0c1d8e1fabec75511942943b533ddd8b637a5e19
Summary:
using namespace in header file is a bad practice due to many reasons as well as discouraged by `-Wheader-hygiene` compiler flag which is default for many apps
https://stackoverflow.com/questions/5849457/using-namespace-in-c-headers
Changelog:
[General][Fixed] - Fixed compilation warning due to `using namespace` being used as part of header
Reviewed By: nlutsenko
Differential Revision: D34788523
fbshipit-source-id: 2a50fbf2ac3371ff5670c600c7f5ad9055060ad2
Summary:
Blocks on queue write/drain for Animated module under a feature flag to test whether it resolves race conditions.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D34752947
fbshipit-source-id: a1b1a286772d29a7a27b5e9c3f743cac84cc2bab
Summary:
This diff fixed an issue that caused regression in fb4a and React Native panel apps regarding scrolling behavior. When scrolling in either horizontal or vertical scroll view, if the consecutive touch interrupted the previous fling (post touch scrolling), the scroll view would block touch event from dispatching to the content view. Thus, the items in scroll view are not responding to touch events anymore.
The diff that caused this issue is D34627330 (https://github.com/facebook/react-native/commit/0368081858193d7c2537acd9080d11bb701ee98b). In that diff, I added code to cancel the scheduled post touch runnable when touch down is received in scroll view. That is expected as the post touch runnable is to handle snapping scroll case, where [an extra fling](https://fburl.com/code/7qza1ece) is triggered to make sure scroll view stops at the right position. When user touch the screen before the previous scroll fling finishes, this post processing is no longer needed -- the new touch should take full control of scroll view.
However, in D34627330 (https://github.com/facebook/react-native/commit/0368081858193d7c2537acd9080d11bb701ee98b), I failed to reset the runnable instance `mPostTouchRunnable` to null when cancelling it. This caused the future post touch handle logic [stops to run](https://fburl.com/code/lh8pi7l0), as it thinks the runnable is non-null and has been scheduled. This prevents fabric from receiving proper scroll state updates from android side, thus causing a state corruption and affects logic to decide where the scroll offset is and where the child item is after that.
This diff fixed the issue by resetting the runnable instance, as well as making sure if the runnable is already running and the extra fling starts, we are canceling that fling animation properly.
Changelog:
[Android][Fixed] - Fixed regression on content in scroll view not responding to touch when fling got interrupted
Reviewed By: ShikaSD
Differential Revision: D34734129
fbshipit-source-id: 7d7689d203ce76c59cd44e16e31582317bb409bd
Summary:
Changelog: [internal]
To avoid unnecessary string copy in event pipeline, use move semantics.
Event pipeline has ownership of event type. Passing it by reference ends up in a copy when `RawEvent` object is constructed. To avoid this, pass string by value through each layer and use move semantics to avoid extra copies.
Reviewed By: javache
Differential Revision: D34392608
fbshipit-source-id: c11d221be345665e165d9edbc360ba5a057e3890
Summary:
Typically, ReactTextView#setText is called via ReactTextViewManager#updateExtraData, but natively animated color changes bypass render and layout pass via direct call to SurfaceMountingManager#updateProps from UIManager#synchronouslyUpdateViewOnUIThread.
Thus, for animated color changes to get applied, we need to handle the color prop in ReactTextAnchorViewManager.
In addition, native driver updates are not synchronized with Fabric's mounting; if the native driver update happens before mount, the update is done in updateState.
Changelog:
[Android][Added] - Support animating text color with native driver
Reviewed By: mdvacca
Differential Revision: D34630294
fbshipit-source-id: c0f1e19c801c0e909e84387d623a6556ce6f2d67
Lorenzo Sciandra
Christoph Purrer
Chris Olszewski
Ramanpreet Nara
Andrei Shikov
Luna Wei
fabriziobertoglio1987
Lulu Wu
CodemodService Bot
Kunal Farmah
Xin Chen
Pieter De Baets
Genki Kondo
Nicola Corti
Arthur Kushka
Samuel Susla
caioagiani
David Vacca
skychx
