Summary:
The `Event.getSurfaceIdForView` method I added recently is actually a duplicate of `UIManagerHelper.getSurfaceId`, except that the latter doesn't support RootViews very well.
Changelog:
[Android][Changed] - Improved UIManagerHelper.getSurfaceId and removed Event.getSurfaceIdForView
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D32102175
fbshipit-source-id: 01741df6b646037a4575e9ca302ea248af9fd6f3
Summary:
Ensures that copy of the native touch objects happens before consuming them.
The reverse order seems accidental after refactor, as copying objects doesn't consume them whereas adding to a native array does. This behavior didn't show up during testing in dev environment (only affects CANCEL events), and it seems to be the cause of high-firing crash on production.
Changelog: [Internal] Copy touch objects before consuming them in the new touch path.
Reviewed By: mdvacca
Differential Revision: D32112036
fbshipit-source-id: e9ec47689b7ceb0a40a23bab9f03367c4acb8632
Summary:
Makes new touch processing path check for double dispose on touch events.
Old event dispatcher has a race condition which makes it double-dispose some events, so we need to make sure it also processes touches correctly.
Changelog: [Internal] Check for double dispose when sending touch event
Reviewed By: cortinico
Differential Revision: D32110250
fbshipit-source-id: d6a12cbac60f9ff5e836cfaca5a47c467bea06c7
Summary:
When calculating the offset range, we assume the first item is always at offset zero position and skipped that (as the smallerOffset is zero). However, this may not be the case in some situations. This diff changes the range measuring loop to always start from the first item.
Changelog:
[Android][Fixed] - Do NOT skip the first child view in the scroll view group when measuring the lower and upper bounds for snapping.
Reviewed By: mdvacca
Differential Revision: D31887086
fbshipit-source-id: af7221a621b2719d057afa6b64aa91c94ac01295
Summary:
Some of the prerendered surfaces rely on Android context being present to have correct theming (e.g. for platform colors) and measurements of platform components. This change uses context provided to initialize the surface as themed context before view is attached.
This way it is possible to configure theming with `ContextThemeWrapper` the same way as Litho does it for prerendering. The assumption is that any kind of customization done through Android theme will be applied from prerendering entry point as well.
Changelog: [Internal] - Use context from surface for prerendering
Reviewed By: mdvacca
Differential Revision: D31906091
fbshipit-source-id: 344fc96eb2f85ba5b762bee64d1a29443b3fd1d3
Summary:
The `ReactScrollView.java` constructor is using `ReactContext` instead of `Context`, which is inconsistent to the horizontal scroll view. This is the result from D3863966 (https://github.com/facebook/react-native/commit/2cf2fdbc04bc5309f6942ed464ad61cd06a26ce8) when an OSS issue needs to be addressed. That issue and all call sites to use the `ReactContext` are deprecated now.
Revert this back to use `Context` to be less restrictive.
Changelog:
[Android][Fixed] - Revert `ReactScrollView` to use `Context` instead of `ReactContext` in the constructor to be less restrictive.
Reviewed By: javache
Differential Revision: D31819799
fbshipit-source-id: 3f00d64850aebd2e20615033b2e1f1c721fed37e
Summary:
Colocate the surface ID generate with the code that consumes it. This allows us to re-use this method in other event emitter locations.
Changelog: [Android][Changed] Add helper to get surfaceId for event dispatching
Reviewed By: philIip
Differential Revision: D31651881
fbshipit-source-id: 109e189f90261d3ba0077ffa519c3d12a9111439
Summary:
Changelog:
[Android][Changed] RootView's onChildStartedNativeGesture now takes the child view as its first argument
Reviewed By: philIip
Differential Revision: D31399515
fbshipit-source-id: b9438f6118e604a04799ef67d0b46303a06d6434
Summary:
Many have reported about the misguiding error `Fatal Exception: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes.so` even though they don't use Hermes (for example issues https://github.com/facebook/react-native/issues/26075#25923).
**The current code does not handle errors correctly when loading JSC or Hermes in `ReactInstanceManagerBuilder`**.
**ReactAndroid/src/main/java/com/facebook/react/ReactInstanceManagerBuilder.java:**
```java
try {
return new HermesExecutorFactory();
} catch (UnsatisfiedLinkError hermesE) {
// We never get here because "new HermesExecutorFactory()" does not throw an exception!
hermesE.printStackTrace();
throw jscE;
}
```
In Java, when an exception is thrown in static block, it will be RuntimeException and it can't be caught. For example the exception from `SoLoader.loadLibrary` can't be caught and it will crash the app.
**ReactAndroid/src/main/java/com/facebook/hermes/reactexecutor/HermesExecutor.java:**
```java
static {
// Exception from this code block will be RuntimeException and it can't be caught!
SoLoader.loadLibrary("hermes");
try {
SoLoader.loadLibrary("hermes-executor-debug");
mode_ = "Debug";
} catch (UnsatisfiedLinkError e) {
SoLoader.loadLibrary("hermes-executor-release");
mode_ = "Release";
}
}
```
This PR fixes the code so that the original exception from failed JSC loading is not swallowed. It does not fix the original issue why JSC loading is failing with some devices, but it can be really helpful to know what the real error is. For example Firebase Crashlytics shows wrong stack trace with current code.
I'm sure that this fix could have been written better. It feels wrong to import `JSCExecutor` and `HermesExecutor` in `ReactInstanceManagerBuilder.java`. However, the main point of this PR is to give the idea what is wrong with the current code.
## 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] - Fix error handling when loading JSC or Hermes
Pull Request resolved: https://github.com/facebook/react-native/pull/30749
Test Plan:
* from this PR, modify `ReactAndroid/src/main/java/com/facebook/react/jscexecutor/JSCExecutor.java` so that JSC loading will fail:
```java
// original
SoLoader.loadLibrary("jscexecutor");
// changed
SoLoader.loadLibrary("jscexecutor-does-not-exist");
```
* Run `rn-tester` app
* Check from Logcat that the app crashed with correct exception and stacktrace. It should **not** be `java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes.so`
Tested with Hermes
```
SoLoader.loadLibrary("hermes-executor-test");
```
Got this one in logcat
```
09-24 20:12:39.552 6412 6455 E AndroidRuntime: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes-executor-test.so
```
Reviewed By: cortinico
Differential Revision: D30346032
Pulled By: sota000
fbshipit-source-id: 09b032a9e471af233b7ac90b571c311952ab6342
Summary:
SurfaceHandlerBinding uses string from JVM memory when initializing, which is released before it is used. If JVM manages to collect this memory before instance init, it can lead to use-after-free.
Changelog:
[Internal] - fix memory corruption in cxx binding of surface handler
Reviewed By: mdvacca
Differential Revision: D31794515
fbshipit-source-id: 3944ebd065f42a516f036096d07c0126a43c912f
Summary:
This bug is caused by RNAndroid dispatching an incorrect sequence of events to JS when the user taps on a Text.
Taking into consideration the example P462662009, when the user taps of the "Inner" text, RN Android is dispatching three events:
topTouchStart, topTouchStart and topTouchEnd.
The information stored on the first two JS events is correct, but the problem is that it is duplicated. This sequence of events makes Pressability to dispatch the event to the incorrect target.
This was originally introduced in D3035589 (https://github.com/facebook/react-native/commit/39fdce259dd46de8fd715efbfd12ede4bc24c8c2) (2016)
In this diff I'm changing the way RN Android bubbles events when the user taps on a ReactTextView. From now on, events won't be bubbled anymore, and they will be handled by the ReactRootView.onInterceptTouchEvent: https://fburl.com/code/rbt8$
Additionally, I'm creating a FeatureFlag in case this change has a unknown side effect that's only detected in production.
I will create a MC for FB4A in the next diffs of the stack
changelog: [Fixed][Android] Fix onPress event for nested Text in RN Android
Reviewed By: javache
Differential Revision: D31628461
fbshipit-source-id: 177397d4369191a3c97e2f86e801757b27ee5121
Summary:
The [first implementation of `TextAttributes` in Fabric](https://github.com/facebook/react-native/commit/62576bcb7832e08c6fd9f9482285882c37a2ece5) included two separate props instead of `textDecorationStyle`: `textDecorationLineStyle` (single, double, ...) and `textDecorationLinePattern` (dot, dash, dotdash, ...). These two props were implemented in C++ and iOS but never supported in JS.
Pre-Fabric (and CSS) on the other hand use a single prop `textDecorationStyle: 'solid' | 'double' | 'dotted' | 'dashed'`.
This diff implements this same API in Fabric, and removes the unused `textDecorationLineStyle` and `textDecorationLinePattern` props.
Changelog:
[iOS][Fixed] - Implement `textDecorationStyle` on iOS and remove unused `textDecorationLineStyle` and `textDecorationLinePattern` from Fabric.
Reviewed By: dmitryrykun
Differential Revision: D31617598
fbshipit-source-id: f5173e7ecdd31aafa0e5f0e50137eefa0505e007
Summary:
Noticed we were sometimes receiving incorrect paths through the view hierarchy. This was largely harmless, as the hover events generated from this would still be correct. We just sometimes send more onExit/onEnter events than necessary.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D31434300
fbshipit-source-id: 3888270eaa16edf48f5d894a1e6daeca1ecfed1e
Summary:
These dynamic_casts aren't really giving us much (they have never fired once in dev! and don't run in prod anyway). They also prevent us from disabling RTTI. So, let's get rid of them.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D31634895
fbshipit-source-id: 4a9b259837127feb324f64fa3e9e23eb1cc481a6
Summary:
Using `WriteableNativeArray` directly in common code is breaking unit tests on CircleCI.
Changelog:
[Android][Internal] - Use mock of native array for sending touches
Reviewed By: mdvacca
Differential Revision: D31665842
fbshipit-source-id: 886418ff6a3f07046e8e17d4743060d80c26b288
Summary:
Nearly all of these are identical and these compiler_flags are now centralized in rn_defs.bzl. This should have NO CHANGE on build configuration, the flags have just moved for now.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D31631766
fbshipit-source-id: be40ebeb70ae52b7ded07ca08c4a29f10a0ed925
Summary:
This seems like a remnant of an old refactor. This is passed in, we wrap it with a JMessageQueueThread and then never use it again.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D31506280
fbshipit-source-id: aca01439dcddbe2b44ce80342fa8664f827919c9
Summary:
Updates touch events in Fabric to be dispatched through the same pipeline as the rest of events, instead of relying on custom dispatch behavior.
Previous method of handling touches was reusing Paper behavior which required:
1. Transform event into a Paper-compatible form of WritableArray and dispatch it to `RCTEventEmitter.receiveTouches`.
2. Intercept `receiveTouches` for Fabric and redirect it to `FabricEventEmitter`
3. Perform transformations copied from Paper JS renderer in Java, transform it to the final form and dispatch this event as usual after.
The new behavior uses emitter's `receiveEvent` method directly to dispatch events. Additionally, it should decrease allocations done when transforming events during step 3 above, as `WritableNativeMap`-based operations performed many re-allocations when reading/re-creating arrays.
Changelog:
[Android][Changed] - Added an experimental touch dispatch path
Reviewed By: JoshuaGross
Differential Revision: D31280052
fbshipit-source-id: 829c2646ac6b0ebff0f0106159e76d84324ac732
Summary:
Simplifies logic of touch dispatch by retrieving surface id and other require info from the event directly.
Changelog: [Android][Internal] - Simplify logic of dispatching touches
Reviewed By: cortinico
Differential Revision: D31583314
fbshipit-source-id: c6b6e131a759c2ebe0cf4441c3aeb1a8b9f5781e
Summary:
Propagate event category definition to every event that is using `dispatchModernV2` (gated in production), providing opportunity to override categories of some events if needed. No events are meaningfully affected by this change, as coalesced events (e.g. scroll) are always dispatched as continuous and touch events are handled separately.
Changelog:
[Internal] Expose event category in Event class
Reviewed By: cortinico
Differential Revision: D31276249
fbshipit-source-id: f9a756b3a5cf5897e17209f3d0aed6a1c16cbd2e
Summary:
Added more logs to understand what's the root cause for https://fburl.com/logview/kgknonri
```java.lang.IllegalStateException: Message queue threads already initialized
at X.5y2.A0I(:64)
at com.facebook.venice.ReactInstance.<init>(:112)
at X.PrB.EgB(:33)
at X.2pN.run(:4)
at X.2pA.execute(:32)
at X.2p6.A00(:30)
at X.2p6.A08(:2)
at X.PrC.EgB(:26)
at X.Pr7.run(:4)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:919)
```
Changelog:
[Android][Changed] - Add some logs
Reviewed By: RSNara
Differential Revision: D31584264
fbshipit-source-id: 11b8bb2c6c9af2266688e3dae95e09f0160de79a
Summary:
The elevation barriers that limited view reordering were applied incorrectly, disabling elevation completely for some combinations of views. This change ensures the order of barriers is correct and only disables elevation reorder between the children and not on them.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D31541961
fbshipit-source-id: 2fa4dc6906790053bd4445c841aeda0e2b3830e5
Summary:
The `scrollTo` method in ScrollViews are using the `(x, y)` position they got from upperstream to scroll, and to set the state for Fabric. This diff fixes an edge case where the scroll result is not ended up to `(x, y)`. For example, if we are going to scroll to the last item in the list, the item may not scroll to the `(x, y)` position, but stay at the end position of the view.
- Change `scrollTo` method to use the actual `scrollX` and `scrollY` position after scrolling to set current state.
Changelog:
[Android][Fixed] - scrollTo API in ScrollView will check the actual scroll position before setting the scroll state
Reviewed By: JoshuaGross
Differential Revision: D31492685
fbshipit-source-id: e5513fb735ea68c5014b5c47fadffe461cad5c94
Summary:
## Context
Right now we are using both LogBox and ExceptionsManager native module to report JS errors in ExceptionsManager.js, from below code we can tell they have some overlapping - when ```__DEV__ === true``` both could report the error.
https://www.internalfb.com/code/fbsource/[5fb44bc926de87e62e6e538082496f22017698eb]/xplat/js/react-native-github/Libraries/Core/ExceptionsManager.js?lines=109-141
## Changes
In this diff overlapping is removed: in ```ExceptionsManager.js``` LogBox will be responsible for showing the error with dialog when ```__DEV__ === true```, when it's prod we'll use ExceptionsManager native module to report the error. As a result LogBox and ExceptionsManager native module don't share responsibilities any more.
Changelog:
[General][Changed] - Remove shared responsibility between LogBox and ExceptionsManager native module
Reviewed By: philIip
Differential Revision: D30942433
fbshipit-source-id: 8fceaaa431e5a460c0ccd151fe9831dcccbcf237
Summary:
This PR fixes a few issues with the Appearance API (as noted here https://github.com/facebook/react-native/issues/28823).
1. For the Appearance API to work correctly on Android you need to call `AppearanceModule.onConfigurationChanged` when the current Activity goes through a configuration change. This was being called in the RNTester app but not in `ReactActivity` so it meant the Appearance API wouldn't work for Android in newly generated RN projects (or ones upgraded to the latest version of RN).
2. The Appearance API wasn't working correctly for brownfield scenarios on Android. It's possible to force an app light or dark natively on Android by calling `AppCompatDelegate.setDefaultNightMode()`. The Appearance API wasn't picking up changes from this function because it was using the Application context instead of the current Activity context.
3. The Appearance API wasn't working correctly for brownfield scenarios on iOS. Just like on Android its possible to force an app light or dark natively by setting `window.overrideUserInterfaceStyle`. The Appearance API didn't work with this override because we were overwriting `_currentColorScheme` back to default as soon as we set it.
## 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
-->
### Fixed
https://github.com/facebook/react-native/issues/28823
* [Android] [Fixed] - Appearance API now works on Android
* [Android] [Fixed] - Appearance API now works correctly when calling `AppCompatDelegate.setDefaultNightMode()`
* [iOS] [Fixed] - Appearance API now works correctly when setting `window.overrideUserInterfaceStyle`
Pull Request resolved: https://github.com/facebook/react-native/pull/29106
Test Plan: Ran RNTester on iOS and Android and verified the Appearance examples still worked [correctly.](url)
Reviewed By: hramos
Differential Revision: D31284331
Pulled By: sota000
fbshipit-source-id: 45bbe33983e506eb177d596d33ddf15f846708fd
Summary:
When the overflow style set to 'scroll', React ViewGroup does nothing to the container. Instead it should be clipped just like hidden.
Changelog:
[Android][Changed] - Setting `overflow: scroll` in View component style will clip the children in the View container
Reviewed By: javache
Differential Revision: D31350605
fbshipit-source-id: e0d618f5e872fec9cf9ecb2d4cfe7af9a2f3c063
Summary:
changelog: [internal]
Retaining `EventEmitter` beyond runtime triggers a crash. Let's try to use raw pointer in `EventEmitterWrapper` to see if it fixes some crashes.
Reviewed By: philIip
Differential Revision: D31307332
fbshipit-source-id: cd059b6c56f8dffe985b3ecb62cdafe823ba1462
Summary:
changelog: [internal]
This is a pre-condition to get rid of `shared_ptr` from `EventEmitterWrapper`. Also saves us a few copies of shared_ptr, this is negligible though.
Reviewed By: mdvacca
Differential Revision: D31307048
fbshipit-source-id: b84654bed2359b66faf3995795e135e88fe51cb6
Summary:
Event merging or "coalescing" is done on Java side from Android, but Fabric also includes some Cxx logic to merge those events. Although Android doesn't need this logic in particular, it is important to follow this path to ensure these events (e.g. scroll) are dispatched as "continuous", allowing for correct prioritization in Concurrent Mode.
`dispatchModernV2` selects between `dispatch` and `dispatchUnique` based on the `canBeCoalesced` parameter of the event, which is exactly what we need. The logic is only used in the "new" event dispatcher at the moment, so I wrapped it with feature flag to validate it doesn't cause any regressions.
Changelog:
[Android][Internal] - Try dispatching coalescing events as unique to Fabric
Reviewed By: sammy-SC
Differential Revision: D31272585
fbshipit-source-id: 6b67b61bd13fbff019d9eb8c5172bdd814a7b5b8
Summary:
Assuming this method was deprecated to mean experimental.
This execution path is used by overwhelming majority of events and it seems as stable as it can be.
Changelog:
[Android][Changed] Removed experimental deprecation from `dispatchModern`
Reviewed By: cortinico
Differential Revision: D31270721
fbshipit-source-id: 5a7e50455ab2850adf9bc86a248773b170bf0ab9
Summary:
We forgot to make ClipboardModule TurboModule compatible. I think this was most likely because our codemods targeted all Java classes that extended ReactContextBaseJavaModule. The ClipboardModule extends ContextBaseJavaModule instead.
There are no other NativeModules that extend ContextBaseJavaModule.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D31291293
fbshipit-source-id: cf5d21898101699f8c349b013a77e8329339a8d3
Summary:
changelog: [internal]
This code assured that view preallocation is only triggered if ShadowNode is cloned from revision 0 to revision 1 (first time ShadowNode is cloned).
Node can go from virtual to view forming in subsequent clones, not just the first one. This is more of a case in Concurrent React where the node can be cloned many times before it is first mounted.
Reviewed By: mdvacca
Differential Revision: D31237719
fbshipit-source-id: 13fe6d10fdc815dbdae785d1d9d86d1c8fd36be4
Summary:
Updates event category deduction to match iOS implementation.
The event priority is used by concurrent mode to prioritize certain events, where Cxx part already assigns the correct priority based on the `ContinuousStart` -> `ContinuousEnd` spans. These spans can be deduced from the touch events, which we do in this implementation.
All events that can be "coalesced" (dispatched through `invokeUnique`) are assigned `Continuous` by default in Fabric core, so scroll/slider change events will never be discrete.
Changelog:
[Internal] Add category deduction to Android touch events
Reviewed By: mdvacca
Differential Revision: D31233233
fbshipit-source-id: f5b039aa137f1b4d2e2b15578bfc29ab6903a081
Summary:
For iOS, event category deduction is done from the C++ code, but the touch events are handled on Java layer in Android. This change exposes the category parameter through the `EventEmitterWrapper` called from Java, allowing to define category for events in the future.
Changelog:
[Internal] - Expose event category through JNI
Reviewed By: mdvacca
Differential Revision: D31205587
fbshipit-source-id: f2373ce18464b01ac08eb87df8f421b33d100be2
Summary:
This diff extends the current implementation of ScrollView.snapToAlignments from RN Android to reach feature parity with RNiOS
changelog: [Android][Changed] Implement ScrollView.snapToAlignments in RN Android
Reviewed By: javache
Differential Revision: D31206398
fbshipit-source-id: b6534965c476a0a4745ac98b419cbe05dc5c746e
Summary:
This diff implements the SnapToAlignment functionality in ReactScrollView for RN Android.
In order to use SnapToAlignment, the pagingEnabled prop should be set
Based on the documentation the behavior implemented in this diff is more "advanced" than the one implemendted in RNiOS, because it let you snap without specifying any interval nor offset (it calculates the intervals in real time based on the size of its content)
I still need to verify how different RNiOS and RN Android behaviors are
changelog: [Android][Added] Implement SnapToAlignment in ReactScrollView
Reviewed By: JoshuaGross
Differential Revision: D31182786
fbshipit-source-id: a9b55d9c00326ae21ca9b89575e79c60bf9edcca
Summary:
This diff adds the new snapToAlignment into ReactScrollViewManager
changelog: [Android][Added] Implement snapToAlignment into ReactScrollViewManager
Reviewed By: JoshuaGross
Differential Revision: D31182787
fbshipit-source-id: 8049ceb462461a11f184dbc1b40ca8079a3e8b60
Pieter De Baets
Andrei Shikov
grgr-dkrk
Xin Chen
Stefanos Markidis
CodemodService FBSourceGoogleJavaFormatLinterBot
Tuomas Jaakola
Joshua Gross
David Vacca
Lulu Wu
Rob Hogan
Joel Arvidsson
Brent Kelly
Samuel Susla
Ramanpreet Nara
