Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39185
Changelog: [Internal] - Fix incorrect pointer coordinates caching
In D48472486 I moved the updating of "previous" fields into the `handleHitStateDivergence` method which made sense considering that it's run on every event regardless but what I didn't take into account was the updating of the `mLastEventCoordinatesByPointerId` field. On `ACTION_HOVER_MOVE` events there's a filter that ensures that only move events that have a large enough distance are emitted (something that isn't done on iOS, hence why I didn't think of it), but after my changes in D48472486 it was updating `mLastEventCoordinatesByPointerId` **before** that hover move check, making the distance always 0 and never firing move events.
This diff fixes this by moving the updating of `mLastEventCoordinatesByPointerId` and `mLastButtonState` back to the end of `handleMotionEvent`.
Reviewed By: lunaleaps
Differential Revision: D48756372
fbshipit-source-id: 6f2e40366986ce8d1c6128e49bf3abd44137196d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39155
[Changelog]: [Android][Fixed] Fix crash in CompositeTurboModuleManagerDelegate
CompositeTurboModuleManagerDelegate.cpp crashes as we pass in one or multiple
```
jni::alias_ref<TurboModuleManagerDelegate::javaobject> delegate
```
but don't retain a global reference to them. Fix use:
```
jni::make_global(delegate)
```
Differential Revision: D48670217
fbshipit-source-id: e805f28919918b2a867589dbb6e2a70d67dcd8c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39140
TurboReactPackage.getModule is nullable, although the internals of ReactNative requires this method to be non null (otherwise there will a NPEs)
I'm making TurboReactPackage.getModule no nullable, this is important to simplify API and future migration to kotlin
changelog: [internal] internal/
Reviewed By: cortinico
Differential Revision: D48588375
fbshipit-source-id: e510f76ea0271ff33ab2ebe6c76382c4781e1787
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39137
getNativeModuleIterator is not required to be public, reducing visibillity to package only
changelog: [internal] intenral
Reviewed By: philIip, rshest
Differential Revision: D48588376
fbshipit-source-id: 6cbff90a4c51d2af4b0693b84c1a674ea24b94d1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39097
Changelog:
[Internal][Added] - Created mechanism to have nested horizontal scrollviews (or flatlists/sectionlists) by prioritizing scrolling on deeper nested scrollviews which have the enableNestedScroll prop equal to true.
Reviewed By: NickGerleman
Differential Revision: D48504762
fbshipit-source-id: 1a6d01f68e142d99ea494e2b5630979c7be2ecce
Summary:
When reloads fail, React Native currently just renders a blank screen.
We should provde some sort of feedback to the developer. Hence, this diff makes the RedBox show up.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D48335851
fbshipit-source-id: 0681cd40f8c83960f9133853481013765634f5cf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39000
Whenever React Native tears down (including on logout), we need to drop unconsumed Pre-rendering surfaces.
D45012714 initially implemented this change, but this diff wasn't complete: it would only drop unconsumed pre-rendered surfaces when ***the Facebook infra* initiated** React Native to tear down. But, React Native could initiate tear down **by iteself** (e.g: via an uncaught exception on the Native Modules thread).
## Changes
In this diff, make the React Manager support an onBeforeDestroy listener. Then, integrate these listeners into the teardown/reload algorithms. That way, no matter how React Native tears down, we **alwasy** drop unconsumed pre-rendered surfaces.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D48323647
fbshipit-source-id: 28f99500eea457b0e3c420fed28c434f8794ac23
Summary:
The new reload/create/destroy methods work by chaining tasks together.
This task chain has the type Task<ReactInstance>.
**The problem:** If any step in the chain fails, task.getResult() actually returns null - not the ReactInstance. Many steps in the existing reload() and destroy() task chains don't account for this case. So:
- The reload() and destroy() task chains sometimes swallow errors.
- Sometimes steps in the reload() and destroy() task chains don't execute: they use .successTask
This diff makes two changes:
1. Ensure each step **always** executes (i.e: use .continueWith vs .success)
2. Ensure each step first checks if the Task<ReactInstance> isn't faulted/cancelled. If the task is faulted/cancelled, a soft exception gets reported, and the current ReactInstance gets returned.
Changelog: [Internal
Reviewed By: mdvacca
Differential Revision: D48080779
fbshipit-source-id: 22f03ef1a54b538d01eeb5ecde6d82a84d32f1f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38997
After React Native gets destroyed (e.g: via an exception), the ReactHost resets its current activity.
## Problem
React Native can display RedBoxes after React Native destruction (e.g: in the case of an exception).
Displaying RedBoxes requires the current activity, which gets nullified. So, the RedBox might not show up after destruction.
## Changes
This diff makes ReactHost keep a track of its last non-null activity in a WeakRef.
Then, the DevMenu just uses the last non-null activity to display RedBoxes (and everything else).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D48076893
fbshipit-source-id: 6baddf8f329c03efe92f93ef1bfc6eb9569c1b38
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38998
Instead of using the mActivity reference directly, let's just use getCurrentActivity() and setCurrentActivity().
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D48076896
fbshipit-source-id: d988deaf8778bf0e3726d13f96e9e6e480d8fdc0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38999
After React Native tears down, a RedBox can appear, prompting the user to reload.
**Problem:** After React Native reloads, the React Native screen wouldn't show up.
**Cause:** ReactContext.onHostResume() wasn't executed.
Why:
- React Native teardown moves the React manager into the **onHostDestroy()** state.
- During initialization, React Native only calls ReactContext.onHostResume(), if the React manager was *already* in the **onHostResume()** state.
https://www.internalfb.com/code/fbsource/[f82938c7cc9a0ee722c85c33d1027f326049d37c]/xplat/js/react-native-github/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/bridgeless/ReactHost.java?lines=924-925
**Question:** Why does React Native only call ReactContext.onHostResume(), **if the React manager was already in the onHostResume() state?**
In short, we want ReactContext.onHostResume() to be delayed until the user navigates to the first React Native screen. Please read the comments in the code to understand why.
## The fix
If we're initializing React Native during a reload, just always call ReactContext.onHostResume().
If React Native is reloading, it seems reasonable to assume that:
1. We must have navigated to a React Native screen in the past, or
2. We must be on a React Native screen.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D48076895
fbshipit-source-id: 6794105920ee30d62cebd745256bb5dea805e891
Summary:
During React Native teardown, we should stop all React surfaces. Otherwise, the app could crash with this error:
```
08-06 14:54:08.644 14843 14843 F DEBUG : Abort message: 'xplat/js/react-native-github/packages/react-native/ReactCommon/react/renderer/scheduler/Scheduler.cpp:171: function ~Scheduler: assertion failed (surfaceIds.empty() && "Scheduler was destroyed with outstanding Surfaces.")'
```
When can teardown occur? One case: an exception occurs on the NativeModules thread.
NOTE: This diff impacts the **new** Bridgeless mode lifecycle methods.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D47926966
fbshipit-source-id: 62be90eb49091773976dfb18db5c2a7c0668c382
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39061
We're suppressing JVM tests using BUCK which is causing misalignment between which tests we run on Buck vs Gradle.
Instead we should be using the Ignore annotation (which we already do) to decide which tests to skip, so that Buck can just pick all the Java/Kotlin file in this folder.
Changelog:
[Internal] [Changed] - Cleanup BUCK setup for our JVM tests
Reviewed By: cipolleschi
Differential Revision: D48433432
fbshipit-source-id: 31070ef848932aefa5d2710a8e11f97646e4b51c
Summary:
Migrate Java tests to Kotlin for the JSDebuggerWebSocketClient class.
## Changelog:
Pick one each for the category and type tags:
[ANDROID] [CHANGED] - Update Java tests to Kotlin for the referenced file
Pull Request resolved: https://github.com/facebook/react-native/pull/38941
Test Plan: All unit tests passed.
Reviewed By: mdvacca, rshest
Differential Revision: D48354172
Pulled By: cortinico
fbshipit-source-id: e8d3c98216b4e2c3ff462433c7e37d628d06f0c6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39051
X-link: https://github.com/facebook/yoga/pull/1344
`YGJNILogFunc` has a bug where it uses a `va_list` to determine the length of a printf string, then reuses the same `va_list` later after it has already been iterated through. Even if no arguments are present, this may cause a crash looking something like:
```
C [libsystem_platform.dylib+0xf12] _platform_strlen+0x12
C [libsystem_c.dylib+0x31bf] __vfprintf+0x1339
C [libsystem_c.dylib+0x307ce] _vsnprintf+0x100
C [libsystem_c.dylib+0x6965] vsnprintf+0x44
C [libyoga.dylib+0x5161] YGJNILogFunc(YGConfig*, YGNode*, YGLogLevel, void*, char const*, __va_list_tag*)+0x59
```
Fixing this fixes crashing unit tests which are not explicitly disabled.
Reviewed By: yungsters
Differential Revision: D48388548
fbshipit-source-id: 492e7a89aeb5f9d15485ce31641875a295356bef
Summary:
Converts ReactPropConstantsTest to Kotlin, as requested in https://github.com/facebook/react-native/issues/38825
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [CHANGED] - Convert ReactPropConstantsTest to Kotlin
[INTERNAL] [CHANGED] - Add null-check to ViewManagersPropertyCache.java
Pull Request resolved: https://github.com/facebook/react-native/pull/39005
Test Plan:
1. Run `./gradlew :packages:react-native:ReactAndroid:test`.
2. All tests should pass.
Reviewed By: mdvacca, rshest
Differential Revision: D48430460
Pulled By: cortinico
fbshipit-source-id: cc425f14bf15ec6e5a334c631d52ca962d06a2a9
Summary:
changelog: [internal]
In D47993140 I removed FabricViewStateManager but made a mistake during refactoring in one of the conditions that detects if we are in paper or fabric.. This fixes it.
Reviewed By: cipolleschi
Differential Revision: D48390478
fbshipit-source-id: ff6e728f3eaae755b2200e9cd8edd3acdc4708aa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39022
Fixes a possible NullPointerException thrown when trying to access the binding after the instance has been destroyed to report mounts.
I added a check for the mount item just in case 😅
Changelog: [internal]
Reviewed By: lenaic
Differential Revision: D48355738
fbshipit-source-id: 401d2e0a52b0764ed89498ecc0176d160226e509
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38858
Pull Request resolved: https://github.com/facebook/react-native/pull/38328
This diff adds the two extra markers `initializeRuntimeStart` and `initializeRuntimeEnd` to the startup performance API. The runtime start time matches the existing android marker `GET_REACT_INSTANCE_MANAGER_START`, which is the first marker we have on the RN android app.
Changelog:
[Android][Added] - Add `performance.reactNativeStartupTiming.initializeRuntimeStart` and `performance.reactNativeStartupTiming.initializeRuntimeEnd` API
Reviewed By: rshest
Differential Revision: D47941110
fbshipit-source-id: d7e65f822f1c60a46dccacc8fd5bba84174f9f31
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38992
This Diff publishes the Hermes dSYMs to Maven while doing a release.
These were missing and so the Stack traces can't be fully symbolicated when a crash occurs.
## Changelog:
[Internal] - Publish dSYM to Maven
Reviewed By: cortinico
Differential Revision: D48309198
fbshipit-source-id: a5514e544587daadd0a0d7614f25a30fccd16a5b
Vincent Riemer
Arushi Kesarwani
Intl Scheduler
Ergul Azizler
Christoph Purrer
David Vacca
Andrew Wang
Alex Hunt
Jesse Watts-Russell
Lulu Wu
Ramanpreet Nara
Nicola Corti
Stewart Sum
Nick Gerleman
Zeya Peng
Thiago Brezinski
Fábio Henriques
Kolin Krewinkel
giolaq
Samuel Susla
Rubén Norte
Xin Chen
Vincent Viego
Yasin Çidem
Riccardo Cipolleschi