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:
While working updating the codeden Makefile template for Android, I've removed
the `libreact_debug` and `libreact_render_debug` dependencies as they were unused in a
simple turbomodule. Turns out that `:ReactAndroid` is depending on having those dependencies.
Moving the build file to use AGP APIs, triggers this scenario and is making `ReactAndroid`
failing to build (see the build status for https://github.com/facebook/react-native/pull/32443).
I'm updating the codegen Makefile template to reintrodce the two libraries + I've update the prebuilt
makefile (used in the playbook) to include `react_debug` prebuilts as they were missing.
Changelog:
[Internal] [Changed] - Re-add libreact_debug to codegen makefile and add prebuilts for them
Reviewed By: ShikaSD
Differential Revision: D31900675
fbshipit-source-id: ff188c0498a0dca4a951a548a580ca8dd0674782
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:
This Diff is adapting the codegen configuration for ReactAndroid
to specify a path for the codegen package. I've used the `findNodeModulePath`
so this will work for both:
* The top level OSS project as `node_modules` will be at the top level
* The scenario where ReactAndroid will be included and built from source (as `node_modules` is in the `..` folder).
Changelog:
[Internal] [Changed] - Use explicit codegen path in ReactAndroid
Reviewed By: mdvacca
Differential Revision: D31730920
fbshipit-source-id: 6637da5d0098114f4379bcaeb8a40e976c46f194
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:
Turns out that the Java generator is (as expected) outputting only Java code.
Therefore the C++ and the Markdown files are still generated by `react-native-codegen`.
I'm updating the logic to make sure the Java generator is not mutually exclusive and
overrides the output of `react-native-codegen`
Changelog:
[Internal] [Changed] - useJavaGenerator output should override the react-native-codegen one
Reviewed By: sshic
Differential Revision: D31754428
fbshipit-source-id: 3e6dae8212fbfebd28247ec17e88243871265808
Summary:
This diff is making sure that we're not failing the build
if either `ANDROID_NDK_PATH` or `ANDROID_NDK_VERSION` are missing.
Currently if any of the two is missing, a Gradle sync will fail.
This is problematic for the New Arch Rollout playbook as users will
import the `:ReactAndroid` project to build from source, and those
properties are instead defined at the `react-native` top level project.
Changelog:
[Internal] [Changed] - Safely access the project NDK properties
Reviewed By: sshic
Differential Revision: D31731291
fbshipit-source-id: ce4b762998ed545b3ec7ddcc07abbe4452602190
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/32426
This diff refactors the extractHeader and extractJni tasks to a single Gradle task in the `.internal` package.
The reason for this change is that those two tasks were always running, therefore invalidating the
whole native build cache.
Changelog:
[Internal] [Changed] - Refactor Extract Headers and JNI from AARs to an internal task
Reviewed By: mdvacca, ShikaSD
Differential Revision: D31682942
fbshipit-source-id: 191cc77902e82c0425949cee743d240ded790137
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32427
This diff refactors the `prepareJSC` task to a separate Gradle task in the `.internal` package.
The reason for this change is that `prepareJSC` was just a plain `Task` and not a `Copy` task.
It was defining a top level `doLast` action and would result in being
invalidated whenever the `build.gradle` file would change. This means that the JSC headers/source files
would have been extracted again, effectively invalidating the timestamps for the native build.
Changelog:
[Internal] [Changed] - Export prepareJSC to an internal task
Reviewed By: ShikaSD
Differential Revision: D31682293
fbshipit-source-id: 3d4cd9d9ce2fcd45e61f3c8c6685b69a622a1912
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32424
This diff refactors the `prepareBoost` task to a separate Gradle task in the `.internal` package.
The reason for this change is that `prepareBoost` was defining a `doLast` action and would result in being
invalidated whenever the `build.gradle` file would change. This means that the Boost headers/source files
would have been extracted again, effectively invalidating the timestamps for the native build.
Changelog:
[Internal] [Changed] - Export prepareBoost to an internal task
Reviewed By: ShikaSD
Differential Revision: D31662120
fbshipit-source-id: 87ba82c634da832ee54c3d13561df45d3fd71381
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32425
This diff refactors the `prepareLibevent` task to a separate Gradle task in the `.internal` package.
The reason for this change is that `prepareLibevent` was defining a `doLast` action and would result in being
invalidated whenever the `build.gradle` file would change. This means that the Libevent headers/source files
would have been extracted again, effectively invalidating the timestamps for the native build.
Changelog:
[Internal] [Changed] - Export prepareLibevent to an internal task
Reviewed By: ShikaSD
Differential Revision: D31661988
fbshipit-source-id: e55c2179a187fa156f701c25bae3b48a796e2660
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32421
This diff refactors the `prepareGlog` task to a separate Gradle task in the `.internal` package.
The reason for this change is that `prepareGlog` was defining a `doLast` action and would result in being
invalidated whenever the `build.gradle` file would change. This means that the Glog headers/source files
would have been extracted again, effectively invalidating the timestamps for the native build.
Changelog:
[Internal] [Changed] - Export prepareGlog to an internal task
Reviewed By: ShikaSD
Differential Revision: D31661668
fbshipit-source-id: efcd5505a67d6c9f02fcab7a5c3255a160215661
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
grgr-dkrk
Xin Chen
Nicola Corti
Stefanos Markidis
Andrei Shikov
Pieter De Baets
CodemodService FBSourceGoogleJavaFormatLinterBot
Tuomas Jaakola
Joshua Gross
David Vacca
Lulu Wu
Rob Hogan
Joel Arvidsson
Brent Kelly
Samuel Susla
Ramanpreet Nara
