Summary:
In https://github.com/facebook/react-native/pull/50734, `LayoutAnimationController` was migrated to Kotlin and all of its methods are now marked as final.
However, this class is used and extended by `react-native-reanimated` in order to provide Layout Animations for Android on the Old Architecture. With all its methods being marked as final, the builds are failing.
This PR restores the possibility to extend `LayoutAnimationController`.
## Changelog:
[ANDROID] [FIXED] - Restored the possibility to extend `LayoutAnimationController`
Pull Request resolved: https://github.com/facebook/react-native/pull/51479
Test Plan: I've checked that this PR fixes build errors caused by `LayoutAnimationController` in react-native-reanimated.
Reviewed By: cipolleschi, mdvacca
Differential Revision: D75079557
Pulled By: cortinico
fbshipit-source-id: beeb700cbad87362dda4b60941124562c4753815
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51496
Fixes problem with generics passed to `VirtualizedSectionList` in generated types. The `flow-api-translator` creates a re-declaration for `export default` variables which shadows generics.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D75141051
fbshipit-source-id: 260ef066038320eee3ffa93692f77f1eff5c9205
Summary:
Calls to create timers should return sequential ids (integers greater than zero in the spec's words). This regressed in the `TimerManager` implementation, which instead starts at zero inclusively.
This has two side-effects for code assuming a spec-compliant implementation of `setTimeout` and `setInterval`:
- Calls to `clearTimeout(0)` or `clearInterval(0)` will potentially cancel scheduled timers, although it's supposed to be a noop
- Predicates like `if (timeoutId)` will fail since they assume non-negative ids
The change in this PR is to align with WHATWG HTML 8.6.2 (Timers): https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timers
> otherwise, let id be an [implementation-defined](https://infra.spec.whatwg.org/#implementation-defined) integer that is **greater than zero** and does not already [exist](https://infra.spec.whatwg.org/#map-exists) in global's [map of setTimeout and setInterval IDs](https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#map-of-settimeout-and-setinterval-ids).
Specifically,
- we should return `0` to indicate that no timer was scheduled
- we should start generating timer IDs at `1` instead of `0`
This was previously raised in review comments here: https://github.com/facebook/react-native/pull/45092/files#r1650790008
The spec-incompliant behaviour was raised in an issue here: https://github.com/apollographql/apollo-client/issues/12632#issue-3075269978
This PR does not,
- add bounds checking on `timerIndex_` and add a search of an available id that isn't in the unordered map
- exclude `0` from being an accepted `TimerHandle` in `TimerManager::createTimer` or `TimerManager::deleteTimer` since the above bounds checking hasn't been added either
## Changelog:
[GENERAL] [FIXED] - Align timer IDs and timer function argument error handling with web standards.
Pull Request resolved: https://github.com/facebook/react-native/pull/51500
Test Plan:
- Run `setTimeout` / `setInterval`; before applied changes the timeout for the first timer will be `0`
- Run `setTimeout(null)`; before applied changes the timer ID will be non-zero
- Run `setInterval(null)`; before applied changes an error will be thrown rather than `0` being returned
Reviewed By: cipolleschi
Differential Revision: D75145909
Pulled By: rshest
fbshipit-source-id: 6646439abd29cf3cfa9e5cf0a57448e3b7cd1b48
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51338
There was some problems removing this feature flag earlier in that, on older android versions, we would try to focus the top most text input whenever any other text input would try to blur. This was ultimately and issue with how Android implements `clearFocus`. To fix this, lets block the focusability of all views while we clear the focus, then re-enable.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D74760594
fbshipit-source-id: 2811c08ad6ed0855da0a4d7fca89fb08f84905c2
Summary:
I noticed the link to networking in new app screen is wrong. So correcting it here
## Changelog:
[GENERAL][FIXED] - Fix Networking URL in New app screen
Pull Request resolved: https://github.com/facebook/react-native/pull/51396
Test Plan: Click on the link to open
Reviewed By: arushikesarwani94
Differential Revision: D74886240
Pulled By: cortinico
fbshipit-source-id: 19ccf63e64f0e40df4a0ab4082299c654926e35d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51382
This diff replaces `dtslint` which is obsolete and [It is not intended to be used on its own, but as part of the definitelytyped set of packages](https://github.com/microsoft/dtslint) in favor of `tsc` type tests.
It's probably not necessary to have `test-typescript-offline` as tsc does that out of the box but doesn't test with multiple TS versions.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D74804967
fbshipit-source-id: 4c581ba5debf6fd0bb8dcddbb95f3c85b05082d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51383
This diff is a set of alignments/improvements in generated TS types. It includes:
- extending `AppStateStatus` with `extension` and `unknown`,
- exporting `AnimatedProps` under `Animated` namespace,
- resolving issue with discriminated unions in `ProgressBarAndroidTypes`,
- fixing `StyleSheet.create` type to accept only specified style properties,
- extending `TextProps` with `AccessibilityProps`,
extending Fn Args generic with `$ReadOnlyArray` in `ErrorUtils`,
- small `__typetests__` adjustments,
- removing type test `styleDimensionValueValidAnimated` as `DimensionValue` no longer accepts `AnimatedNode`,
- removing `styleDimensionValueInvalid` as `DimensionValue` accepts any string now - template literal types in Flow are not supported,
- changing `overlayColor` type to `ColorValue` to align with manual types,
- fixing `AnimatedPropsAllowList` type which wasn't correct in TS because index signature type was different from style type,
- using `DeviceEventEmitter` instead of `DeviceEventEmitterStatic` in type tests which is equivalent in both new and old types - `DeviceEventEmitterStatic` was only a type of `DeviceEventEmitter`,
- removing type test for checking forwarded key type - doesn't work with new types and that shouldn't be supported,
- removing `Animated.legacyRef` type test - not included in new types,
- adding `DOMRect` from "dom" lib to `globals.d.ts` to not include "dom" lib in the tsconfig - tries to compare globals with `lib.dom.d.ts` and produces many errors,
- exporting `SectionListData`,
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D74807552
fbshipit-source-id: c5254ea0f701f3602b9d716faeb50ca1ab21b013
Summary:
Expo is using the backingmap to be able to update properties in a fast and performant way in two overridden view manager subclasses (ViewGroupManager subclass is one of them).
This diff exposes the backing field via JvmName using the `internal_` prefix.
So Expo can keep on accessing the field as they were doing before. In the long run we should prevent them from accessing this property altogether but this would require a different API.
## Changelog:
[INTERNAL] -
Pull Request resolved: https://github.com/facebook/react-native/pull/51386
Test Plan: Build with Expo modules
Reviewed By: cipolleschi
Differential Revision: D74884533
Pulled By: cortinico
fbshipit-source-id: e76673c794a6a125059633d29445d991d867b770
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51285
The `composeStyles` function should correctly determine the type of the input styles (`ViewStyle`, `ImageStyle`, `TextStyle`) base on the output type:
```ts
const combinedStyle8: StyleProp<ImageStyle> = StyleSheet.compose(
// ts-expect-error
composeTextStyle,
composeTextStyle,
);
```
This diff adds generic type checking for `compose` function and fixes `ImageStyle` overflow prop type which accepted `scroll` property (which wasn't previously accepted in manual types) and which enables type system to distinguish `ImageStyle` from `ViewStyle` and `TextStyle`:
previous:
```ts
overflow?: 'visible' | 'hidden' | 'scroll'
```
current:
```t
overflow?: 'visible' | 'hidden'
```
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D74574293
fbshipit-source-id: 751a44f2d3cd43055d93031343995f16ef87b185
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51307
D72228547 added the `exports` field to the main `react-native` package, in which all imports from `./src/*` are explicitly disallowed. This was expected to be a breaking change and to limit the surface area of it, this diff will allow using all imports in jest tests.
Changelog: [General][Added] Added a custom Jest resolver to opt out from handling "exports" in tests
Reviewed By: huntie
Differential Revision: D74708701
fbshipit-source-id: 9a2714f4e6f78ffbad9e56b5bb92657c9ea908ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51121
Previously could match via the `"./*"` subpath when `"react-native-strict-api"` is not set. Only the entry point `./types_generated/index.d.ts` should be exposed.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D74242716
fbshipit-source-id: 232c90f34fafe8fdf1a5a7ef1fec4acc191525b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51096
**Problem:** `Activity.onBackPressed()` has been deprecated and with targetSdk 36, predictive back will be enforced and the API no longer called. We need to migrate to backward compatible AndroidX `OnBackPressedCallback`.
- https://developer.android.com/about/versions/16/behavior-changes-16#predictive-back.
**Solution:**
`OnBackPressedCallback` is registered conditionally only if it is `targetSdk` 36 or greater.
If the callback in enabled, `onBackPressed()` is not called and callback is used regardless of `android:enableOnBackInvokedCallback` property in <application> or <activity> set in AndroidManifest.xml.
As a workaround callback is manually calling existing `onBackPressed()`.
This is done rather than removing onBackPressed() completely and using only `OnBackPressedCallback` as we are not sure of the impact of removing the implementation entirely. Once we determine it is safe to do so then, we should remove the workaround and fully transition to `OnBackPressedCallback`
* I also surveyed child classes extending ReactActivity for overridden `onPressedBack()` usage and found only one usage which will be handled later.
NOTE: `ReactDelegate.onHostResume()` sets up the `DefaultHardwareBackBtnHandler` using `ReactActivity` (https://fburl.com/ul47tbeo) and will be called from JS `BackHanderl.exitApp` (https://fburl.com/code/a4l2pjsw). Calling `BackHanderl.exitApp` enables predictive back to work.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D74161428
fbshipit-source-id: 2e081ba6922b315e9d1746e83a41bab5277fa62e
Summary:
Expo inherits from the DevServerHelper class, and needs it to be declared as open, the same goes for its public interface.
Expo is using this in `DevLauncherDevServerHelper` and overrides the methods:
- getDevServerBundleURL
- getDevServerSplitBundleURL
- getSourceUrl
- getSourceMapUrl
- isPackagerRunning
This PR fixes this by adding the open to the class and to the methods that should be open
## Changelog:
[ANDROID] [FIXED] - Made DevServerHelper and its method open so that they can be overridden.
Pull Request resolved: https://github.com/facebook/react-native/pull/51323
Test Plan: Verify that we can build against Expo.
Reviewed By: cipolleschi
Differential Revision: D74876479
Pulled By: cortinico
fbshipit-source-id: 0037d6f7cee190a690ec3ec59896df04f46797b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51381
Changelog: [General][Fixed] Fixed codegen breaking when a subset of `modulesConformingToProtocol` fields was specified or when the value was string
D70822061 introduced a new way of defininf modules and components in codegen, but accidentally introduced two breaking changes to the legacy syntax:
- before that diff, in case of 1:1 mapping, the value of the fileds could be a string, while after, it required it to be an array
- before that diff, not all of the fields on `modulesConformingToProtocol` had to be defined in `package.json`, while after, it required all fields to be defined even if unused
Reviewed By: cipolleschi
Differential Revision: D74875251
fbshipit-source-id: 610103b508f1462b4de01725f9b0a87341571197
Summary:
See https://github.com/facebook/react-native/issues/51212 - children aren't updated correctly in an old arch native view using the interop layer under Fabric.
This is caused by the mountChildComponentView method not updating the view, only adding the new view to a list that will be used on the next update to mount the child.
This commit fixes this by adding the same pattern as in unmountChildComponentView where children are inserted directly if the underlying paperview is available in the adapter - otherwise it uses the mounting list as before.
#Closes 51212
bypass-github-export-checks
## Changelog:
[IOS] [FIXED] - fixed adding child views to a native view using the interop layer
Pull Request resolved: https://github.com/facebook/react-native/pull/51213
Test Plan:
**Previous output**:
<image src="https://github.com/user-attachments/assets/472b95e7-0921-46c9-be6a-f31759c0cd26" width="200px" />
**After fix**:
<image src="https://github.com/user-attachments/assets/554387cd-c264-483e-9c52-d9cd40b42601" width="200px" />
Reviewed By: sammy-SC
Differential Revision: D74471278
Pulled By: cipolleschi
fbshipit-source-id: 798f9e7be389359bd6e3aa1b6a6e9fb799fcb369
Summary:
After conversion to Kotlin we could no longer override the removeView function since it is no longer open. The rest of this class can be overridden as before, but since functions are final by default this doesn't work for the new `removeView` function.
Expo is overriding the `removeView` functions in `GroupViewManagerWrapper.kt` (a lot of other ViewManager methods are also overridden here, but the `removeView` is introduced in `ViewGroupManager` and needs to be open as well. `GroupViewManagerWrapper.kt` is a replacement view manager that adds support for a delegate that will receive callbacks whenever one of the methods in the view manager are called.
This commit fixes this by making the removeView function explicitly open.
## Changelog:
[ANDROID] [FIXED] - Made function `removeView` open in Kotlin class
Pull Request resolved: https://github.com/facebook/react-native/pull/51322
Test Plan: Verify that Expo can build against this class.
Reviewed By: javache
Differential Revision: D74807744
Pulled By: cortinico
fbshipit-source-id: 55f4b9deccb7d82ceb78be1d56c2b99a6f7e3ce9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51135
In generated types default exported variables are re-declared which shadows attached tags and doc blocks. This transform moves necessary comments on top of re-declarations to keep them accessible.
Example output for SafeAreaView:
```ts
import type { ViewProps } from "../View/ViewPropTypes";
import View from "../View/View";
import * as React from "react";
declare const exported: (props: Omit<ViewProps, keyof {
ref?: React.Ref<React.ComponentRef<typeof View>>;
}> & {
ref?: React.Ref<React.ComponentRef<typeof View>>;
}) => React.ReactNode;
/**
* Renders nested content and automatically applies paddings reflect the portion
* of the view that is not covered by navigation bars, tab bars, toolbars, and
* other ancestor views.
*
* Moreover, and most importantly, Safe Area's paddings reflect physical
* limitation of the screen, such as rounded corners or camera notches (aka
* sensor housing area on iPhone X).
*/
declare const SafeAreaView_DEFAULT: typeof exported;
declare type SafeAreaView_DEFAULT = typeof SafeAreaView_DEFAULT;
export default SafeAreaView_DEFAULT;
```
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D74249424
fbshipit-source-id: 5cdd1c746e7fed99e3d3427d6ebf4c0e7ba3f3fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51136
This diff attaches doc block to ProgressBarAndroid copied from the manual TS types.
Generated types result:
```ts
import * as React from "react";
import type $$IMPORT_TYPEOF_1$$ from "./ProgressBarAndroidNativeComponent";
type ProgressBarAndroidNativeComponentType = typeof $$IMPORT_TYPEOF_1$$;
import type { ProgressBarAndroidProps } from "./ProgressBarAndroidTypes";
export type { ProgressBarAndroidProps };
declare let ProgressBarAndroid: (props: Omit<ProgressBarAndroidProps, keyof {
ref?: React.Ref<React.ComponentRef<ProgressBarAndroidNativeComponentType>>;
}> & {
ref?: React.Ref<React.ComponentRef<ProgressBarAndroidNativeComponentType>>;
}) => React.ReactNode;
/**
* ProgressBarAndroid has been extracted from react-native core and will be removed in a future release.
* It can now be installed and imported from `react-native-community/progress-bar-android` instead of 'react-native'.
* see https://github.com/react-native-community/progress-bar-android
* deprecated
*/
declare const $$ProgressBarAndroid: typeof ProgressBarAndroid;
declare type $$ProgressBarAndroid = typeof $$ProgressBarAndroid;
export default $$ProgressBarAndroid;
```
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D73855212
fbshipit-source-id: c6c09ea68c9f61f305f96c0954370bb938fc59d9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51192
The `build-types` script cannot currently resolve `react-native/assets-registry` and `react-native/js-polyfills`. This diff moves imported types from these packages to `react-native` to include them in generated types.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D74392568
fbshipit-source-id: cbce977b710f54dc53ce1b0fc080704b420490d4
Summary:
Enables `DEFINES_MODULE` in `React-jsc.podspec`
After upgrading app to RN `0.79`, when installing pods with JSC enabled there is an error being thrown that
`The following Swift pods cannot yet be integrated as static libraries`
`The Swift pod 'RNFlashList' depends upon 'React-jsc', which does not define modules. ...`
when installing packages that use Swift
## Changelog:
[IOS] [CHANGED] - enable `DEFINES_MODULE` in `React-jsc.podspec`
Pull Request resolved: https://github.com/facebook/react-native/pull/51160
Test Plan: RNTester runs and builds correctly
Reviewed By: huntie
Differential Revision: D74325357
Pulled By: cipolleschi
fbshipit-source-id: b994b7e678633440d5e362ae6965b2d5188d34f1
Summary:
Selectively disabling autolinking of a native dependency with components registered in the codegen configuration in react-native.config.js causes builds to crash upon launch on iOS. This is because the generated `RCTThirdPartyComponentsProvider.mm` file contains references to the excluded library using `NSClassFromString` causing the returned NSDictionary from `+[RCTThirdPartyComponentsProvider thirdPartyFabricComponents]` to be populated with nil values and therefore crashing the app. This has been confirmed in 0.78.2 and 0.79.2 but probably exists in 0.77.x as well.
The issue has been further described in https://github.com/facebook/react-native/issues/51077.
## Changelog:
[IOS][FIXED] - Skip codegen for selectively disabled libraries in react-native.config.js
Pull Request resolved: https://github.com/facebook/react-native/pull/51078
Test Plan:
1. Install a library that has the componentProvider field set in the codegen config (see reproducer) and install the iOS pods.
2. Build the app.
3. App should run successfully without any crashes.
Reviewed By: cortinico
Differential Revision: D74248371
Pulled By: cipolleschi
fbshipit-source-id: 1ff7b477ed3d94ca45616ae243d3d2d30bd897db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51246
Changelog: [General][Fixed] Fix generated types in react-native/virtualized-lists being used without opt-in
D71969602 introduces `exports` field to `package.json` files in `react-native` and `virtualized-lists`. In that diff, the `types` in `virtualized-lists` by default pointed to the new generated types without requiring the opt-in.
This fixes that by requiring the opt-in before using the generated types.
Reviewed By: huntie
Differential Revision: D74573321
fbshipit-source-id: fe05b0204a7200c1c91aac2614aa786bbbced2a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51101
TS LSP suggests importing/using components from `types_generated` directory which are exported under slightly different name than root exports. Prefixing default exports with `$$` fixes the issue.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D74177107
fbshipit-source-id: 86a6869c2aa7a113915184e4857a7882710b1db4
Summary:
When building the RNDependencies XCFrameworks we saw some errors in the CI servers about rsync failing:
`rsync(3031): error: poll: hangup on nonblocking write`
We decided to fix this by changing from using rsync to cp.
This commit fixes this by replacing rsync with cp, and adding a cleanup step after copying the XCFramework files.
## Changelog:
[INTERNAL] [FIXED] - Replacing rsync with cp, and adding a cleanup step after copying the XCFramework files.
Pull Request resolved: https://github.com/facebook/react-native/pull/51095
Test Plan: Run RNDependencies scripts on CI and verify that they're working as expected.
Reviewed By: fabriziocucci
Differential Revision: D74236114
Pulled By: cipolleschi
fbshipit-source-id: accd84abf7601919cfdbc1b6a8681a61d4293ca5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51112
Throw if getCatalystInstance() is executed when running on bridgless mode + legacy arch minification
This should be safe given that all the methods of BridgelessCatalystInstance throw exceptions
changelog: [internal] internal
Reviewed By: alanleedev
Differential Revision: D74200099
fbshipit-source-id: a888061250f19348a22895c3684aa2333280c916
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51111
BridgelessCatalystInstance is unused in bridgeless, any usage will lead to an exception / crash.
This diffs marks BridgelessCatalystInstance as LegacyArchitecture and removes DoNotStrip annotation to enable further optimizations
changelog: [internal] internal
Reviewed By: alanleedev
Differential Revision: D74200097
fbshipit-source-id: f99b6fa74c30bdf0e1cd6758e223601b3ce5826c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51088
Creates `ShadowNodeReferenceCounter`, a module with utilities for writing Fantom tests that make assertions about the reference count for a `ShadowNode` object.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D74131710
fbshipit-source-id: a949a402ee52f40445ce99c712540e80c8a05065
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51065
This adds infrastructure to let us start storing cached Android text layouts as part of a `ParagraphShadowNode`. After this, we will clear them out, and propagate them to state. Right now, the flag doesn't do much, apart from extra work.
This is done by adding `TextLayoutManagerExtended::supportsPreparedLayout()`, and `TextLayoutManager::PreparedLayout` types, to shim between platforms, then on Android, we add a `PreparedLayout`, which is for now just an Android layout, with extra field (`maxNumberOfLines`, for some reason not exposed on recent versions).
Android `TextLayoutManager` java side is split a little bit, so that we reuse all the existing logic for prepared layouts. I tried to set up the boundary, so that we don't reserialize a MapBuffer after preparation, and for simplicity, this means source of truth for attachment count, and attachment sizes, now lives on the layout. This means we need to change boundary a bit, where we are no longer able to pass in a buffer to fill from C++ side of attachment positions.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D73970149
fbshipit-source-id: ff71c227e062c16fe52a4eb3ba2acbebf3d96e56
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51107
Changelog: [iOS][Deprecated] Deprecate loadImageForURL in favor of new signature which uses completionHandlerWithMetadata
Updating the signature of completionHandlerWithMetadata to allow passing metadata through the completionHandlerWithMetadata in order to enable better instrumentation of image loading.
Reviewed By: philIip
Differential Revision: D73162738
fbshipit-source-id: 8e7e4ac35c9685a362a2efe08ebebbf0dd249ff9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51108
We calculate the width of text to be the full width of the container, if the text overflows the bounds of the container, instead of the wrapped width, to match the behavior on web.
Incorporating line count into layout defeats this logic, since the final layout never overflows. We need to also check to see if we are ellipsized (had overflow) instead.
Changelog:
[Android][Fixed] - Assume full container width when ellipsizing line
Reviewed By: joevilches
Differential Revision: D74204041
fbshipit-source-id: 1c2a7fc50f101bd4c9ed2f979534731992b5310b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51106
There was a strange bug reported to us with `accessibilityOrder` where an OCR model would announce text on the screen sometimes. This would happen if a focused `View` without a label would wrap `Text` that was was not included in the `accessibilityOrder` array. What happens under the hood is we have a focused `View` trying to coopt a label. It finds no accessibility nodes under it (because the `Text` has `importantForAccessibility` set to `NO`) so it falls back to this weird TalkBack behavior. It both reads the text from the TextView and announces an OCR announcement - leading to repeating the text.
To fix this we just check if we are going to coopt text and if we do then we do not set `importantForAccessibility`. Behavior here changes a bit. Links are not accessible without having to reference the Text, setting `accessible={true}` on non-referenced `Text` will lead to be focusable.
These are both less bad than what we had before though, so I think this tradeoff is fine.
Changelog: [Internal]
Reviewed By: jorge-cab
Differential Revision: D74101530
fbshipit-source-id: 0678915efdc46a6273f79927b87f22bc9017814a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50997
In some apps, we spend a non-trivial amount of time calling ShadowNode destructors on the UI thread.
A simple way to avoid stalling the UI thread is to move the `baseRevision_` instance to a data structure that is cleared on a background thread, so it's tree of ShadowNode shared_ptrs are released (and in most cases destroyed) on the background thread.
Rather than using std::thread, this change introduces the LowPriorityExecutor abstraction that should be supplied by host platforms. The implementation of this LowPriorityExecutor for each platform is as follows:
- iOS: uses dispatch_async to a low priority dispatch queue
- Android: uses a pthread with SCHED_OTHER and priority = 19
Moving the ShadowTreeRevision into a lambda capture and punting the lambda to the LowPriorityExecutor moves the destructor calls of the ShadowNodes to the host platform implementation of the LowPriorityExecutor.
This change is also guarded by a feature flag so we can keep an eye out for potential memory leaks.
## Changelog
[Internal]
Reviewed By: NickGerleman
Differential Revision: D73688009
fbshipit-source-id: 6a66da248e6fe5c38375bf026499346e8381e75a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51018
`ReactNativeTypes` deep imports `MeasureOnSuccessCallback`, `PublicInstance`, `PublicRootInstance` and `PublicTextInstance`. The `MeasureOnSuccessCallback` type is already root exported, `PublicInstance` is exported as `HostInstance` and there are two types left to export to root import all of them from react-native. This is needed for `simpleResolve` to properly resolve and build types located in `ReactNativePrivateInterface`.
This cannot be fixed on the resolver level because that would also involve change in the `exports` field in `package.json` to enable types resolution for deep paths which should be strict by design.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D73926160
fbshipit-source-id: 3a711a0f002ea42d9ad538c07ec00f22cc4afb6b
