Summary:
`SafeAreaView` has been marked for deprecation some time ago. The [following discussion](https://github.com/react-native-community/discussions-and-proposals/discussions/827) summarizes some of the arguments for it, but in a nutshell: it is iOS-only, limited in functionality, and incompatible with Android 15's enforced edge-to-edge rendering.
~~The Android/Kotlin classes have also been deprecated.~~ Not anymore, they are internal and might stay as they are.
## Changelog:
[General] [Deprecated] - Deprecate SafeAreaView due to its iOS-only support and incompatibility with Android 15 edge-to-edge behavior; recommend using react-native-safe-area-context instead.
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/51896
Test Plan: Access `SafeAreaView` in your code and check that the deprecation warning logs exactly once in the console.
Reviewed By: rshest
Differential Revision: D76816160
Pulled By: cortinico
fbshipit-source-id: 60f539f9425f8ed8e19578a4530cb1f7d9b54488
Summary:
Due to us moving to central.sonatype.com for publishing, we cannot publish and release the Maven repository in 2 distinct invocations.
This consolidates all the publishing job to happen during build_npm_package
Changelog:
[Internal] [Changed] -
Reviewed By: fabriziocucci
Differential Revision: D76888543
fbshipit-source-id: 3cb0db6176ed2221a12b4f3f1f575232aa006a6c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52081
changelog: [internal]
# The problem in Java and Obj-C Native Animated
--------------------
Event based animations in Native Animated have one big problem: detecting when the gesture is completed. This has led to number of bugs over the years that manifest as Pressable's onPress not triggering. The root cause of the problem is disconnect between where a piece of UI is on the screen and where Fabric thinks it is. Fabric is used for hit testing, and other things like intersection observing, and if Fabric does not have up to date values, weird things start happening.
This diff implements completion detection for event based animations. Unlike previous solutions, it does not depend on sequence of events nor it uses React setState to update shadow tree.
# Completion Detection
--------------------
The key mechanism for marking event animations as completed is in the `onRender` method:
- After processing animations, if `onAnimationFrame` returns false - indicating no UI changes, the system assumes all event-driven animations have completed.
- it then:
* Collects all animated value nodes connected to event drivers.
* Updates all nodes connected to these "finished" animations.
* isEventAnimationInProgress_ to false.
* Commits final property values to the UI.
The benefits over the previous solution:
- It works across all platforms without the need to emit "completion events".
- It uses a UI frame that wouldn't animate anything to do syncing work. Using main thread IDLE time towards bookkeeping.
- No need to call into JavaScript for synchronisation.
Reviewed By: zeyap
Differential Revision: D76743467
fbshipit-source-id: b21ab5ef9c71ff93fd0250e6af6b22ded395be8d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52094
Changelog [Internal]:
- LegacyViewManagerInteropComponentDescriptor was initiaizing Module just to get the `Class` for `componentName`. This can cause deadlock issue when we have module that needs mainQueue to initialize.
Reviewed By: RSNara
Differential Revision: D76757706
fbshipit-source-id: 6fc6127b6ff472fda509364f0c3daa13b6a6df1e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52056
This prop should only be used on Views using it in Text is not very intuitive and also would require some unnecessary edge case handling on Android which we now also remove
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D76744972
fbshipit-source-id: 23113789747295ea1a306727f1e29e3ddc078ac4
Summary:
Compile out the legacy c++ core from android.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D72991984
fbshipit-source-id: 56bb6ca1c4797adb9235e982121712b11e85e109
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52073
X-link: https://github.com/facebook/yoga/pull/1820
Fixes https://github.com/facebook/yoga/issues/1819
Yoga has a fast path when measuring a node, if it thinks it knows its dimensions ahead of time.
This path has some eroneous logic, to set both axis to owner size, if *either* will evaluate to zero, while having an `YGMeasureModeAtMost`/`FitContent` constraint. This means that if a node is given a zero width, and Yoga later measures with with `FitContent`, its height will become the maximum allowable height, even if it shouldn't be that large.
We can fix this, by only allowing if both axis are this fixed case, instead of just one.
This bug has existed for about a decade (going back to at least D3312496).
Changelog:
[General][Fixed] - Fix possible invalid measurements with width or height is zero pixels
Reviewed By: yungsters
Differential Revision: D76793705
fbshipit-source-id: ea4c00e688912a58c08801e4a14ddf1b293a5d86
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52069
Noticed an E2E tests against old emulator version showed aliased Text against Facsimile. This is because non-scratch-paint path does not explicitly enable anti-aliasing (like TextView does), older versions of Android don't enable by default, and `updateTextPaint()` no longer sets, after call to `paint.reset()` was removed.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D76780749
fbshipit-source-id: 26f0de6d6558649fe08339f1ac91390bbd4cce3c
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:
This diff adds snapshot `diff-api-snapshot` script for public JS API breaking change detection.
### Motivation
Detecting if there are any breaking changes introduced in the commit. It is achieved by comparing `ReactNativeApi.d.ts` rollup from the current and previous revision.
This is a naive implementation with a three possible outcomes:
- BREAKING
- POTENTIALLY_NOT_BREAKING,
- NOT_BREAKING
The algorithm analyses exported top-level statements (after inlining) in both rollups and tries to create a mapping between them by name.
The **BREAKING** outcome happens whenever the statement is:
- removed
- renamed
- changed
- not exported anymore (private)
The **POTENTIALLY_NOT_BREAKING** outcome happens if it's not BREAKING and the new statement is added.
The **NOT_BREAKING** outcome happens if public API snapshot doesn't change.
Changelog:
[General][Added] - Add public JS API breaking change detection under `yarn diff-api-snapshot` script.
Pull Request resolved: https://github.com/facebook/react-native/pull/51972
Test Plan:
Signals, added tests.
In `react-native-github` run:
`yarn test scripts/diff-api-snapshot/__tests__/diffApiSnapshot-test.js`
Rollback Plan:
Reviewed By: j-piasecki
Differential Revision: D76430965
Pulled By: coado
fbshipit-source-id: 095a196aa4f643501db0af9262556ddefff5d30d
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