Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41192
We currently don't have visibility on what the native module thread is doing when it's busy (on Android). This adds Systrace blocks to at least know the native module and the method we're running there.
Changelog: [internal]
Reviewed By: ryancat
Differential Revision: D50645557
fbshipit-source-id: 5cb6a7f1166bfd50c28f0aba634552c35a34c941
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41157
This is internal until we're ready to test this outside of Meta.
Changelog: [internal]
## Context
In the new architecture, every time we commit a new tree in React we send a transaction to the host platform to make all the necessary mutations in the underlying native views.
This can be bad for user experience, because the user might see quick changes to the UI in succession for related changes. It also breaks the semantics of things like layout effects and ref callbacks, which are core to the React programming model and should work across all platforms.
The main semantic that this behavior breaks in React Native is that layout effects are supposed to be blocking for paint. That means that any state updates (or UI mutations) done in layout effects should be applied to the UI atomically with the original changes that triggered them, so users see a single update where the final state is applied. This doesn't work in React Native as none of the commits coming from React are blocked waiting for effects, and instead they're all mounted/applied as they come.
This isn't only a problem for React, but also for future Web-like APIs that rely on microtasks. Those are also assumed to block paint in browsers, and we don't support that behavior either.
## Changes
Now that we're adding support for a well-defined event loop in React Native, we can add a new step to notify UI changes to the host platform in specific points in time, after macrotasks and microtasks are done (the "Update the rendering" step defined on the [Web specification](https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model)).
This implements that step in the new `RuntimeScheduler`. This works by batching all the notifications from the `UIManager` to `MountingCoordinator` and calling all those methods from `RuntimeScheduler` at the right time.
There will be cases where the notifications will be to mount the same tree multiple times, but the mounting coordinator already handles this correctly (would mount the last version of the tree for each surface ID the first time, and be a no-op the other times).
This change will reduce the amount of mount operations we do on the main thread, which means that we could potentially remove the push model from Android if performance is acceptable with this.
NOTE: This only works with the modern runtime scheduler, and only makes sense when used with microtasks enabled too and background executor disabled.
Reviewed By: javache
Differential Revision: D49536327
fbshipit-source-id: fabcbd6a6fb89a851f4c2b4ebefbb330a6ad3a18
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41148
changelog: [internal]
RN moved away from using folly::hash. These are a few places missed during the migration.
Reviewed By: cipolleschi
Differential Revision: D50540176
fbshipit-source-id: 497c13032c23c5b2dfab9e3d6f226f596b90761e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41162
"The C++ standard forbids containers of const elements because allocator<const T> is ill-formed."
We have a few other callsites for std::vector<const ...>, but the const values are always const pointers, which I guess are okay?
Suffice to say, this doesn't compile with Microsoft STL headers unless you remove const.
## Changelog
[Internal]
Reviewed By: javache
Differential Revision: D50563174
fbshipit-source-id: 96053baedc41237d8d27a1e01ac94ce5abd6c768
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41090
This propagates to enable the use of microtasks in the React reconciler, Runtime Scheduler and Hermes.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D50177355
fbshipit-source-id: 6cf23cf72b63d19f50453d3e4cc4ac1b056dbd92
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41084
Adds support for executing microtasks in `RuntimeScheduler`, the same way we did in `JSIExecutor` before (removed in D49536251 / https://github.com/facebook/react-native/pull/40870) but now after each actual task in the scheduler.
When we use microtasks in the scheduler, we ignore calls to execute expired tasks (which was used to call "React Native microtasks" that we had before). Those should now be regular microtasks in the runtime.
This is gated behind a feature flag until we've tested this broadly.
This is going to be tested in Hermes but we need to add support for microtasks in JSC (which has a no-op in its JSI interface).
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D49536262
fbshipit-source-id: 8f7ce54c266d1f25312a641abc4ef073d019281f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41043
Changelog: [Internal]
in this change, we create an config pipeline to set `_enableSharedModuleQueue` in TMM
Reviewed By: cipolleschi
Differential Revision: D50398636
fbshipit-source-id: cd8c210ad2ae4774ceb10130a8b80e500d17986a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41042
Changelog: [Internal]
currently, each native module creates a new module queue if `methodQueue` is not overridden in the native module.
we want to see if we can use a single execution queue for a few reasons:
- parity with android's queue model
- performance: creating so many queues... for what? the overhead of this feels like it exceeds any potential benefit
- set us up to remove the assocs from the module to the method queue, which will allow us to deprecate `synthesize methodQueue` and `-(dispatch_queue_t)moduleQueue` API.
in this QE, we just start with replacing the KVO assoc'd queue with the shared module queue.
Reviewed By: cipolleschi
Differential Revision: D50398635
fbshipit-source-id: 0b194a5ae5269e843c7c537a973ee1d345ce1df4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41048
Reapplies D49792717
AsyncCallback and SyncCallbacks are better primitives for jsi::Function handling. The code is simpler and requires less manual argument passing. See in D49684248 how the API was extended to support more use-cases.
The underlying issue causing memory corruption has been addressed in D50286876.
Changelog: [Deprecated] AsyncCallback replaces RAIICallbackWrapperDestroyer as a safer way to manage jsi::Function memory ownership.
Reviewed By: rshest
Differential Revision: D50319914
fbshipit-source-id: e038813cad85c47be1f004bc2ea1fdaf0eee9094
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41063
Some tests for RuntimeScheduler broke because we used uninitialized values incorrectly (they're initialized with 0 on Android but with something like `0101010101...` on iOS).
This fixes the tests by assigning the right initial value.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D50413220
fbshipit-source-id: e1fc223e795e2ae01d6e3ba3bc32bd052c8fc2f3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41028
This removes misleading `const` modifiers from some methods in `RuntimeScheduler` that shouldn't really use it, and removes the `mutable` modifiers that were only necessary because of that.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D50364626
fbshipit-source-id: 28ed9fa923f8e787166f702ccaecd41a635d3b3a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40945
This adds some temporary logic to configure the use of the modern version of RuntimeScheduler based on values coming from the app configuration.
This logic is centralized in `ReactInstance` so from that point the code is completely cross-platform.
This doesn't use `ReactNativeConfig`/`CoreFeatures` because they're initialized after the point where we need to access them for this use case. This way is a bit uglier but this isn't intended to live for long (only until we verify this doesn't have regressions in a complex app).
Changelog: [internal]
---
Reviewed By: sammy-SC
Differential Revision: D50171297
fbshipit-source-id: 8d96e228550cc6112ffe2abec4d531514b052f82
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40944
## Summary
This creates a new version of `RuntimeScheduler` that's intended to be backwards compatible but with a few notable changes:
1. `scheduleTask` is now thread-safe.
2. `scheduleWork` is now just an alias of `scheduleTask` with immediate priority (to preserve the yielding semantics it had over other tasks).
3. Yielding mechanism has changed, to make lower priority tasks to yield to higher priority tasks, instead of just yielding to `scheduleWork` and `executeNowOnTheSameThread`.
We don't expect this to have any impact in performance or user perceivable behavior, so we consider it a short-lived refactor. When we validate this assumptions in a complex application we'll delete the old version and only keep the fork.
## Motivation
The main motivation for this refactor is to reduce the amount of unnecessary interruptions of running tasks (via `shouldYield`) that are only used to schedule asynchronous tasks from native.
The `scheduleWork` method is the only available mechanism exposed to native APIs to schedule work in the JS thread (as the existing version of `scheduleTask` is only meant to be called from JS). This mechanism **always** asks for any running tasks in the scheduler to yield, so these tasks are always considered to have the highest priority. This makes sense for discrete user events, but not for many other use cases coming from native (e.g.: notifying network responses could be UserBlocking, Normal or Low depending on the use case).
We need a way to schedule tasks from native with other kinds of priorities, so we don't always have to interrupt what's currently executing if it has a higher priority than what we're scheduling.
## Changes
**General APIs:**
This centralizes scheduling in only 2 APIs in `RuntimeScheduler` (which already exist in the legacy version):
* `scheduleTask`, which is non-blocking for the caller and can be used from any thread. This always uses the task queue in the scheduler and a new yielding mechanism.
* `executeNowOnTheSameThread`, which is blocking for the caller and asks any task executing in the scheduler to yield. These tasks don't go through the task queue and instead queue through the existing synchronization mechanism in `RuntimeExecutor`. The yielding mechanism for these tasks is preserved.
`scheduleWork` will be deprecated and it's just an alias for `scheduleTask` with an immediate priority (to preserve a similar behavior).
**Yielding behavior:**
Before, tasks would only yield to tasks scheduled via `scheduleWork` and `executeNowOnTheSameThread` (those tasks didn't go through the task queue).
With this implementation, tasks would now yield to any task that has a higher position in the task queue. That means we reuse the existing mechanism to avoid lower priority tasks to never execute because higher priority tasks never stop coming.
All tasks would yield to requests for synchronous access (via `executeNowOnTheSameThread`) as did the current implementation.
Changelog: [internal]
Reviewed By: javache, sammy-SC
Differential Revision: D49316881
fbshipit-source-id: 046afc8b6f510a8608ef3da6e27b2663d861f1b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40875
This introduces a proxy for RuntimeScheduler so we can select between 2 different implementations at runtime (current implementation vs. new implementation, done in D49316881).
Changelog: [internal]
Reviewed By: javache, sammy-SC
Differential Revision: D49316880
fbshipit-source-id: 4035ed6ba641a2316f2efb7cf4a0a86270d6ae23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40870
This removes an old experiment to implement microtasks in React Native (which is incorrect now that the runtime scheduler executes multiple tasks per runtime executor "task"). `drainMicrotasks` is a no-op at the moment in Hermes because the flag isn't set, so this code is essentially dead.
We'll add the new iteration of microtasks in a following PR.
Changelog: [internal]
Reviewed By: christophpurrer
Differential Revision: D49536251
fbshipit-source-id: b8efba2d0310b9e33e65b79c60ad2db1c8109def
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41020
This adds Fabric and Paper bindings to support `alignContent: "space-evenly"` as implemented in https://github.com/facebook/yoga/pull/1422
Changelog:
[General][Added] - Bindings for `alignContent: "space-evenly"`
Reviewed By: yungsters
Differential Revision: D50347978
fbshipit-source-id: 44df3b8ddc7171cddf56957c11ac7d975f706f9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41019
### Changes made
- Regenerated tests (as some aspect ratio tests seem to be out of date compared to the fixtures)
- Added SpaceEvenly variant to the "Align" enums (via enums.py)
- Implemented `align-content: space-evenly` alignment in CalculateLayout.cpp
- Added generated tests `align-content: space-evenly`
- Updated NumericBitfield test to account for the fact that the Align enum now requires more bits (this bit could do with being reviewed as I am not 100% certain that it's valid to just update the test like this).
### Changes not made
- Any attempt to improve the spec-compliance of content alignment in general (e.g. I think https://github.com/facebook/yoga/pull/1013 probably still needs to happen)
X-link: https://github.com/facebook/yoga/pull/1422
Reviewed By: yungsters
Differential Revision: D50305438
Pulled By: NickGerleman
fbshipit-source-id: ef9f6f14220a0db066bc30db8dd690a4a82a0b00
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41033
This has been rolled out with the false value (previous client-default of false). The open-source value was already false.
Changelog: [Internal]
Reviewed By: NickGerleman, sammy-SC
Differential Revision: D50362517
fbshipit-source-id: 577a2ead047b30d196409a26fd5385f333f20b18
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40895
This is a long running debug assert due to a race condition with BE. I have at times wanted to try to add a lock to protect this, and measure impact, but really it will go away when we get rid of BE anyway, and any strategy I have come up with to lock gets hairy quickly.
This change does not impact RN in OSS, where BE is already disabled.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D50247680
fbshipit-source-id: d004fc7db24f1f0b7c3ea8756d4678ce41579712
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40866
This type doesn't do anything, and we can replace it with a `jsi::Function` inside `UIManagerBinding`.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D50176084
fbshipit-source-id: 1c782f3e4d212f1d956451fd650d3ed5ed8f0d71
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40873
Some host platforms may require the LayoutContext for computing the size of text, e.g. to read the pointScaleFactor value. This change passes the LayoutContext to TextLayoutManager so it can be used during text measurement.
Please note, for now, this does not wire any fields from LayoutContext through to the TextMeasureCache, TextLayoutManager::getHostTextStorage, or TextLayoutManager::measureCachedSpannableById (on Android).
## Changelog:
[General] [Internal]
Reviewed By: rshest
Differential Revision: D50227592
fbshipit-source-id: 37ec16a4828c6cef4a1c1f01d144a86dd29dec29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41001
I believe this is due to a race condition between VM teardown and callback invocation. Because we were previously retaining the CallbackWrapper across the invokeAsync call, we may potentially have been holding onto the JSI::Function after it was already destroyed.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D50286876
fbshipit-source-id: 1277a9f37166da59ebb2169fe8d5a6fabce82f1b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40936
Found a couple of places where we were accidentally copying Props structs. These can be big, so we should avoid doing so.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D50263678
fbshipit-source-id: f60a0370df9b7f3f146988148d5192d3cc32fb4e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40933
This enables us to have lint coverage (and others) for these files. Visibility is none, so it won't be pulled in to anything.
Also removed no-op JSITracing implementation.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D50262377
fbshipit-source-id: 6218c7a79b5c0328bed8472590cff9e92006b86e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40881
Some host platforms (e.g., Windows) may have different semantics for accessibility props. For example, not setting `accessibilityState` at all is different from setting all accessibilityState values to false.
Similarly, setting AccessibilityState::expanded to false is different than not setting AccessibilityState::expanded at all because Windows inverts the AccessibilityState::expanded value for it's semantics: an explicitly false value for AccessibilityState::expanded sets the component to a collapsed accessibility state.
## Changelog
[General][Internal]
Reviewed By: NickGerleman
Differential Revision: D50236747
fbshipit-source-id: 2131824d14e38e1ed08a80e8b0e311fc6b02d1f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40880
The isPressable prop was previously added to TextAttributes. It also needs to be parsed from RawProps in BaseTextProps for platforms to use it.
## Changelog
[General][Internal]
Reviewed By: javache
Differential Revision: D50235306
fbshipit-source-id: 101aded2af5889c739ed06af7511bd34a2683dfc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40871
If we pass isPressable to the native props object (via TextAttributes), we can use this information to bypass hit testing on some spans. This is rather important on some platforms where pointerenter/pointerleave/ mousemove events force frequent hit testing.
## Changelog:
[General] [Internal]
Reviewed By: javache
Differential Revision: D50228473
fbshipit-source-id: 4fce85f4b18617fbe10d3c804e943484bf990664
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40792
Similarly to D49792717, simplify the careful logic we have with CallbackWrapper and RCTBlockGuard and instead rely on bridging's `AsyncCallback` so safely handle jsi::Function for us.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D49862756
fbshipit-source-id: 289f2d5ef622f47eb3fccf0cc7a52cc13a83b028
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39952
AsyncCallback and SyncCallbacks are better primitives for jsi::Function handling. The code is simpler and requires less manual argument passing. See in D49684248 how the API was extended to support more use-cases.
Changelog: [General] Deprecated RAIICallbackWrapperDestroyer. Use AsyncCallback instead for safe jsi::Function memory ownership.
Reviewed By: RSNara
Differential Revision: D49792717
fbshipit-source-id: 9f2f3b00c71ad1b86427dee3749c6d98ef0f5678
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39970
Changelog: [Internal]
in this diff, i add the logic that makes void return values run synchronously
Reviewed By: javache
Differential Revision: D49613770
fbshipit-source-id: ef840fb3ee130430505d000a7cf74e094f9d1405
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40233
changelog: [internal]
This is a reland of D49355595 and D49358327.
the problem was using two different hashing functions in place where they must be the same.
Reviewed By: javache
Differential Revision: D50020135
fbshipit-source-id: 1cec6bc385077d371b024a0fb5d9c64ba1f6269c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39795
X-link: https://github.com/facebook/yoga/pull/1412
Android NDK 25 uses a version of libc++ that is more than three years old, missing a lot of basic features of C++ 20. This is rectified in NDK 26 (latest LTS NDK), which brings us up to date with latest Clang (17, released this year), and adds a new policy where future NDK versions will bump libc++ as part of bumping LLVM/Clang.
This requires an a beta AGP version (and corresponding Android Studio Preview). Based on how far we are historically, it wouldn't be a surprise if we see the stable release this month (well before the RN 0.74/Yoga 3.0 cut, even in the worse case).
Changelog:
[Android][Changed] - Use NDK 26
Reviewed By: yungsters
Differential Revision: D49895949
fbshipit-source-id: 37bb4d1fdf81137be7f14f6675b4e079c6f861e4
Summary:
This bumps folly, to absorb https://github.com/facebook/folly/commit/45fffa629d6bf7321391222d40613d75e8e067d7 which fixes warnings in XCode 15, and NDK 26 (treated as error bc we have better hygiene there). We then bump a little bit further to get past a new warning added, then fixed later.
Need to manually set `FOLLY_HAVE_GETTIME` on Apple because of the silliness described in https://github.com/facebook/folly/issues/1470#issuecomment-1746035194
There is not a combination of Folly, and Android libc++, that has fixes for warnings, but doesn't require the new libc++ in NDK 26. It is expected then that this commit will fail the build, but the next should succeed, and the two must be landed at the same time.
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/39798
Reviewed By: fkgozali
Differential Revision: D49897681
Pulled By: NickGerleman
fbshipit-source-id: 52b97ed5b302abf9e27f38dc655207827852dcc3
Summary:
This is what Folly is built against internally. Bump the version we use, and the standard we compile with, to take some different paths, and see if we fix some warnings caused by FMT with the ndk bump.
Changelog:
[General][Breaking] - Bump fmt to 9.1.0
Pull Request resolved: https://github.com/facebook/react-native/pull/39799
Test Plan: Passes in CircleCI
Reviewed By: cortinico, yungsters
Differential Revision: D49900112
Pulled By: NickGerleman
fbshipit-source-id: 3f11080555ef20aeb9291d1096ffa6077b3b3bbd
Summary:
Changelog: [Internal]
sync void execution is now hooked up to mc
Reviewed By: mdvacca
Differential Revision: D49854130
fbshipit-source-id: fb4241b11a80d44318b382e2757fe7fcbfba4fb1
Rubén Norte
Samuel Susla
Eric Rozell
Phillip Pan
Pieter De Baets
Nick Gerleman
Nico Burns
Arushi Kesarwani
Krystof Woldrich
Christoph Purrer
Riccardo Cipolleschi
David Vacca
Chiara Mooney
Florian Sauer
Nick Gerleman