Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50914
The URL spans generated by Linkify are not actually accessible because we do not update the delegate's virtual views.
I also had to change how AccessibilityLinks get generated, since it does not work well if it includes spans that are not `ReactClickableSpans`
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D73612119
fbshipit-source-id: 0c6028a7473e0484216300863f2d7a043fb2ea85
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50887
There is currently a bug with the recent changes to keyboard accessibility with Text and nested links. If something with nested links has a `dataDetectorType` prop then we have 2 different selections when we navigate with arrow keys since the drawing behind the 2 are separate.
Removing LinkMovementMethod is not possible since it allows for clicking the links it detects
As a result, lets just allow it to take precedence over the delegate when handling link navigation in the cases its present.
Changelog: [Android][Fixed] - Double selection with dataDetectorType and links
Reviewed By: NickGerleman
Differential Revision: D73549839
fbshipit-source-id: bbe37470e78841bb119fa68e197b327023031c7e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51029
# Changelog: [Internal]
Instead of exposing vector of samples / call frames directly, we will share pair of iterators that would allow iterating over them in a specified order.
Reviewed By: dannysu
Differential Revision: D73448002
fbshipit-source-id: 16c476453e943a71403b375b168b30da7d261cfa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51028
# Changelog: [Internal]
There is a way to implement the trie without allocating `ProfileTreeNode` on the heap. The serialization logic (`RuntimeSamplingProfilerTraceEventSerializer.cpp`) remained mostly the same, the only new limitation is that we can only use pointer to `ProfileTreeNode` until the next push into a `children` container, when all pointers are invalidated. Not sure if we can avoid this invalidation, since we don't know the potential size of `children` vector, it has to be dynamically allocated.
Main changes are in `ProfileTreeNode`:
- Instead of receving already created instane that will be check if it should be added as a child, it will expose predicate to check if such node already exists - `getIfAlreadyExists`. If not, then caller can use `addChild` to register it and receive a pointer.
Reviewed By: huntie
Differential Revision: D73213284
fbshipit-source-id: 385be884bcc5feb61b3a8cbd0ff36402e3b20c6c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50847
# Changelog: [Internal]
We have different types of call frames, right now we defined 4 of them. Previously, they would descend from `ProfileSampleCallStackFrame`, which has `kind_` field that can be used for determining the type of the call frame.
We were using polymorphism later on React Native side to cast from base type to derived.
Instead of this, and instead of doing heap allocations for potentially tens of thousands of objects, we will use std::variant for storing frames in a single container and them distinguishing them.
This fixes memory leaks caused by new-ing objects and not clearing out when Profile is destroyed.
Reviewed By: dannysu
Differential Revision: D72803934
fbshipit-source-id: a279c6d68c7c2628f0eab585f33137222ad9e3f1
Summary:
The `Object.assign` support is [inherently unsound](https://github.com/facebook/flow/issues/3392), carries a lot of tech debt, and we want to error on them.
This diff pre-suppresses errors that will be added in the next version of Flow, to make the next release easier.
Changelog: [Internal]
Reviewed By: panagosg7
Differential Revision: D73963639
fbshipit-source-id: ebefc82c123588eb0b72ab48a24e45c42be33267
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51035
This is causing some problems with older versions of Android. Let's back out for now.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D73950625
fbshipit-source-id: 424dfc1216ae811e1e287774c6ac5d0c9ba5aa17
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51004
It would be very convenient if `accessibilityOrder` could reference itself. Meaning the View with the `accessibilityOrder` prop can include its own `nativeID` in the array. This makes sense API wise - we allow for referencing parents and their descendants, so long as they are treated as an element and not a container. This is pretty nice since you no longer have to wrap everything in a View who's sole purpose is `accessibilityOrder`.
Under the hood things get a bit garbled, however, since iOS only lets you have UIViews that are either accessibility elements or accessibility containers - and we need to support both at the same time for this to work. To do this, we make use of the `UIAccessibilityElement` class and just forward all of the logic to the View with the `accessibilityOrder` prop. This View will also not be an accessibility element from the point of view of iOS.
Changelog: [Internal]
Reviewed By: jorge-cab
Differential Revision: D73792934
fbshipit-source-id: b0810277c8e410319639b863b59e4e60782bffca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50925
This crashes without this change, now it does not!
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D73626930
fbshipit-source-id: 37fd99372d1781a9e895e854e8b2f75c568ef9c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51027
Simple change to make the host of `experimental_accessibilityOrder` include the view that hosts the property in its order.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D73808337
fbshipit-source-id: 441329a6ca0cd4b0aba08bddb15143215d337e01
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51014
Starting from the [24th of April](https://developer.apple.com/news/upcoming-requirements/?id=02212025a), Apple only accepts app built with Xcode 16.0 or greater
This change bumps our CI to ensure that everything works with Xcode 16.
## Changelog:
[Internal] - Bump CI to Xcode 16.2
Reviewed By: javache
Differential Revision: D73924819
fbshipit-source-id: 82cdca5e12cee505de6e97513c07678776642d88
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51022
As per title, it bumps maestro to 1.40 in CI
## Changelog:
[Internal] - Bump Maestro to 1.40
Reviewed By: cortinico
Differential Revision: D73929936
fbshipit-source-id: 7dfd974a0d1227520c5a6892ff4f157633fdbd54
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51013
There's no need to use a singleton pattern here, we can just use a Kotlin object.
Changelog: [Android][Removed] Deprecated `ResourceDrawableIdHelper.instance`
Reviewed By: Abbondanzo
Differential Revision: D73923281
fbshipit-source-id: f46e125ce595fe4506b9fb5aa471109f5ba150f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50998
I'm reverting this as this change is too disruptive for the OSS ecosystem.
It will break ALL the apps written in Kotlin and it's coming too close to the branch cut which is in less than one week.
We need to re-do this migration in a non breaking manner after the branch cut as this is highly disruptive for little benefit at this point
Changelog
[Android][Changed] - Back out "[RN][Kotlin] Migrate ReactActivity"
Original commit changeset: 936263100ca9
Original Phabricator Diff: D73507044
Reviewed By: mdvacca
Differential Revision: D73864144
fbshipit-source-id: 264921b1f1cd38301e66364de4b619807272bd27
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51006
Moves a bit of code, reading spans that we may not control, to query for `Spanned`, instead of `Spannable`, since some code (see last diff around ellipsization) may wrap intermediate Spannables.
Changelog: [internal]
Reviewed By: joevilches
Differential Revision: D73820368
fbshipit-source-id: e107bcf1f2f7d5555fca68fb2209c12c3f99c099
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51007
Right now, we fully layout text, then use max lines to determine a metric to use when calculating size.
Android API 23+ which we fully target allows incorporating ellipsization and maxlines directly into the layout. This will let us directly draw the layout when using maxLines later. This may also let Android optimize line-breaking a bit, when we hit truncation.
Special care is taken not to set this when we are in `adjustsFontSizeToFit` path, so that line count will flow over, signifing overflow.
I think the main user-facing change is that `onTextLayout` events will have measures post-ellipsization.
Changelog:
[Android][Changed] - Incorporate maxLines and ellipsization into text layout
Reviewed By: joevilches
Differential Revision: D73811573
fbshipit-source-id: df83295d0902ae8b043ce57b06cbb9c8f0c194fc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51005
We need to get a context corresponding to the root being passed, to be able to resolve things like theme to use. RIght now that's a TODO, that's been around since new arch. Let's pass the real data along.
Changelog:
[Android][Fixed] - Correctly Pass SurfaceID to TextLayoutManager
Reviewed By: javache
Differential Revision: D73819640
fbshipit-source-id: 1ae2505b59b8577d35a4dc5bb2a524663f3bd47f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50889
This effectively reverts D67064488
We are trying to smash together functions, variables, virtual or non-virtual, all required by different platforms, into a single header, often using #ifdefs that are not what we want (apart from a bad editor experience, `#ifdef ANDROID` may or may not be compiled into the react-native-cxx platform, and we cannot use it for the Android platform reliably).
For Facsimile, we are going to be introducing more potential divergence, with the idea of `PreparedText`, where we can generate intermediate products as part of the layout process to be reused later. I'm planning to design that in a way which can be eventually reused across platforms, but not everywhere.
I think the best path for this is going to be to allow each platform to have their own headers, instead of the current messiness, then allow shared code (e.g. in `ParagraphShadowNode`) to pick how to interact at compile time. I added an example of this as part of `TextLayoutManagerExtended`, to customize how we act if a `TextLayoutManager` chooses not to implement `measureLines`.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D73557126
fbshipit-source-id: 9851ebba691b0d123f6a355126f2d5b003aceba0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50970
__onAnimatedValueUpdateReceived is called from 2 places.
It is called from the onAnimatedValueUpdate subscription where the source of the values comes from here: https://fburl.com/8v2cwd2x with getValue() returning the offset + value components combined.
It's also called from in the animation end callback here: https://fburl.com/h36xy2nw where the source of this value comes from https://fburl.com/sud7m7st. In this case it's accessing `nodeValue` directly rather than calling getValue() and so it only includes the value component.
In this diff we pass both the value and offset in both onAnimatedValueUpdate callbacks as well as endCallback.
This allows us to separate the value from the offset on the JS side and ensures we have the latest offset value from native
Changelog: [Android][Fixed] - Sync offset and value from native -> js in separate fields
Reviewed By: zeyap
Differential Revision: D73795619
fbshipit-source-id: e8ed234497e3fcaf9d2a137aa1e17ca8d0f76d97
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51000
changelog: [internal]
# Why so many tests?
Differentiator has two modes: regular and reparenting. The reparenting one is almost a completely separate Differentiator, effectively doubling the complexity. It handles quite a few different special cases and is not covered by any reasonable tests, so here I am adding the tests to make sure every branch of the reparenting Differentiator is traversed.
Reviewed By: lenaic
Differential Revision: D73845746
fbshipit-source-id: 27a9fd72a5f8111b84e231cf8f495e278037a323
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50971
This feature flag enables a fix of double measurement on a subset of android components
changelog: [internal] internal
Reviewed By: yungsters
Differential Revision: D73804996
fbshipit-source-id: 3271deb8a8bf4c132cbfb6819f72cab556c6253c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50985
# Changelog: [Internal]
There may be tens of thousands of samples stored, so we should avoid copying it. I don't think we should restrict it from being copied, though, but we don't need it to copy in this case.
Reviewed By: huntie, dannysu
Differential Revision: D73106950
fbshipit-source-id: 45c027ea8bfc3424fe3428f5578d5bed3d1cdda9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50984
# Changelog: [Internal]
We are only using these struct to define how they will be serialize before sending over CDP, no need for custom constructors.
Also updated the naming of the serialization method to align with other parts of the project: `asDynamic()` -> `toDynamic()`.
Reviewed By: huntie
Differential Revision: D73774114
fbshipit-source-id: d0371cf3dee7584daa77054f73aced440550e674
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50988
Changelog: [internal]
This fixes a potential bug where we coalesce unique events with non-unique ones of the same type and target.
Not marked as a bug fix in the changelog because this wouldn't happen in practice, as we always dispatch events of a given type the same way (all unique or all non-unique).
Reviewed By: sammy-SC, javache
Differential Revision: D73849222
fbshipit-source-id: 6f387d63b3a68dccc81c110287d42e15e31c181e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50987
Changelog: [internal]
This adds a new `isUnique` option in `RawEvent` to determine if it's unique (whether it should be coalesced with other unique events of the same type and target).
This effectively makes `dispatchUniqueEvent` redundant, as we can use `dispatchEvent` with a `RawEvent` marked as unique.
This will allow us to fix the bug we found in the new tests for event dispatching, where non-unique events of a given type where being coalesced with non-unique events of the same type.
Reviewed By: javache
Differential Revision: D73849220
fbshipit-source-id: ce89623aee509071ab6a86654ee25d9614863a8a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50989
Changelog: [internal]
Just adding a test suite to verify the behavior of event dispatching in Fabric (especially around event priorities, automatic determination based on ContinuousStart/ContinuousEnd and unique events).
This also surfaced a bug where we incorrectly batch unique and non-unique events together (see the disabled test).
Reviewed By: javache
Differential Revision: D73849218
fbshipit-source-id: 404172822d6985283a161c8a56575e0b5658a5cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50986
Changelog: [internal]
This just exposes some enum values and methods that we forgot to expose in a few interfaces.
Reviewed By: javache
Differential Revision: D73849221
fbshipit-source-id: 19014d53216e67c77b0c31e5ade8f86de071b001
Summary:
This PR aims to migrate ViewGroupManager to kotlin as part of https://github.com/facebook/react-native/issues/50513
## Changelog:
[ANDROID][CHANGED]Migrate ViewGroupManager to kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/50895
Test Plan: Tested with RN tester with old and new arch
Reviewed By: javache
Differential Revision: D73770843
Pulled By: cortinico
fbshipit-source-id: 45959a8bf512b3590ca8bc64dac281e13fa41ca3
Summary:
With the redesign of the new app screen, the E2E tests against the template started failing because we don't have a `Step One` string anymore.
This change should fix them.
## Changelog:
[Internal] - Fix Template E2E tests
Pull Request resolved: https://github.com/facebook/react-native/pull/50990
Test Plan: tested by running the E2E tests on this PR
Reviewed By: huntie
Differential Revision: D73855988
Pulled By: cipolleschi
fbshipit-source-id: d0d72e5a07cd88923e310767eae27f5df376d637
Summary:
As part of the work to integrate libraries with our nightlies, we want to receive a message when the libraries are failing to build on discord. This will help us catch breaking changes early on and onboarding library maintainer as soon as possible.
## Changelog:
[Internal] - Integrate with Discord when nightly fails
Pull Request resolved: https://github.com/facebook/react-native/pull/50979
Test Plan: GHA
Reviewed By: cortinico
Differential Revision: D73845810
Pulled By: cipolleschi
fbshipit-source-id: c6cfdf16b29642b1c3ad3872096c0e815fa88a0a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50992
shouldnt happen but when it does it shouldnt crash some more
fix for P1798860939
Changelog: [Internal] - fix crash when onHostPause is called and mCurrentActivity is null
Reviewed By: cortinico
Differential Revision: D73852655
fbshipit-source-id: 19ee4ada1c71a34a6115882e9a558b4ea9f9d8c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50965
While D72228547 has recently disallowed all `./src/*` subpath imports from React Native (functionally, `./src/private/*`), we have a number of APIs that are imported from Meta product code legitimately — e.g. as part of validating under-development React Native features internally in real Meta apps.
This diff defines a new, exported `./src/fb_internal/*` subpath via `package.json#exports`, which will allow us to expose select entry points for this purpose.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D73770609
fbshipit-source-id: 397019669e565b95a86302ef30f80b65a17dcc0d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50976
This is the second part of the migration of `rn-tester` package to use root imports. In this diff the `CodegenTypes` namespace is used to define Codegen primitives.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D73780584
fbshipit-source-id: c13c2dfcfa4d023978a9463af1d2a3bf7b72476c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50975
Re-defining types in `AnimatedExports.js.flow` shadows their documentation located in `AnimatedImplementation`. Moving them to the `AnimatedExports` fixes the issue for generated TS types.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D73840908
fbshipit-source-id: 2648498a53660b483c70be647716accc11e96d82
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50967
In some cases we may want to check this only if the prop exists
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D73793783
fbshipit-source-id: b498f82414edf63d8644b90bb3932298eb37b43c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50941
Without doing this, using Animated.event to update a value with an offset causes the value to revert to not having an offset because the native side doesn't even know about the offset if it hasn't been synced.
Don't think there's a better place to sync this for the cases where an animation is kicked off entirely from the native side
Changelog: [Android][Fixed] - Ensure latest offset value is synced to native
Reviewed By: javache
Differential Revision: D73622302
fbshipit-source-id: 7e67a7f41d900cc225af410af94ccdfd33c170c8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50850
This prop will be used to enable screen reader focusability without allowing keyboard focus. Mostly a quality of life prop for product engineers and maps 1:1 to Android
Changelog: [Android][Added] - Expose Android's screenReaderFocusable prop
Reviewed By: javache
Differential Revision: D73382051
fbshipit-source-id: 8171b9d24a735dd42d54abe4537fb487bdd011b7