Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57376
AnimatedPropsRegistry::update() runs on the UI thread every animation frame and
created a surface's entry via operator[]. clearOnSurfaceStop() (run on the JS
thread when a surface stops) erases that entry, but an in-flight animation frame
landing after the stop re-created it via operator[] -- and since the surface is
gone, nothing ever cleans it up again. The resurrected entry leaks its
PropsSnapshot and ShadowNodeFamily for the lifetime of the registry.
A surface's entry is legitimately created by getMap(), which
AnimationBackendCommitHook calls on every React commit. stopSurface drains
in-flight commits before unregistering the ShadowTree
(ShadowTreeRegistry::remove takes the registry's unique lock, which excludes the
shared-locked commit visits), so getMap() can never run for a stopped surface.
That leaves update()'s operator[] as the only thing that can resurrect one.
Fix: update() now only refines surfaces that already exist (find instead of
operator[]) and never creates an entry; getMap() remains the sole creator. A
stopped surface can no longer be resurrected, and there is no extra bookkeeping
that could grow over time.
Changelog: [General][Fixed] - Fix a surface-stop race in the C++ Animated shared backend that could permanently leak per-surface animated state
Reviewed By: javache
Differential Revision: D109156094
fbshipit-source-id: 4684ca51d372023e3b082427a225de7d84d14889
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57377
ViewShadowNodeProps was a thin subclass of ViewProps that only forwarded its constructor. After the feature flag propagation logic was removed, the subclass serves no purpose.
Changelog:
[Internal]
Reviewed By: lenaic
Differential Revision: D110095190
fbshipit-source-id: a2555c4ba455e51116c73be3b5c9a71788895ffd
Summary:
Closes https://github.com/react/react-native/issues/45255.
Adds `textAlign: 'start' | 'end'` support for Text and TextInput across the JS types, Android, iOS, and Fabric text conversion paths.
- Android legacy Text and TextInput now accept logical `start`/`end` alignment values.
- Fabric preserves `start`/`end` as distinct `TextAlignment` values and resolves them against layout direction for iOS paragraph layout.
- Existing `left`/`right` behavior is left unchanged to avoid changing current RTL semantics.
This replaces https://github.com/react/react-native/issues/57007 because the original fork became locked and could not be updated after the upstream conflict.
## Changelog:
[GENERAL] [ADDED] - Add support for `textAlign: 'start'` and `textAlign: 'end'`.
Pull Request resolved: https://github.com/react/react-native/pull/57201
Test Plan:
- `yarn build-types`
- `yarn test-typescript`
- `yarn flow-check`
- `./node_modules/.bin/prettier --check packages/react-native/Libraries/Components/TextInput/TextInput.d.ts packages/react-native/Libraries/Components/TextInput/TextInput.flow.js packages/react-native/Libraries/StyleSheet/StyleSheetTypes.d.ts packages/react-native/Libraries/StyleSheet/StyleSheetTypes.js packages/react-native/types/__typetests__/index.tsx packages/react-native/ReactNativeApi.d.ts`
- `./gradlew ktfmtCheck -Preact.internal.useHermesStable=true --no-daemon`
- `./gradlew :packages:react-native:ReactAndroid:testDebugUnitTest --tests com.facebook.react.views.textinput.ReactTextInputPropertyTest.testTextAlign --tests com.facebook.react.views.text.TextAttributePropsTest -Preact.internal.useHermesStable=true --no-daemon`
- `./gradlew ':packages:react-native:ReactAndroid:buildCMakeDebug[arm64-v8a][hermestooling,jsi,etc]' -Preact.internal.useHermesStable=true --no-daemon`
- `git diff --check`
The Android unit test and CMake checks were run from an ASCII-only temporary worktree because Kotlin unit test compilation in my main checkout fails before running these tests when the workspace path contains non-ASCII characters.
Reviewed By: christophpurrer
Differential Revision: D108628602
Pulled By: javache
fbshipit-source-id: 28111d0553451d7de0424a07e956f71bda8787ca
Summary:
Removes the deprecated `animated` prop from `Modal`. It was a no-op everywhere. Use `animationType` instead.
See https://github.com/react/react-native/issues/57384
## Changelog:
[GENERAL] [REMOVED] - Remove deprecated `Modal` `animated` prop
Pull Request resolved: https://github.com/react/react-native/pull/57385
Test Plan:
- `yarn jest packages/react-native/Libraries/Modal`
- `yarn flow` and `tsc` pass with the prop removed from `Modal.js` / `Modal.d.ts`.
Reviewed By: huntie
Differential Revision: D110205204
Pulled By: cortinico
fbshipit-source-id: 8e5b4d7dc8811d7270de3776476e7f868eafddd5
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57367
Places this one folder up, in a location that will be preserved when we later delete the manual `types/` dir. These tests already apply to both the `types/Libraries` dirs and the generated `types_generated/`.
Changelog: [Internal]
___
Differential Revision: D110055787
fbshipit-source-id: 5ff190d301628877c9bda57c92b1af1a2917f1ca
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57346
Restores a deprecated three-argument overload of `RawProps::at()` for backwards compatibility with existing callers (like Nitro modules) that pass prefix/suffix separately.
The new overload concatenates `prefix + name + suffix` when needed and delegates to the parser's `at(string_view)` method. When both prefix and suffix are null, it forwards directly to the single-argument version.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D109837388
fbshipit-source-id: c16188cee163ca786f4530d07475f561a53c51b6
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57310
Add `AppIcon.icon` file (Icon Composer) for macOS 26 Tahoe. Also rename previous `.icns` file for consistency.
`electron/packager` is updated to `^20.0.0` (`.icon` support was added in `18.4.0`).
**Notes**
- This change ensures the Icon Composer source is part of the codebase (following above Electron packager support which came in March).
Changelog:
[General][Changed] - **React Native DevTools**: Add macOS 26/27 app icon
Reviewed By: robhogan
Differential Revision: D97292364
fbshipit-source-id: ba1c34175a95da8c2860142d9db0c4d98d3f6de0
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57348
Follow-up to the `js1 build-cxx-api` rename. Move `build-geo-screenshot-tests`, `build-js-api`, and `build-twui-screenshot-tests` under the `build` group so they sit next to their siblings (`js1 build assets`, `js1 build turbomodule`, etc.) instead of being top-level hyphenated outliers.
Each old top-level command stays as a hidden alias that prints a deprecation notice and delegates to the new module, so existing muscle memory and any out-of-tree scripts keep working.
Also updates the two places that emit the old command names into user-visible output: the TWUI template comment headers, and the JS API snapshot failure message.
Changelog:
[Internal]
Reviewed By: zeyap
Differential Revision: D109844649
fbshipit-source-id: 00623fa8b4d724e16a2dc62d196182c32a9fed64
Summary:
Adds ArrayBuffer support to ObjC TurboModules, following the C++ ArrayBuffer PR ([`226ef2e`](https://github.com/facebook/react-native/commit/226ef2e7c5d1928d5696dc23efc1b8950ba00e37)).
- Codegen support for `ArrayBufferTypeAnnotation` in ObjC module specs (`NSMutableData *` params/returns, new `ArrayBufferKind`)
- JSI↔ObjC conversion wraps native-backed buffers zero-copy via `-[NSMutableData initWithBytesNoCopy:length:deallocator:]`; the deallocator retains the backing store so the bytes stay valid even if the `NSMutableData` escapes the call or the source ArrayBuffer is garbage-collected
- JS-backed buffers are copied, which is safe on both the synchronous and asynchronous paths
This PR is iOS-only; Android support follows in a separate PR.
## Changelog:
[IOS] [ADDED] - Add ArrayBuffer support to ObjC TurboModules
X-link: https://github.com/facebook/react-native/pull/56986
Reviewed By: javache
Differential Revision: D106846249
Pulled By: christophpurrer
fbshipit-source-id: 3393d5d6f31a1412f5d52328c90e51205aa6b153
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57339
Every Props subclass parses its fields in its 3-arg ctor's initializer list, but `Props` was the odd one out — its 3-arg ctor had an empty initializer list and a body that called a separate `Props::initialize` method, which then assigned `nativeId` and (on Android) ran `initializeDynamicProps`.
Fold the `nativeId` parse back into the initializer list and inline the Android `initializeDynamicProps` call into the ctor body, matching the subclass pattern.
This removes the only remaining external caller of `Props::initialize`: `YogaStylableProps`'s ctor was constructing its `Props` subobject via `Props()` and then calling `initialize(...)` from its body. Replace with the standard `Props(ctx, sourceProps, rawProps, filterObjectKeys)` initializer-list chain. With both call sites gone, delete `Props::initialize` outright.
Behaviour is unchanged: the work that `initialize` did still runs on the same construction path, just via the ctor itself.
Changelog:
[Internal]
Reviewed By: christophpurrer
Differential Revision: D109691981
fbshipit-source-id: 835615191332239e90353da2e66fecc429365529
Summary:
X-link: https://github.com/facebook/react-native/pull/55763
RawPropsKey previously stored three `const char*` fields
(prefix, name, suffix) that were concatenated at runtime to form
property names.
This is pretty niche, used to make a few patterns simpler, but also can lead to confusing conflicts when the same property name can be represented in different ways (e.g. T174300106). Iterator style props parsing also completely avoids it.
Lets change the API to a flat name instead.
This change is breaking, but could only find a single user (Nitro module) effected, searching through `react-native-libraries`.
Changelog:
[General][Breaking] - Remove RawPropsKey prefix and suffix
Reviewed By: christophpurrer
Differential Revision: D94367880
fbshipit-source-id: d865725c7be6f880760b6e8d1a567a1b12ac469a
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57308
`private/helloworld` depends on `react-native/core-cli-utils` (it imports `android`, `app`, and `apple` from it to build the app), but that package is no longer published to npm nor to the local Verdaccio proxy that the e2e build installs against. Since `private/helloworld` is excluded from the workspace, it installs standalone, so its `"*"` dependency on `react-native/core-cli-utils` could not resolve and `npm install` failed with `E404`.
Resolve `"*"`-pinned in-repo `react-native/*` dependencies to a local `file:` path in `_prepareHelloWorld()`, so helloworld consumes `core-cli-utils` directly from its in-repo reference implementation regardless of whether it is published. This mirrors how the `react-native` package itself is already wired up for the e2e build.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D109374920
fbshipit-source-id: b6668785387511fa54580ee75e81f13168782797
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57286
We currently have a mix of quote styles in `.yml` files (AI summary below). This applies prettier and reformats everything to single quotes to align with defaults.
Also fixes a couple of cases of over-indentation.
```
Single-quotes only (0 double-quoted scalars):
analyze-pr.yml
— 12 single, 0 double
api-changes.yml
— 3 single, 0 double
check-for-reproducer.yml
— 4 single, 0 double
retry-workflow.yml
— 1 single, 0 double
Single-quote predominant > double:
autorebase.yml 2 vs 1
create-draft-release.yml 8 vs 2
generate-changelog.yml 3 vs 2
on-issue-labeled.yml 7 vs 2
prebuild-ios-core.yml 59 vs 17
prebuild-ios-dependencies.yml 39 vs 1
stale-bot.yml 18 vs 15
test-all.yml 70 vs 27
Double-quote predominant > single:
bump-podfile-lock.yml 1 vs 10
create-release.yml 3 vs 12
e2e-android-rntester.yml 2 vs 6
e2e-android-templateapp.yml 6 vs 13
e2e-ios-rntester.yml 2 vs 7
e2e-ios-templateapp.yml 2 vs 18
fantom-tests.yml 2 vs 7
monitor-new-issues.yml 3 vs 12
publish-npm.yml 42 vs 50
validate-cxx-api-snapshots.yml 2 vs 23
validate-dotslash-artifacts.yml 2 vs 5
Tie / 1-1:
cache-reaper.yml 1 vs 1
close-pr.yml 1 vs 1
needs-attention.yml 2 vs 2
All files contain single quotes somewhere, but only those 4 are single-quote-exclusive. Most CI-heavy workflows — bump, create-release, e2e-, fantom, monitor, publish-npm, validate- — lean double-quoted, while the pr/issue automation, prebuild ios, test-all, and stale-bot lean single-quoted.
```
Changelog: [Internal]
___
Differential Revision: D109151683
fbshipit-source-id: 24391e906c0dd92fe402224089dce8bb2068b4d9
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57274
Fantom could not deterministically fire delayed JS timers: the timer registry it used scheduled timers on a real background thread with real wall-clock delays, so `setTimeout(fn, 100)`/`setInterval` callbacks never fired within a synchronous test. This adds a mockable timer registry and a public Fantom API to control it from JS, similar to `installHighResTimeStampMock`.
- New `Fantom.installTimerMock()` returns a controller with `advanceTimersByTime(ms)`, `runAllTimers()`, `getPendingTimerCount()`, and `uninstall()` (jest fake-timer style). While installed, `setTimeout`/`setInterval` callbacks only fire when the virtual clock is advanced.
- New deterministic `FantomTimerRegistry` (no background thread) keyed off a virtual clock, injected via a new optional `platformTimerRegistryFactory` seam on `ReactInstanceConfig` (the default registry is unchanged for all other consumers).
- `PlatformTimerRegistry` gains a virtual `setTimerManager` (default no-op) so the registry can be wired polymorphically.
- Control flows from JS through new `NativeFantom` methods, the same way the high-res timestamp mock works.
Default (non-mock) behavior is preserved: zero-delay `setTimeout` still fires on the next work loop, and existing tests are unaffected.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D109017304
fbshipit-source-id: 8afe6fb2a39f470ae293038f6592c46535442dc2
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57248
Implement the CDP `Page.addScriptToEvaluateOnNewDocument` and `Page.removeScriptToEvaluateOnNewDocument` methods in the modern JS inspector (`jsinspector-modern`). `Page.addScriptToEvaluateOnNewDocument` registers a JavaScript snippet that is evaluated in every new JS runtime created for the Host (for example, after a reload), before the application's main bundle runs, matching the standard Chrome DevTools Protocol semantics. This is useful for debugger frontends and tooling that need to install instrumentation ahead of application code.
The registered scripts are stored as session state (alongside `Runtime.addBinding` subscriptions in `SessionState`) and replayed onto each new runtime by `RuntimeAgent` via the runtime executor, so they run before any user code and survive reloads. Per CDP semantics the script does not run in the runtime that is current when it is registered; the client triggers `Page.reload` to apply it. `HostAgent` handles both methods, returning the generated script `identifier` from add and removing by `identifier` on remove.
Changelog:
[General][Added] - Implement the `Page.addScriptToEvaluateOnNewDocument` and `Page.removeScriptToEvaluateOnNewDocument` CDP methods in the modern inspector
Reviewed By: hoxyq
Differential Revision: D107084044
fbshipit-source-id: 7951028f81f89fbf36418cf8da8a03a7191d228a
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57226
This removes the experimental `enableImageRequestDowngradingForNonVisibleImages` feature flag and backs out the behavior it gated. When enabled, `ImageShadowNode` downgraded image requests to prefetch priority for images that layout determined did not intersect the viewport — threading an `ImageRequestPriority` through `ImageRequestParams` and the Apple image managers, and propagating per-node viewport frames during Yoga layout via `experimental_layoutOrigin`/`experimental_layoutFrame` on `LayoutContext`.
The flag defaulted to off and was never enabled in a release, and the gated behavior did not deliver the expected improvement, so the feature is removed entirely: `<Image>` once again always requests at immediate priority. This deletes the feature flag, the `ImageRequestPriority` enum and the `ImageRequestParams::priority` field, the priority parameter on `RCTImageManager`/`RCTSyncImageManager`/`RCTImageManagerProtocol`, the `experimental_layout*` `LayoutContext` fields and their Yoga propagation, the iOS request-priority debug overlay, and the associated Fantom test scaffolding. The generated feature-flag sources and the C++ API snapshots are regenerated accordingly.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D108411690
fbshipit-source-id: 1538ec699ed2857f3d3154d666fac43a1dc64cd1
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57213
`StateData` is the placeholder data type for shadow nodes that have no state. It declared `getMapBuffer()` but never defined it, which breaks the build under clang-22.
`ConcreteState<DataT>::getMapBuffer()` calls `getData().getMapBuffer()` only when the `StateDataWithMapBuffer` concept is satisfied, and otherwise returns `MapBufferBuilder::EMPTY()`. Because `StateData` declared `getMapBuffer()`, it satisfied the concept, so `ConcreteState<StateData>::getMapBuffer()` referenced the undefined `StateData::getMapBuffer()`. Whether a class template's virtual members are implicitly instantiated is unspecified ([temp.inst]/11); clang-22 instantiates this override, turning the missing definition into an undefined-symbol link error.
Remove `getMapBuffer()` from `StateData` so the concept is no longer satisfied and the `EMPTY()` fallback is used — the same way `getJNIReference()` is already handled for this placeholder type. `getDynamic()` stays, since `ConcreteState` calls it unconditionally.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D95506209
fbshipit-source-id: 71e767bb19dce5b6097d49654b3701896a783f5b
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57205
## Changelog:
[Internal][Fixed] - Fix EXC_BAD_ACCESS / KERN_INVALID_ADDRESS in C++ Animated when `useSharedAnimatedBackend()` flips across a reused runtime
C++ Animated chose between the legacy and shared-`AnimationBackend` code paths by reading `ReactNativeFeatureFlags::useSharedAnimatedBackend()` live, in many places. That flag is a process-global singleton (`ReactNativeFeatureFlags::accessor_`). On some app the global is reset and re-applied on every user switch (`FBReactModule setUpReactNativeFeatureFlags` -> `dangerouslyReset()`/`override()`), and the previous user's runtime is kept alive and reused. The shared `AnimationBackend` is attached only once, when an instance's `Scheduler` is constructed, gated on the flag at that moment. On a multi-account device the global flag could therefore read true on a reused instance whose backend was never attached, so `getOrCreate` took the shared path and dereferenced a null backend. It also let JS and C++ disagree, since JS caches the flag per runtime while C++ followed the mutated global.
Fix: make the per-instance decision once and use it everywhere instead of the live flag.
- `NativeAnimatedNodesManagerProvider::getOrCreate` selects the path by whether the shared `AnimationBackend` actually exists for this instance (`unstable_getAnimationBackend().lock() != nullptr`).
- `NativeAnimatedNodesManager` stores a `const bool useSharedAnimatedBackend_`, latched in its constructor (true for the shared-backend ctor, false for the legacy ctor), and exposes it via `useSharedAnimatedBackend()`. All internal reads now use the member.
- `PropsAnimatedNode` reads the decision through `manager_->useSharedAnimatedBackend()`.
The attach side (`Scheduler`) is intentionally unchanged: it remains the single construction-time read that latches the per-instance decision the rest of the code now follows. This keeps JS and C++ consistent across global flag flips and removes the null dereference.
Reviewed By: sbuggay
Differential Revision: D108428720
fbshipit-source-id: dff283cd3671866395d1b07b6c9c72e504aecea2
Summary:
X-link: https://github.com/facebook/react-native/pull/57140
`StartupLogger::getInitReactRuntimeEndTime()` was a public getter returning the `initReactRuntimeEndTime` member, but it had no callers. `NativePerformance` (the only consumer of `StartupLogger`) never reads it. This removes the dead getter; the backing member `initReactRuntimeEndTime` is kept because `logStartupEvent`/`reset` still write it.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D108012904
fbshipit-source-id: 56a6710c485a926caf82ecb1cc08e845571b2dd8
Summary:
X-link: https://github.com/facebook/react-native/pull/57142
`StartupLogger::getRunJSBundleEndTime()` was a public getter that returned the `runJSBundleEndTime` member, but it had no callers. `NativePerformance` is the only consumer of `StartupLogger` and reads the start-time getters plus `getAppStartupEndTime`, never this end-time getter. This removes the dead getter. The backing member `runJSBundleEndTime` is kept because `logStartupEvent`/`reset` still write it.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D108012912
fbshipit-source-id: ac6348b8223fba8695843340e99d7e277bf4f60a
Summary:
X-link: https://github.com/facebook/react-native/pull/57137
`RAMBundleRegistry::multipleBundlesRegistry` was a static factory wrapping the public `RAMBundleRegistry` constructor (the one taking a main bundle plus a factory callback), but it had no callers anywhere. Registries are constructed via the public constructor directly. With the sibling `singleBundleRegistry` already removed, this deletes the last orphaned static factory; the constructor and the rest of the class remain intact.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D108012906
fbshipit-source-id: 7bb403ff7660317f0f5b422dca140ac69e048dac
Summary:
X-link: https://github.com/facebook/react-native/pull/57143
`RAMBundleRegistry::singleBundleRegistry` was a static factory that wrapped the public `RAMBundleRegistry` constructor, but it had no callers anywhere. Objects are constructed via the public constructor directly. This removes the orphaned factory; the sibling `multipleBundlesRegistry`, the constructor, `MAIN_BUNDLE_ID`, `registerBundle`, `getModule`, and `getBundle` are all left intact.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D108012903
fbshipit-source-id: 5d8f18ebce2bb19abd124dbb7c9eda60baa0f272
Summary:
X-link: https://github.com/facebook/react-native/pull/57145
`HostTargetController::installPerfIssuesBinding()` was declared in `jsinspector-modern/HostTarget.h` but had no definition anywhere and no callers. (`HostTargetController` is `final`, so the method is not an override.) A declared-but-never-defined non-virtual member cannot be invoked — any call would be a link error — so this is unreachable dead code. The unrelated, live `HostTarget::installPerfIssuesBinding` (a different class) is left intact.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D108012907
fbshipit-source-id: 5c7f14a7956f67e3e884a32f95aa2e50fd0f3ea6
Summary:
X-link: https://github.com/facebook/react-native/pull/57133
`JSIndexedRAMBundle` was a deprecated legacy-architecture class (annotated `[[deprecated("This API will be removed along with the legacy architecture.")]]` and guarded by `#ifndef RCT_REMOVE_LEGACY_ARCH`) for parsing indexed RAM bundles. It was only ever instantiated by `Instance::loadRAMBundleFromString` and `Instance::loadRAMBundleFromFile`, and those two `Instance` methods have no callers anywhere in fbsource: the old Android entry point `CatalystInstanceImpl` that used to call them has been deleted, and the new architecture (`ReactInstance` / bridgeless) routes `loadScriptFromFile` through `loadJSBundleFromFile` in the new runtime, never touching the legacy `Instance`. The only remaining user was its own unit test.
This removes `JSIndexedRAMBundle` and the two dead `Instance` RAM-bundle loaders that referenced it:
- Delete `JSIndexedRAMBundle.cpp`, `JSIndexedRAMBundle.h`, and `JSIndexedRAMBundleTest.cpp`.
- Remove `loadRAMBundleFromString` / `loadRAMBundleFromFile` from `Instance.cpp` / `Instance.h` and drop the now-unused include.
- Drop `JSIndexedRAMBundle.h` from `CXXREACT_PUBLIC_HEADERS` in `cxxreact/BUCK`.
- Update the committed C++ API snapshots accordingly.
The broader legacy RAM-bundle machinery (`RAMBundleRegistry`, `JSModulesUnbundle`, `Instance::loadRAMBundle`, `JSIExecutor::setBundleRegistry`) is left in place; it belongs to the same `RCT_REMOVE_LEGACY_ARCH` legacy bridge and can be removed as a follow-up.
Changelog: [Internal]
Reviewed By: javache, mdvacca
Differential Revision: D108001933
fbshipit-source-id: 4b0f12258e8caff1991847a4bb211e94fbecefa8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/57116
## Changelog:
[General][Breaking] Compile out RuntimeScheduler_Legacy under RCT_REMOVE_LEGACY_ARCH
Guard the legacy RuntimeScheduler implementation behind the `RCT_REMOVE_LEGACY_ARCH` macro instead of deleting it. `RuntimeScheduler_Legacy.h`/`.cpp` remain in the tree, but their contents — along with the feature-flag-based selection between the legacy and modern schedulers in `RuntimeScheduler.cpp`, `NativeMutationObserver.cpp`, and `Task.h` — are wrapped in `#ifndef RCT_REMOVE_LEGACY_ARCH`. When the macro is defined, the legacy code is compiled out and `RuntimeScheduler` unconditionally instantiates `RuntimeScheduler_Modern`; when it is not defined, behavior is unchanged.
The C++ API snapshots are updated to drop the `RuntimeScheduler_Legacy` symbols from the new-arch surface, and the parameterized scheduler test (`RuntimeSchedulerTest`) only runs the modern configuration when the legacy arch is compiled out.
Reviewed By: rubennorte
Differential Revision: D107777881
fbshipit-source-id: 2b50711ab3af182edc45a87fd232d96a0f879837
Summary:
This makes the shell to use escape interpretation by setting `echo -e "..."`. For zsh shell, this often works out of the box. For other shells like bash, we may need to set it explicitly.
## Changelog:
<!-- 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
-->
[INTERNAL] [FIXED] - allow escape interpretation for shells
Pull Request resolved: https://github.com/facebook/react-native/pull/57114
Test Plan:
- CI Passes
- Verified Locally on template app
https://github.com/user-attachments/assets/4c8c6bf7-1cf2-4bd8-b094-651c44578ae0
Reviewed By: cipolleschi
Differential Revision: D107904889
Pulled By: cortinico
fbshipit-source-id: 2222f589ecc149a82d5067e0a2198b9c1a17ffcb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/57103
Changelog: [General][Fixed] Fixed `display: contents` nodes having `hasNewLayout` set incorrectly
`cleanupContentsNodesRecursively` unconditionally sets `hasNewLayout=true` on `display: contents` children, including on code paths where their parent's layout was not actually performed in this pass. The stale flag can survive across layout passes and, in clone-on-write renderers (e.g. React Native Fabric), be observed by a subsequent pass whose parent was cloned but whose layout was served from cache, leaving the contents child's owner pointing at the previous parent revision.
There are two paths through which the cleanup could stamp a contents child whose parent's `hasNewLayout` would end up false:
1. Measure-phase visit. Inside `calculateLayoutImpl`, the cleanup ran with no knowledge of `performLayout`. When the parent's `calculateLayoutImpl` was invoked only with `performLayout=false` (cache miss on measure, cache hit on layout), the cleanup stamped contents children even though the parent itself never had its `hasNewLayout` set.
2. Absolute-layout walk. `layoutAbsoluteDescendants` walks every static layout descendant of the containing block - including ones whose own `calculateLayoutImpl` was skipped via the layout-phase cache. The cleanup invoked along that walk unconditionally stamped contents children, but the parent's `hasNewLayout` was only updated when the recursion actually found new layout downstream.
In both cases, the result is the same invariant violation: a contents node with `hasNewLayout=true` whose parent has `hasNewLayout=false`. A consumer iterating the tree via `hasNewLayout` skips the parent and never clears the stale flag.
X-link: https://github.com/facebook/yoga/pull/1970
Test Plan:
Added `YGContentsNodeHasNewLayoutTest.cpp` with regression tests:
- `contents_child_hasNewLayout_not_stamped_on_measure_only_visit` - pins the measure-phase fix
- `absolute_descendant_through_contents_is_reachable_via_hasNewLayout` - pins the positive case for absolute-layout path
- `absolute_phase_cleanup_does_not_stamp_when_parent_layout_skipped` - pins the negative case for absolute-layout path
Reviewed By: javache
Differential Revision: D107854528
Pulled By: j-piasecki
fbshipit-source-id: cae5e889622296e8b6380a6428509b5ffea3e9ae
Summary:
This fixes the failing CI jobs on main for `template` testing. The job fails as they echo `react.internal.mavenLocalRepo=...` to the `gradle.properties` of template test project. As a result of which the `gradle.properties` look like below:
```properties
android.builtInKotlin=false
android.newDsl=falsereact.internal.mavenLocalRepo=...
```
To fix it we add a line break in the `echo` command.
## Changelog:
<!-- 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
-->
[INTERNAL] [FIXED] - add line break to gradle.properties for template testing
Pull Request resolved: https://github.com/facebook/react-native/pull/57107
Test Plan:
- CI Passing
- Verified Locally
Reviewed By: cortinico
Differential Revision: D107880136
Pulled By: cipolleschi
fbshipit-source-id: 81cf2fe53c1c2285f79db538aa5aa3cb745f796d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/57040
The split between `logTaggedMarkerImpl` and `logTaggedMarkerBridgelessImpl` no longer earns its keep — bridgeless callers always pass the same instance key, and the bridge mode is on its way out. Collapse the two paths into a single hook so platform code only has to wire up one slot.
`LogTaggedMarkerBridgeless` becomes a type alias for `LogTaggedMarker`. The free `logMarkerBridgeless` / `logTaggedMarkerBridgeless` functions stay around as `[[deprecated]]` shims that forward to the unified path, but the `logTaggedMarkerBridgelessImpl` registration slot is removed entirely — external writers should assign to `logTaggedMarkerImpl` instead. Call-sites in `ReactInstance` switch to the unified `logMarker` / `logTaggedMarker`. On the Android side, `logPerfMarkerBridgeless` and the `logPerfMarkerWithInstanceKey` indirection go away — there's only one instance key now.
`logTaggedMarkerImpl` is also reshaped into a small `AtomicLogTaggedMarker` wrapper so reads and writes synchronize internally and callers no longer need to lock around it; the standalone `logTaggedMarkerImplMutex` goes away.
Changelog:
[General][Breaking] - Remove `logTaggedMarkerBridgelessImpl`; assign callbacks to `logTaggedMarkerImpl` instead
[General][Deprecated] - Deprecate `logMarkerBridgeless` and `logTaggedMarkerBridgeless` in favor of `logMarker` and `logTaggedMarker`
Reviewed By: mdvacca
Differential Revision: D88068665
fbshipit-source-id: b9ae3baddf6ecccd5bc8c4ad2a341edbae107e42
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/57083
In bridgeless mode, `RCTInstance` records native startup timings in a per-instance `RCTPerformanceLogger`, but that logger was never reachable from app code: `RCTBridgeProxy.performanceLogger` returned nil and `RCTJavaScriptDidLoadNotification` was never posted. Startup-perf consumers that follow the long-standing pattern of reading `[bridge performanceLogger]` on `RCTJavaScriptDidLoadNotification` were therefore silently inert under bridgeless, dropping all native startup timings.
This restores that pattern for bridgeless:
- `RCTBridgeProxy` now holds a real `performanceLogger` property, injected by `RCTInstance`, instead of returning nil.
- `RCTInstance` posts `RCTJavaScriptDidLoadNotification` (on the main thread, with the bridge proxy in `userInfo[@"bridge"]`) once the JS bundle has loaded, mirroring the legacy bridge.
No change to the legacy bridge path.
Changelog:
[iOS][Fixed] - Expose the bridgeless performance logger via `RCTBridgeProxy` and post `RCTJavaScriptDidLoadNotification`, so native startup-perf consumers work in bridgeless
Reviewed By: christophpurrer
Differential Revision: D107542363
fbshipit-source-id: e1b539dfec9e337c5d32c2f8d720e04e795dc538
Summary:
`textDecorationStyle` is declared on `TextStyleAndroid` in the public types but `TA_KEY_TEXT_DECORATION_STYLE` was a no-op handler: every value silently rendered as a solid line, and `wavy` was additionally rejected at the Fabric C++ enum boundary with an `Unsupported value` log. This PR wires the prop through the existing C++ → Kotlin pipeline and implements `solid`, `double`, `dotted`, `dashed`, and `wavy` for both underlines and strikethroughs.
Android's `Layout.draw` paints the underline produced by `setUnderlineText(true)` using `paint.color` only and offers no native way to draw a dotted / dashed / wavy decoration. `ReactUnderlineSpan` and `ReactStrikethroughSpan` now extend `CanvasEffectSpan` and paint the decoration themselves in `onDraw` via `Canvas.drawLine` / `Canvas.drawPath`, dispatching by style. As a side effect this also makes `textDecorationColor` reach the paint, closing the separate long-standing gap filed as https://github.com/facebook/react-native/issues/4579 in 2015 — the companion color-focused PR https://github.com/facebook/react-native/issues/56767 isolates that fix for reviewers who only want the color change.
`TextDecorationStyle::Wavy` is added to the Fabric C++ primitives / conversions so the `wavy` JS value flows through; the same enum is shared with iOS (see companion iOS PR https://github.com/facebook/react-native/issues/56769).
The wavy curve uses Chromium/Blink's formula from `decoration_line_painter.cc` (`wavelength = 1 + 2 * round(2 * thickness + 0.5)`, `controlPointDistance = 0.5 + round(3 * thickness + 0.5)`, one cubic Bezier per wavelength with both control points at the midpoint, one above and one below the y-axis). The minimum stroke thickness is density-aware (1.5 dp) so decorations read consistently across display densities. The drawing loop iterates `while x < x2` so the final cycle continues through the last character (including trailing punctuation that would otherwise be visually uncovered when the run width is not an integer multiple of the wavelength).
`ReactTextView.onDraw` invokes `CanvasEffectSpan.onDraw` after `super.onDraw`, mirroring what `PreparedLayoutTextView.onDraw` already did. Without this, the new spans have no effect on the older view class, which is what some Text components on the new architecture still route through.
Companion PRs (independent, also targeting `main`):
- https://github.com/facebook/react-native/issues/56767 — fix(android): textDecorationColor on underlines + strikethroughs. Resolves https://github.com/facebook/react-native/issues/4579.
- https://github.com/facebook/react-native/issues/56769 — feat(ios): textDecorationStyle wavy/dotted/dashed via custom CG paths. Shares the `TextDecorationStyle::Wavy` enum addition; whichever lands first leaves the other with a trivial conflict to resolve.
## Changelog:
[GENERAL] [ADDED] - `textDecorationStyle: 'wavy'` for `<Text>` (see corresponding iOS PR for the iOS counterpart)
[ANDROID] [ADDED] - Text decorations honor `textDecorationStyle` (`solid`, `double`, `dotted`, `dashed`, `wavy`)
Pull Request resolved: https://github.com/facebook/react-native/pull/56768
Test Plan:
Rendered `<Text>` components with `textDecorationLine` set to `"underline"` or `"line-through"` and `textDecorationStyle` cycling through `solid` / `double` / `dotted` / `dashed` / `wavy`. On stock 0.85.2 every value renders as a solid line and `wavy` logs an `Unsupported value` warning; with this patch each style renders with the requested stroke geometry. Verified single-line and wrapped multi-line cases on an Android API 36 emulator: each visual line within a wrapped block receives its own correctly-styled decoration that starts and ends at the line's content boundaries.
```tsx
<Text style={{
color: 'black',
textDecorationLine: 'underline',
textDecorationStyle: 'wavy',
}}>
Hello
</Text>
```
Unit tests added for `TextDecorationStyle.fromString()` covering all five styles plus null, empty, and unknown inputs. Run with `buck2 test //xplat/js/react-native-github/packages/react-native/ReactAndroid/src/test/java/com/facebook/react/views:views_text_TextDecorationStyleTestAndroid` — all 8 tests pass.
Fantom integration tests added to `Text-itest.js` verifying all five `textDecorationStyle` values propagate through the Fabric pipeline for both underline, strikethrough, and multi-line wrapped text.
Installed RNTester on a Pixel 8 Pro (Android API 36) and verified all five `textDecorationStyle` values render correctly for both underline and line-through decorations, including multi-line text with inline decoration spanning line breaks. Screenshot: https://pxl.cl/b3c4f
jest-e2e screenshot test updated with new Android screenshot hashes reflecting the updated decoration rendering.
Reviewed By: javache
Differential Revision: D104680895
Pulled By: cortinico
fbshipit-source-id: 7d057326af3809869fdd8394d51aa50ff328ed6f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/57067
Removes `RCTBridge`-related functions from `RCTReactNativeFactory` protocol and default delegate implementation as part of cleaning up legacy architecture APIs.
Removes `createBridgeWithDelegate:launchOptions:`, `createRootViewWithBridge:moduleName:initProps:`, and the `bridge` property. The `bridgeAdapter` property is preserved as it returns `RCTSurfacePresenterBridgeAdapter`, not `RCTBridge`. Updates documentation in `RCTAppDelegate.h` to reflect the removed overridable methods.
## Changelog:
[iOS][Breaking] Remove RCTBridge Functions from RCTReactNativeFactory Header
Reviewed By: andrewdacenko
Differential Revision: D107417684
fbshipit-source-id: 2f6f66a49502250c15c5c62d9abbbdfe10884d55
Summary:
X-link: https://github.com/facebook/hermes/pull/2037
Pull Request resolved: https://github.com/facebook/react-native/pull/57005
Promote `IEventLoopControl` and `ISetEventLoopControl` out of `JSI_UNSTABLE` and make `HermesRuntimeImpl` always implement the setter interface. Keep unrelated unstable APIs such as serialization, tracing helpers, and Worker installation behind `JSI_UNSTABLE`.
Other hermes branches do not implement `ISetEventLoopControl`, for now.
Changelog: [Internal]
Reviewed By: tmikov
Differential Revision: D106744174
fbshipit-source-id: 0cf88de7c067f091b19238fce7171300b9777c98
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/57065
## Changelog:
[iOS][Breaking] Remove unused bridge-based RCTTurboModuleManager initializer
`RCTTurboModuleManager` declared three initializers, but only the bridgeless (`RCTBridgeProxy`-based) ones are used. The bridge-based `initWithBridge:delegate:jsInvoker:` initializer was the only path that ever set a non-nil bridge, leaving a large amount of bridge-only code permanently dead under the surviving initializers.
This removes that initializer along with the now-dead bridge-mode code: the `_bridge` ivar, the `decorateNativeMethodCallInvoker:` decoration, the `RCTModuleData`/`registerModuleForFrameUpdates:` registration, the `performanceLogger` setup markers, and the bridge invalidation notification observers and handlers. `initWithBridgeProxy:bridgeModuleDecorator:delegate:jsInvoker:devMenuConfigurationDecorator:` becomes the designated initializer, and the shorter `RCTBridgeProxy` initializer now forwards to it. The `RCTDidInitializeModuleNotification` post is preserved with a nil bridge, matching the existing runtime behaviour of the bridgeless initializers.
Reviewed By: philIip
Differential Revision: D107409088
fbshipit-source-id: 81022c5e864d3d0897170eea000f4c29d8fe3529
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/57057
X-link: https://github.com/facebook/yoga/pull/1968
Re-land of D105720159, originally reverted (revert: 0e642b96c7e2) due to a latent NPE in `ReactProgressBarViewManager.kt` and Instagram-internal `ReactSwitchManager.kt` — both fixed in the prior diffs in this stack. Crash and broken e2e tests reported in T273821098 / P2359486686.
This re-land additionally fixes a correctness gap in the original D105720159 design: it claimed "Default configs carry the bit (preserves today's behaviour); existing trees see no change" — but `LayoutConformance::Strict` in `YogaLayoutableShadowNode::resolveErrata` returned `YGErrataNone`, which clears every errata bit *including* the new `MinSizeUndefinedInsteadOfAuto` (bit 8). Since `react-strict-dom` sets `experimental_layoutConformance="strict"` on every native View, this implicitly opts every RSD-using surface into the new auto-min probe. That's the exact path Airwave's tests took to hit the original NPE.
Change: `LayoutConformance::Strict` now returns `YGErrataMinSizeUndefinedInsteadOfAuto` instead of `YGErrataNone`. Strict mode keeps every other CSS conformance behavior intact; only the new auto-min feature stays opt-in via explicit `YGConfig` setup. This matches the design pattern Litho uses in the child diff (`ComponentsConfiguration.useAutoMinSize` flag, gated independently of any strict-mode plumbing).
Original summary follows:
X-link: https://github.com/facebook/yoga/pull/1966
Pull Request resolved: https://github.com/facebook/react-native/pull/57015
Implements CSS Flexbox §4.5 automatic minimum sizing in Yoga. When opted in on a `YGConfig`, every flex item whose main-axis `min-{width,height}` is undefined receives a content-derived floor — `min(min-content, specified-size, max-size)` plus any aspect-ratio-transferred lower bound — so it cannot shrink below the size CSS browsers would honor.
How to opt in: clear the new `YGErrataMinSizeUndefinedInsteadOfAuto` errata bit on the config. Default configs carry the bit (preserves today's behaviour); existing trees see no change. The bit is added to `YGErrataClassic` so consumers using that constant continue to get the same default. **`LayoutConformance::Strict` also keeps the bit set** — the new feature is strictly opt-in, not inferred from strict-mode CSS conformance.
See D105720159 for full details on precedence rules, container recursion semantics, and per-item opt-outs.
Changelog:
[General][Added] - Add CSS Flexbox §4.5 automatic minimum sizing. Opt in by clearing the new `YGErrataMinSizeUndefinedInsteadOfAuto` errata bit on `YGConfig`.
Reviewed By: javache, aashay-gaikwad
Differential Revision: D107183851
fbshipit-source-id: 451b86347e24da5504649ba575fb27ae0d2f9853
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/57034
With D107165685, it should work this time.
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D107111468
fbshipit-source-id: 326b2911088d7c87c3564a578125eeaab9d0b8cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/57028
Mark `ReactNativeElement` and `ReadOnlyNode` as non-user-constructible in the generated TypeScript definitions by emitting `protected constructor()`.
**Motivation**
- Correctness — like web DOM elements (`HTMLElement`, etc.), `ReactNativeElement` instances are created by the React Native runtime, not in user space. See also D107227212.
- Reduce public API surface (in particular, since this is also aliased to the `HostInstance` type).
**Changes**
- Adds a new `build-types protected-constructor` directive and corresponding `build-types` post-transform.
- Applies directive to `ReactNativeElement` and `ReadOnlyNode`.
- Also extracts shared `build-types` directive helpers into `transforms/typescript/utils/buildDirectives.js`.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D107119545
fbshipit-source-id: 8320780db12475b00910745d4b8cee8c9f22d547
Summary:
X-link: https://github.com/facebook/yoga/pull/1966
Pull Request resolved: https://github.com/facebook/react-native/pull/57015
Implements CSS Flexbox §4.5 automatic minimum sizing in Yoga. When opted in on a `YGConfig`, every flex item whose main-axis `min-{width,height}` is undefined receives a content-derived floor — `min(min-content, specified-size, max-size)` plus any aspect-ratio-transferred lower bound — so it cannot shrink below the size CSS browsers would honor.
How to opt in: clear the new `YGErrataMinSizeUndefinedInsteadOfAuto` errata bit on the config. Default configs carry the bit (preserves today's behaviour); existing trees see no change. The bit is added to `YGErrataClassic` so consumers using that constant continue to get the same default.
Three ways for a node to declare its min-content size along an axis, in this precedence order:
1. **Static per-axis value** via `YGNodeSetMinContentWidth/Height(node, value)`. Pass `YGUndefined` to clear. When set, the §4.5 probe short-circuits at this node — skipping both the dynamic callback and any container recursion. Use for known constants (e.g., images returning 0 per CSS-Images; scroll containers returning 0 on their scroll axis).
2. **Dynamic callback** via `YGNodeSetMinContentMeasureFunc(node, fn)`. Mirrors `YGMeasureFunc`'s shape. The algorithm invokes it for measure-func leaves when no static value is set.
3. **Default fallback**: the existing `YGMeasureFunc` invoked with `AtMost 0`, which text measurers naturally answer with their longest-word width.
For container nodes without a static value, the algorithm walks children directly — sum on the container's own main axis, max on the cross axis — mirroring RenderCore FlexLayout's `computeMinContentSize`. This replaces the previous `calculateLayoutInternal(performLayout=false)` re-entry and skips cross-axis sizing, padding/border resolution, alignment, and baseline machinery that the probe doesn't need.
Per-item opt-outs follow the CSS spec: explicit `min-{width,height}` (including 0), `display: none`, and `overflow != visible`.
Cost when off (default): a single errata-bit check per flex line plus one `FloatOptional` short-circuit per `boundAxisWithAutoMin` call. Sub-microsecond.
Cost when on: one min-content probe per opted-in flex item per layout pass. Static values short-circuit in ~30 ns; measure-func leaves cost one extra `measure()` call; container subtrees do one recursive sum/max walk over in-flow descendants.
Reference: https://www.w3.org/TR/css-flexbox-1/#min-size-auto. Modeled after `xplat/flexlayout/`'s `MinSizeUndefinedInsteadOfAuto` errata path.
Changelog:
[General][Added] - Add CSS Flexbox §4.5 automatic minimum sizing. Opt in by clearing the new `YGErrataMinSizeUndefinedInsteadOfAuto` errata bit on `YGConfig`. Adds `YGNodeSetMinContentWidth/Height` for static contributions and `YGMinContentMeasureFunc` for dynamic ones.'
GH pull request
https://github.com/facebook/react-native/pull/57015https://github.com/facebook/yoga/pull/1966
Reviewed By: fbcbl
Differential Revision: D105720159
fbshipit-source-id: 57a14408b10535fd84623b4d99ae9b5fba7b35ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56877
## Changelog:
[Internal] [Changed] - Revisit timing to capture old/new nodes
Previously, when `applyViewTransitionName` is called from react reconciler, if there is active viewtransition, we decide it's applying to new node. This was incorrect because `applyViewTransitionName(old)` for next transition can be called when the previous transition is still ongoing. In fact `applyViewTransitionName(old)` is guaranteed to be called before mutationCallback in a transition while `applyViewTransitionName(new)` is inside mutationCallback. So that is a better criteria to separate old and new cases. Given mutationCallback is synchronous on JS thread we can just use a boolean flag to tell the timing.
Given this interleaved situation, when we clean up resources (for new/old nodes) of a transition at its end, we should also avoid removing those for a pending transition. Introducing transitionId for this case.
Reviewed By: Abbondanzo
Differential Revision: D105214322
fbshipit-source-id: 6c719964921db2e76421e9917151076c97d1d623
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56998
Reverts the recent Flow syntax codemods applied across `packages/`, `private/`, and `scripts/` in react-native-github. Specifically restores the previous form for:
- `+T` / `+Instance` style variance annotations on generic type parameters that had been converted to the newer `out T` / `in T` keyword form.
- `+field:` covariant object/interface properties that had been converted to the `readonly field:` modifier form.
- `+[K in keyof T]:` mapped-type covariance that had been converted to `readonly [K in keyof T]:`.
These are purely Flow type-annotation changes with no runtime behavior impact, restoring the form that the rest of the toolchain (in particular Fantom) already supports.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D106813102
fbshipit-source-id: 6bf915d530e130eba9c9d96a2b6c3dc8853594d1
Summary:
Remove duplicated words from comments in a release script, a dev middleware test helper, the Gradle plugin JDK utility, and the virtual view render state.
## Changelog:
[INTERNAL] [FIXED] - Fix duplicated words in source comments.
Pull Request resolved: https://github.com/facebook/react-native/pull/56985
Test Plan: Comments.
Reviewed By: cortinico
Differential Revision: D106615714
Pulled By: fabriziocucci
fbshipit-source-id: cbb08abc5c0e6fbcfe2299c00aa05e67901b9f4c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56976
changelog: [internal]
Use Fabric layout data to classify image shadow nodes as visible or offscreen on Apple platforms. Offscreen image requests now use `ImageRequestPriority::Prefetch`, which is bridged to the existing `RCTImageLoaderPriorityPrefetch` API, while visible images stay at `Immediate`. The new React Native feature flag defaults to `false` until app-specific gating wires it up.
Reviewed By: javache
Differential Revision: D106074485
fbshipit-source-id: 80ece75cf0d639be1fdbfdd5f19b838b7b64aba6
Bartlomiej Bloniarz