Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52078
This Cmake file is not imported anymore and can be removed now.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D76808417
fbshipit-source-id: 81824c7c46080bc16c891b5c11c3a8946f16c1b9
Summary:
The target needs the HERMES_ENABLE_DEBUGGER flag in debug just like .reactHermes does.
This commit fixes this by adding the define to the reactRuntime target.
## Changelog:
[IOS] [FIXED] - Added HERMES_ENABLE_DEBUGGER to debug configuration for the reactRuntime target.
Pull Request resolved: https://github.com/facebook/react-native/pull/52082
Test Plan: Prebuild React Core
Reviewed By: robhogan
Differential Revision: D76813200
Pulled By: cipolleschi
fbshipit-source-id: cb81a40fb9c5a91ca40c3a27ae4ccdf043186bac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52083
These headers were removed in D55037569 but we may have some targets still depending on them. Add redirection headers with warnings to help users migrate without this being a breaking change.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D76810433
fbshipit-source-id: 43cddcc69eefbcff0c0140e165fb893bee493c79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52077
RNTester is currently crashing on release due to a stripped `mHybridData` field.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D76808165
fbshipit-source-id: 049cca49f683c5dc92aa1f9a37dd7b4371dcbfd6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52015
Changelog: [Internal]
Add gflags to fantom_tester so we can pass in data like featureFlags
Reviewed By: cortinico
Differential Revision: D76618409
fbshipit-source-id: a18e642a02c405eef972a7418a606a5980253b6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52079
After the conversion to Kotlin (D74571782), there seems to be a synchronization issue when iterating on `viewManagers` (see T226095884).
There could a shadowing problem kicking in in a few places due to the fact that we are declaring a `viewManagers` local variable when there is already a `viewManagers` instance variable within `ViewManagerRegistry`.
To remove any ambiguity, here we are renaming the instance variable `viewManagers` as `viewManagersMap` (which also makes more sense).
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D76807070
fbshipit-source-id: 4f598700e04251409ee19b60515639e90699cc9e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52076
Changelog: [internal]
This refactors the implementation of surface creation in Fantom to make the surface ID handled in native, and treated as an opaque type the same way we do at runtime in RN.
Reviewed By: andrewdacenko
Differential Revision: D76744096
fbshipit-source-id: 1b49a1cbdf0a8d6804de3b87ede727207bc662d9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52051
In {D76368959}, I moved `react-native-fantom` from `packages/` to `private/` and missed this reference.
Changelog:
[Internal]
Reviewed By: rubennorte
Differential Revision: D76743071
fbshipit-source-id: f99d3f2ac5e14fd23f7cf208ca030541844dddc6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52054
Changelog: [internal]
This makes `OpaqueNativeObserverHandle` really opaque and fixes the problems in the observer implementation caused by it.
Reviewed By: yungsters
Differential Revision: D76744094
fbshipit-source-id: a8b6fa43ee8a5ee9d15f0171a83fe0badd46d9c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52055
Changelog: [internal]
This migrates NativeIdleCallbacks to use opaque types now that they're supported in the codegen
Reviewed By: yungsters
Differential Revision: D76744095
fbshipit-source-id: d9d1beea8df7f5635fc531a2cef001ea0aed38b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52053
Changelog: [internal]
The codegen allows us to do this already! :D
Reviewed By: yungsters
Differential Revision: D76741113
fbshipit-source-id: d460685bc6ad6ba11f7132136e8603bd57488014
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52052
Changelog: [General][Added] - Add support for Flow opaque types in codegen for native modules
This allows us to codegen native modules that expose opaque types, but the implementation sees the type the same way they're visible in the JS spec.
Reviewed By: yungsters
Differential Revision: D76741112
fbshipit-source-id: 100ca9aa7f93d35120c52153f756436c9c380b07
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52062
changelog: [internal]
- update comments to be more descriptive.
- use `#pragma mark -` to better group methods in `NativeAnimatedNodesManager`. It is nicely formatted in VSCode.
{F1979345410}
Reviewed By: mdvacca
Differential Revision: D76737257
fbshipit-source-id: c4b22ca45cd5dec2c72e7931bfec4466cda3070c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52065
1. We can crash when tapping at the boundary between two spans. Previous ReactTextView had some custom heuristic for overlapping ReactTags, assuming they could be nested, which never happens (We only have a single tag per AttributedString fragment), but spans may overlap at a single character, where one is meant to be exclusive, and the other inclusive. We add logic for that.
2. We don't incorporate the offset of the text layout within the view for hit testing, needed for padding or `textAlignVertical`.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D76764051
fbshipit-source-id: 308756c45d8ff574420dfc1c88678bae7e03e767
Summary:
While testing I notice that `types/react` was not updated in some peer depencies
## Changelog:
[GENERAL] [CHANGED] - Bump types/react to 19.1
Pull Request resolved: https://github.com/facebook/react-native/pull/52059
Test Plan: CI should be green
Reviewed By: christophpurrer
Differential Revision: D76763084
Pulled By: sbuggay
fbshipit-source-id: c078c03aa57ca04040c64986dd7957da8a6f2c2d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52043
The `hasTVPreferredFocus` prop is functionally similar to the `focusable` prop. On iOS, the props are identical. The primary difference appears on Android, where the prop attempts to request focus when set to true. Attempting to invoke imperative API calls through declarative means has been [a source of confusion](https://github.com/react-native-tvos/react-native-tvos/issues/237) and we should instead recommend requesting focus through imperative means, like calling `focus()` on a specific view's ref instead. Workarounds presented rely on lifecycle methods to request focus natively.
This change only marks these methods as deprecated on JS. In the following version, they will be removed from the public API.
Changelog: [General][Deprecated] - Deprecate `hasTVPreferredFocus`
Reviewed By: andrewdacenko
Differential Revision: D76732539
fbshipit-source-id: 64912b4dacb76cd40e79148c1082d8ed8f573879
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51949
This code is no longer necessary now that JSC support is offered via
https://github.com/react-native-community/javascriptcore
Instructions for users on how to continue using JSC are available in the README of such library.
Changelog:
[Android] [Removed] - Remove 1st party JSC support
Reviewed By: javache
Differential Revision: D76420382
fbshipit-source-id: f8e61556bb02fe4d5b34f89b40f8e5e38ac1c8d6
Summary:
When trying to implement e2e tests using maestro in a large app I ran into major performance issues. I tracked it down to the generation of recursive accessibility labels.
The maestro iOS driver uses [XCUIElement snapshot dictionaryRepresentation](https://developer.apple.com/documentation/xctest/xcuielementsnapshot/dictionaryrepresentation) [here](https://github.com/mobile-dev-inc/Maestro/blob/96e8c9a2be3430be991c13d033486d52d2001334/maestro-ios-xctest-runner/maestro-driver-iosUITests/Routes/Handlers/ViewHierarchyHandler.swift#L234) to get a representation of the view hierarchy. The problem is that will query the accessibilityLabel for every single view, starting from the root of the app. It goes without saying that this is extremely slow since it traverses the view hierarchy, executing a recursive function on each one.
I think the only way to fix this is to avoid generating these recursive labels when not needed. From my understanding these should only be needed for accessible views.
## Changelog:
[IOS] [CHANGED] - Only generate recursive accessibility label for accessible elements
Pull Request resolved: https://github.com/facebook/react-native/pull/51988
Test Plan:
- Tested using VoiceOver in RN tester to make sure it works exactly the same.
- Tested in an app using Maestro to make sure this fixes the performance issue.
- Tested in RNTester running Maestro e2e test by creating a larger view hierarchy to make the problem more apparent, and simulate a real app. Using [this code](https://gist.github.com/janicduplessis/9f6b302d92b4e22ff5e8462a8a84e237) in RNTesterAppShared.js
Before:
```
❯ yarn e2e-test-ios
yarn run v1.22.22
$ ./scripts/maestro-test-ios.sh
Waiting for flows to complete...
[Passed] flatlist (14s)
[Passed] text (28s)
[Passed] modal (16s)
[Passed] image (8s)
[Passed] button (10s)
[Passed] legacy-native-module (32s)
[Passed] pressable (32s)
[Passed] new-arch-examples (35s)
8/8 Flows Passed in 2m 55s
✨ Done in 180.26s.
```
After:
```
❯ yarn e2e-test-ios
yarn run v1.22.22
$ ./scripts/maestro-test-ios.sh
Waiting for flows to complete...
[Passed] flatlist (7s)
[Passed] text (15s)
[Passed] modal (10s)
[Passed] image (4s)
[Passed] button (6s)
[Passed] legacy-native-module (16s)
[Passed] pressable (16s)
[Passed] new-arch-examples (17s)
8/8 Flows Passed in 1m 31s
✨ Done in 97.53s.
```
Reviewed By: christophpurrer, joevilches
Differential Revision: D76581949
Pulled By: cipolleschi
fbshipit-source-id: 0689c7d43a0c865572c4ee5ea32ee9b2dcb33ad5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51986
"{}" defaults to false on C++ but the prop is not initialized which means that if accessibilityEnablesUserInteraction is set to false it will not be applied on first render. setting the default to true fixes that issue
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D76532158
fbshipit-source-id: 51cba8b89eb239e01db985d412dd2b19e482f068
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51979
Fix type checking that was left out from the last diff; D73224138
We should unify the type checking so remove uses of `java.lang.Boolean` and just use Kotlin version of `Boolean`.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D76523674
fbshipit-source-id: 293ae5998c78c98a20c7d6cf962ab7b19087fd9c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52048
This diff exports types defined in RNCodegen to be used by other codegens
changelog: [internal] internal
Reviewed By: christophpurrer
Differential Revision: D76472492
fbshipit-source-id: fa236a254a9a4211d2e00ace436f55978a262a76
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52041
After changing the publishing logic on Maven, the download logic for the artefacts published in a Snapshot was broken, because Maven does not support the redirect anymore.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76725418
fbshipit-source-id: 8bad88915d9bad96355a048486972a55f232d109
Summary:
Static code analysis reports numerous unused symbols across the codebase, which accounts for several static code analysis warnings. I've cleaned up some of them (not all of them because many of them are false positives from testing files)
The cleaned-up symbols are mostly private and from internal classes, so this should not impact users (unless they are used internally at Meta – in that case, let me know so I can revert accordingly)
## Changelog:
[INTERNAL] - Kotlin: clean up some unused symbols
Pull Request resolved: https://github.com/facebook/react-native/pull/52029
Test Plan:
```sh
yarn test-android
yarn android
```
Reviewed By: javache
Differential Revision: D76722313
Pulled By: cortinico
fbshipit-source-id: 8c7dfe204fa7c457b7484a7edd120ae45e1d604d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52035
Fixes https://github.com/facebook/react-native/issues/52014
Some OSS library is still returning null for `getViewManagerNames` especially if they're
implementing the `ViewManagerOnDemandReactPackage` in Java.
I'm adding a try-catch here so that we prevent the NPE for those scenarios.
Changelog:
[Android] [Fixed] - Fix crash on ReactInstance due to null returned for getViewManagerNames
Reviewed By: javache
Differential Revision: D76723826
fbshipit-source-id: cc159dee389257c6877b03a67840a45ee5bec165
Summary:
The OSS CI for iOS is broken because of a couple of commit that landed:
- Commit 05a61e8161 : dynamic frameworks are broken
- Commit abc8fe1c92 : pod donwload is broken
This change fixes both of them
## Changelog:
[Internal] - Fix OSS CI
Pull Request resolved: https://github.com/facebook/react-native/pull/52042
Test Plan:
Tested locally by building RNTester with Dynamic frameworks
```
USE_FRAMEWORKS=dynamic bundle exec pod install
```
Reviewed By: rshest, lenaic, GijsWeterings
Differential Revision: D76730331
Pulled By: cipolleschi
fbshipit-source-id: 71cca1f50763d24773dedcd8267130df261b01dc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52012
changelog: [internal]
On iOS, once a prop on a view is controlled by animated, the control is never released to Fabric or React. That's why it is important to use direct manipulation to commit even final value.
Reviewed By: lenaic
Differential Revision: D76601913
fbshipit-source-id: ea02219e158f28977018b34ac7152b899723b35a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52033
This change fixes the download of the artefacts for the nightlies of Hermes and React Native Dependencies after we changed the publishing logic for Maven
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76723289
fbshipit-source-id: 6b0ea6a6c35125e6fb03cecc6be893bd02abdad8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51946
This change simplified the setp disallowing to use JSC from core.
As a side effect, it simplified the setup by always falling back to hermes if the users decides not to use the third party JSC
## Changelog:
[iOS][Removed] - remove the option to use JSC from core
Reviewed By: cortinico
Differential Revision: D76342625
fbshipit-source-id: c925ab4fab1e171e289a1c5f75890c92da1b3f08
Summary:
I am not sure exactly why, but I've been getting this error when running RNTester on iOS, when it tries to build hermesc from source. We're clearing the env using `env -i` which seems to cause the issue. If I add PATH to the env we set then it builds fine.
```
++ hermesc_dir_path=/Users/janicduplessis/Developer/react-native/packages/rn-tester/Pods/hermes-engine/build_host_hermesc
++ shift
++ jsi_path=/Users/janicduplessis/Developer/react-native/packages/rn-tester/Pods/../../react-native/ReactCommon/jsi
+++ xcode-select -p
++ SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
++ env -i SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk /opt/homebrew/bin/cmake -S /Users/janicduplessis/Developer/react-native/packages/rn-tester/Pods/hermes-engine -B /Users/janicduplessis/Developer/react-native/packages/rn-tester/Pods/hermes-engine/build_host_hermesc -DJSI_DIR=/Users/janicduplessis/Developer/react-native/packages/rn-tester/Pods/../../react-native/ReactCommon/jsi
CMake Error: CMake was unable to find a build program corresponding to "Unix Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
Command PhaseScriptExecution failed with a nonzero exit code
```
## Changelog:
[INTERNAL] [FIXED] - Fix RNTester hermesc build issue on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/51989
Test Plan: Build RN tester locally
Reviewed By: cortinico
Differential Revision: D76606335
Pulled By: cipolleschi
fbshipit-source-id: f442b77aefb3afacd6d9fb1f3d515b8d63c526ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52020
Aligns the type exports of `ReportFullyDrawnView` across platforms, so that they are resilient to any changes made to `View` itself.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D76638685
fbshipit-source-id: 612b2bcd76e70751aec691a24f31beca453cea35
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51425
# Problem
React native's new architecture will allow components to do sync render/events. That means they'll makes synchronous dispatches from main thread to the js thread, to capture the runtime so that they can execute js on the main thread.
But, the js thread already as a bunch of synchronous calls to the main thread. So, if any of those js -> ui sync calls happen concurrently with a synchronous render, the application will deadlock.
This diff is an attempt to mitigate all those deadlocks.
## Context
How js execution from the main thread works:
* Main thread puts a block on the js thread, to capture the js runtime. Main thread is put to sleep.
* Js thread executes "runtime capture block". The runtime is captured for the main thread. The js thread is put to sleep.
* Main thread wakes up, noticing that the runtime is captured. It executes its js code with the captured runtime. Then, it releases the runtime, which wakes up the js thread. Both the main and js thread move on to other tasks.
How synchronous js -> main thread calls work:
* Js thread puts a ui block on the main queue.
* Js thread goes to sleep until that ui block executes on the main thread.
## Deadlock #1
**Main thread**: execute js now:
* Main thread puts a block on the js queue, to capture the runtime.
* Main thread then then goes to sleep, waiting for runtime to be captured
**JS thread**: execute ui code synchronously:
* Js thread schedules a block on the ui thread
* Js thread then goes to sleep, waiting for that block to execute.
**Result:** The application deadlocks
| {F1978009555} | {F1978009612} |
## Deadlock #2
**JS thread**: execute ui code synchronously:
* Js thread schedules a block on the ui thread
* Js thread then goes to sleep waiting for that block to execute.
**Main thread**: execute js now:
* Main thread puts a block on the js queue, to capture the runtime.
* Main thread then then goes to sleep, waiting for runtime to be captured
**Result:** The application deadlocks
| {F1978009690} | {F1978009701} |
# Changes
This diff attempts to fix those deadlocks. How:
* In "execute ui code synchronously" (js thread):
* Before going to sleep, the js thread schedules the ui work on the main queue, **and** it posts the ui work to "execute js now".
* In "execute js now" (main thread):
* This diff makes "execute js now" stateful: it keeps a "pending ui block."
* Before capturing the runtime, the "execute js now" executes "pending ui work", if it exists.
* While sleeping waiting for runtime capture, "execute js now" can wake up, and execute "pending ui work." It goes back to sleep afterwards, waiting for runtime capture.
## Mitigation: Deadlock #1
**Main thread**: execute js now:
* Main thread puts a block on the js queue, to capture the runtime.
* Main thread then then goes to sleep, waiting for runtime capture
**JS Thread**: execute ui code synchronously:
* Js thread puts its ui block on the ui queue.
* ***New***: Js thread also posts that ui block to "execute js now". Main thread was sleeping waiting for runtime to be captured. It now wakes up.
* Js thread goes to sleep.
The main thread wakes up in "execute js now":
* Main thread sees that a "pending ui block" is posted. It executes the "pending ui block." The block, also scheduled on the main thread, noops henceforth.
* Main thread goes back to sleep, waiting for runtime capture.
* The js thread wakes up, moves on to the next task.
**Result:** The runtime is captured by the main thread.
| {F1978010383} | {F1978010363} | {F1978010371} | {F1978010379} |
## Mitigation: Deadlock #2
**JS Thread**: execute ui code synchronously:
* Js thread puts its ui block on the ui queue.
* ***New***: Js thread also posts that ui block to "execute js now". Main thread was sleeping waiting for runtime to be captured. It now wakes up.
* Js thread goes to sleep.
**Main thread**: execute js now
* Main thread sees that a "pending ui block" is posted. It executes the "pending ui block" immediately. The block, also scheduled on the main thread, noops henceforth.
* Js thread wakes up and moves onto the next task.
**Result:** Main thread captures the runtime.
| {F1978010525} | {F1978010533} | {F1978010542} |
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D74769326
fbshipit-source-id: 854b83ce4e482a4030dc711834ea6c5613091537
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52000
Fixes https://github.com/facebook/react-native/issues/50338
The current JS FPS value is incorrect because the frame skipping logic hasn't been reimplemented in Fabric.
As we're looking into moving this into the performance panel, I've discussed with huntie
and agreed we'll just remove the value for now to don't show inaccurate informations.
Changelog:
[Android] [Changed] - Hide JS FPS on performance overlay as not accurate
Reviewed By: huntie
Differential Revision: D76590909
fbshipit-source-id: 90b0d9c84f9aefa9197243ebb57f4e86107d6c01
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51982
This class should not be accessed externally. I'm making it internal.
On top of this, it was not fully reimplemented on NewArch so is not working consistently.
This is gonna break one library which is unmaintained and not properly udpated to work with NewArch
https://github.com/hannojg/react-native-performance-stats
Changelog:
[Android] [Breaking] - Cleanup and internalize FpsDebugFrameCallback
Reviewed By: huntie
Differential Revision: D76531175
fbshipit-source-id: 25598eb7c1ecf476b69bb6a2f2f8088a57b9fbc2
Nicola Corti
Christian Falch
Pieter De Baets
Riccardo Cipolleschi
Samuel Susla
Andrew Datsenko
Fabrizio Cucci
Rubén Norte
zhongwuzw
Tim Yung
Nick Gerleman
Gabriel Donadel
Christoph Purrer
Peter Abbondanzo
Mathieu Acthernoene
Janic Duplessis
Jorge Cabiedes Acosta
Alan Lee
David Vacca
Mateo Guzmán
Ramanpreet Nara