Summary:
See previous diff for details on general approach and benchmarks.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D36676887
fbshipit-source-id: b177dcd19f1ea687bf7d2d4f2f637d2924723340
Summary:
Changelog: [Internal][Changed] - Make the same optimization on enter/leave/move pointer events being dispatched by a mouse input.
If any ancestor view is listening to enter/leave events (just capture) then we dispatch the enter/leave event.
Reviewed By: vincentriemer
Differential Revision: D36601638
fbshipit-source-id: d6b5c32ae50bcf000100bcb878ca2ca89bd5c02e
Summary:
This diff cleans up several Android Makefiles which we're not using anymore
as they've been replaced by CMake files.
There are still 3 Makefiles left, which I'm aiming to remove in the near future.
Changelog:
[Internal] [Changed] - Remove unused Makefiles from React Native core
Reviewed By: javache
Differential Revision: D36660902
fbshipit-source-id: 8afffac74d493616b0f9414567821cd69f4ef803
Summary: Changelog: [Internal] - Bypass dispatching an event if no view along the hierarchy is listening to it. Only applied for touch-based interactions. Next change will add optimization for mouse interactions
Reviewed By: vincentriemer
Differential Revision: D35739417
fbshipit-source-id: 134ffefef3bb4f97bf3e63b6bccc0caca464dfbd
Summary:
ViewManager does a null-check already, and so inside the `updateState` method, we can safely assume this parameter is no longer nullable.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D36545806
fbshipit-source-id: 92eefa518f11c17b91aa3da2e14066d36fa4f4c2
Summary:
This way we can avoid unnecessary ArrayList copies.
Changelog: [Android][Changed] Generalized the return type of ViewManagerOnDemandReactPackage.getViewManagerNames
Reviewed By: nlutsenko
Differential Revision: D36131516
fbshipit-source-id: 6a42c76cadbcce4c3720875d80062e1ee237bc2f
Summary:
Based on Google Play crash logs, crashes due to the assertions in `dispatchViewManagerCommand` is our top source of crashes:
```
com.facebook.react.uimanager.IllegalViewOperationException: Unable to execute operation dispatchViewManagerCommand: blur on view with tag: 17549, since the view does not exists
at com.facebook.react.uimanager.UIImplementation.assertViewExists(UIImplementation.java:830)
at com.facebook.react.uimanager.UIImplementation.dispatchViewManagerCommand(UIImplementation.java:713)
at com.facebook.react.uimanager.UIManagerModule.dispatchCommand(UIManagerModule.java:739)
at com.facebook.react.uimanager.UIManagerModule.dispatchViewManagerCommand(UIManagerModule.java:726)
at com.facebook.react.uimanager.ReanimatedUIManager.dispatchViewManagerCommand(ReanimatedUIManager.java:233)
at java.lang.reflect.Method.invoke(Method.java:-2)
at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)
at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:151)
at com.facebook.react.bridge.queue.NativeRunnable.run(NativeRunnable.java:-2)
```
There are many other places in UIImplementation that instead of throwing a fatal exception, just log a message and continues execution.
Logging a message and discarding the command should be safe for commands like "blur this view". We keep the previous behavior in debug mode, but just log and discard commands in production.
## 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
-->
[Android] [Fixed] - Avoid crash by handling missing views in dispatchViewManagerCommand
Pull Request resolved: https://github.com/facebook/react-native/pull/33795
Test Plan: We had a tough time reproducing specific crashes, but we ran with this binary in the latest release of our app and it has eliminated this class of crashes from Google Play and Bugsnag instrumentation.
Reviewed By: cortinico
Differential Revision: D36285603
Pulled By: JoshuaGross
fbshipit-source-id: db0be74926c4cb83f07686398579236da8e586bf
Summary:
Cherry picking https://github.com/facebook/react-native/pull/33707 to main branch
This change is extending the changes made by alespergl to reduce the file paths and command lengths of ndk build commands
Essentially we are shortening the length of the source files by using relative paths instead of absolute paths as enumerated by the wildcard expression
This commit is extending the fix by including all the new modules introduced into RN for the new architecture, including the generated modules.
We are also reverting the ndk bump as ndk23 is crashing frequently when building RN with new arch. The reduced file paths lengths ensures the ndk bump is not required for relatively short application paths.
Fix building RN with new architecture on Windows boxes by using relative paths for C++ sources
## Changelog
Fix building RN with new architecture on Windows boxes by using relative paths for C++ sources
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/33784
Test Plan: Verified building on windows box
Reviewed By: javache
Differential Revision: D36241928
Pulled By: cortinico
fbshipit-source-id: 1ce428a271724cbd3b00a24fe03e7d69253f169b
Summary: There's no need to use private feature flag for overflowInset feature. This makes future refactor on feature flags easier.
Reviewed By: javache
Differential Revision: D35866302
fbshipit-source-id: a3fde212ff40cd6d4c68832bb39b34de5a17a8d4
Summary:
The `notifyNativeGestureEnded` API is added to notify user gesture ended, so that any optimization we had during handling the gesture can be restored.
It's possible that when the gesture finishes, the RootView is already unmounted from the native side. This might happen when user starts a gesture that caused leave of the RN screen, or close the app.
Changelog:
[Android][Internal] - Avoid NPE for gesture notifier
Reviewed By: javache
Differential Revision: D35902523
fbshipit-source-id: 9bb5819a53dd053290031eebaae1b8f0318ae534
Summary:
Refactor of TouchTargetHelper.findTargetPathAndCoordinatesForTouch to avoid unnecessary lookup of views during the dispatching of Hover Events
changelog: [internal] internal
Reviewed By: lunaleaps, mdvacca
Differential Revision: D32296003
fbshipit-source-id: 93834c37331ad5d75645a5665a1c8c3d965765fb
Summary:
D34687371 (https://github.com/facebook/react-native/commit/7b5b114d578142d18bf4a7a5279b179a9ac8d958) unfortunately caused a regression with UIAutomator, where it would no longer be able to see any Views that have the ReactAccessibilityDelegate attached to them. This was because the delegate was changed to extend ExploreByTouchHelper which implements its own default AccessibilityNodeProvider, which does nothing in the case of a view without any virtual children.
This diff simply *only* uses the node provider if the view in question has virtual children, otherwise defaulting to the standard behavior from the View class.
Changelog:
[Android][Fixed] - Fixed issue where any node with an AccessibilityDelegate set (which was any node with any accessibility propoerty), was using ExploreByTouchHelper's built in AccessibilityNodeProvider, and not properly populating their AccessibilityNodeInfo's, leading to focus issues and issues with automated test services like UIAutomator.
Reviewed By: kacieb
Differential Revision: D35601320
fbshipit-source-id: 92e009c6e8b4ddcab860e2c91e6bd1a8f95359f0
Summary: Changelog: [Internal] - Fix pointer event dispatch to also fire enter/leave for ancestors in the hit path. Compared the event order with web on the RNTester W3C pointer example
Reviewed By: appden
Differential Revision: D35403076
fbshipit-source-id: 726e45e49a901b1d97ad3e20f5898701fd1f763b
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:
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:
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:
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:
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:
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:
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:
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
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33160
Enables Kotlin build in RNAndroid, while adjusting the package structure to help with path/package inconsistency.
Moves `react/uimanager/interfaces` files into `react/uimanager` to make sure package name matches with file location and updates Buck configuration to still include it as a separate target.
Changelog: [Android][Changed] - Moved `com/react/facebook/uimanager/interfaces` files into `com/react/facebook/uimanager` to enable Kotlin build
Reviewed By: cortinico
Differential Revision: D34381179
fbshipit-source-id: 252588d9c7f62b8019bdfcce66197628d63e63a1
Summary:
Was trying out some behaviour when using the MapBuffer experiment and fixed some small issues.
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D34108859
fbshipit-source-id: 550ca0847419006ec17472cc4b70d38fc8d05396
Summary:
Found that after backgrounding `mShouldStop` would always remain true, which prevents events from being dispatched / scheduled.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D34247567
fbshipit-source-id: 63876986dc0cee5e2a73cb4f8a35d90379d9f8ea
Summary:
Certain events (practically always touch events probably?) will not be correctly emitted to JS in Fabric if there is no View underneath the touch - if there is no touch target besides the ReactRootView.
We can just rely on the UIManagerType annotation on the Event, which is correct and reliable.
Instead, what we do today is derive UIManagerType from ViewTag, which is correct UNLESS the viewtag is the same as the SurfaceId, in which case we may incorrectly detect that the touch is on a non-Fabric View when in fact it is on a Fabric ReactRootView.
ViewTag is not a reliable way to detect Fabric vs non-Fabric /when looking at the RootView/, where ViewTag is the same as SurfaceId. Ironically, only Fabric RootViews have a SurfaceId at all.
Practically, this won't change anything since events emitted to ReactRootView don't go anywhere (they don't have EventEmitters). So this is a pretty low-stakes fix, but is still technically correct.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D34149878
fbshipit-source-id: f01da556865eb597a50cd49e9787316a0ed56f70
Summary:
The views with touch event props are currently flattened by Fabric core, as we don't take event listeners into account when calculating whether the view should be flattened. This results in a confusing situation when components with touch event listeners (e.g. `<View onTouchStart={() => {}} /> `) or ones using `PanResponder` are either ignored (iOS) or cause a crash (Android).
This change passes touch event props to C++ layer and uses them to calculate whether the view node should be flattened or not. It also refactors events to be kept as a singular bitset with 32 bit (~`uint32_t`).
Changelog: [Changed][General] Avoid flattening nodes with event props
Reviewed By: sammy-SC
Differential Revision: D34005536
fbshipit-source-id: 96255b389a7bfff4aa208a96fd0c173d9edf1512
Summary:
Update javadoc of ReactRoot.getState() since the task was fixed and the API remained the same
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D33981298
fbshipit-source-id: 0136a640b884a787b0a20162781735630c1fa1c7
Summary:
Changelog: [Internal]
Remove all the MCs that enable SVCs in Fabric, because we'll only test SVCs in Bridgeless mode to simplify rollout. There were complications with enabling SVCs in Fabric at a previous rollout.
Reviewed By: RSNara
Differential Revision: D33861243
fbshipit-source-id: fdbfedce77f8bd1bab2a807237017787ae8bf7c1
Summary:
This diff deletes the flag ReactFeatureFlags.enableReactContextCleanupFix, the flag was disabled for many months, I just disable it.
changelog: [internal] internal
Reviewed By: genkikondo, makovkastar
Differential Revision: D33781628
fbshipit-source-id: 4b5e22adf9d30da5b85bbbde8bdc98d98f5e8891
Summary:
The overflowInset uses negative values to indicate extending from parent view. This diff fixes the math so that it's correctly check if the point is within overflowInset.
Changelog
[Android][Fixed] - Fix math for detecting if children views are in parent's overflowInset area.
Reviewed By: genkikondo
Differential Revision: D33750129
fbshipit-source-id: 1a5a33a227280c687b158b4a81a56017b6f4f3e0
Summary:
Per discussion in the previous diff D33672110, it's ok to add the `pointerEvents` prop to scrollview. This will help prevent scrolling on the ScrollView if pointerEvents is set to `box-none`, or `none`.
Corresponding doc changes are in https://github.com/facebook/react-native-website/pull/2936
Changelog:
[Android][Added] - Add new API in ScrollView and HorizontalScrollView to process pointerEvents prop.
Reviewed By: javache
Differential Revision: D33699223
fbshipit-source-id: 1cae5113e9e7d988fc4c4765c41d817a321804c4
Nicola Corti
Joshua Gross
Luna Wei
Pieter De Baets
Harry Yu
Anandraj Govindan
Xin Chen
Moti Zilberman
fabriziobertoglio1987
Brett Lavalla
Chris Olszewski
Andrei Shikov
CodemodService Bot
Genki Kondo
Ian Childs
David Vacca
Paige Sun
grgr-dkrk
Ramanpreet Nara
Andres Suarez