)

Summary:
Pull Request resolved: #57416

Moves the native component specs out of the legacy `specs_DEPRECATED/components` directory and into a `specs/` folder colocated with the component they belong to, under `src/private/components/<component-name>/specs/`. The directory name for each component is its public name, lowercased and without spaces (e.g. `DrawerLayoutAndroid` -> `drawerlayoutandroid`, `RefreshControl` -> `refreshcontrol`).

This continues the effort described in the `specs_DEPRECATED` README of gradually moving specs out of that directory until it can be removed. Specs shared by the same public component are grouped together (e.g. `AndroidSwitchNativeComponent` and `SwitchNativeComponent` under `switch/specs`, `AndroidSwipeRefreshLayoutNativeComponent` and `PullToRefreshViewNativeComponent` under `refreshcontrol/specs`).

Relative imports inside each moved spec were updated for the new depth, and every consumer (the re-export shims under `Libraries` plus the colocated `scrollview` and `safeareaview` consumers) now points at the new location. Public import paths are unchanged because the `Libraries` re-export shims are preserved. Codegen still discovers the specs since it scans the whole `src` directory.

Changelog: [Internal]

___

Reviewed By: huntie

Differential Revision: D110472967

fbshipit-source-id: bb56a957f3a7d5169cb49ebe889dc226459d99ab

Summary:
Pull Request resolved: #57407

Add the generated React Native feature flag plumbing for `enableIOSCompressedTextFrameAdjustment`. The flag gates an iOS `Text` rendering adjustment that expands and recenters compressed explicit `lineHeight` drawing when font glyph bounds exceed the drawing frame.

Changelog:
[iOS][Added] - Add `enableIOSCompressedTextFrameAdjustment` feature flag for `Text` rendering adjustments.

Differential Revision: D110430299

fbshipit-source-id: f7df2e0ea3ad73b80f8a3ed41ef2b990ea25b727

Summary:
Pull Request resolved: #57408

Gate the iOS compressed text adjustment behind a runtime gate, expand the paragraph text drawing frame when compressed glyph bounds exceed the view bounds, and center glyph drawing for explicit line heights shorter than the font metrics.

Changelog: [Internal]

Reviewed By: javache

Differential Revision: D110430304

fbshipit-source-id: 946942a20a286735001ac1e49089e30660ebf7e9

Summary:
Pull Request resolved: #57405

The `image-blur-prefetch` and `image-wide-gamut` Maestro flows under `packages/rn-tester/.maestro/` were added recently and are too flaky on the iOS E2E job (`test_e2e_ios_rntester`), repeatedly failing builds in the React Native OSS repo. Both rely on `assertScreenshot` color/blur comparisons that don't reproduce reliably on the iOS simulator in CI.

This wraps each flow in a `runFlow: when: platform: Android` guard and adds the `android-only` tag, matching the existing pattern used by `image-progressive-jpeg.yml` and `image-getsize-local-drawables.yml`. On iOS the wrapped `runFlow` is skipped, leaving an empty (passing) flow; on Android the flow runs in full, so Android coverage is unchanged.

The long-standing `image.yml` flow (cross-platform test case in place since 2024) is intentionally left untouched and continues to run on iOS.

Changelog: [Internal]

Reviewed By: zeyap

Differential Revision: D110372082

fbshipit-source-id: 8a33c32dff94017cb1706ce706876101d7a109a2

Summary:
Pull Request resolved: #57359

Adds two new MapBuffer entry types, `IntBuffer` and `DoubleBuffer`, for storing homogeneous arrays of ints and doubles compactly in the dynamic data section. Unlike `Map` / map lists, these carry no per-element key/type overhead: a batch of N values costs ~N*elementSize bytes plus a single 4-byte count prefix instead of N 12-byte buckets. The bucket value holds the offset of the array within the dynamic data section.

Covers the full surface: the C++ reader (`MapBuffer::getIntBuffer` / `getDoubleBuffer`), the C++ builder (`MapBufferBuilder::putIntBuffer` / `putDoubleBuffer`), and the Kotlin reader API (`MapBuffer.getIntBuffer` / `getDoubleBuffer`, `Entry.intBufferValue` / `doubleBufferValue`). The `DataType` enum gains `IntBuffer = 6` and `DoubleBuffer = 7`, kept in sync across C++ and Kotlin.

Changelog:
[General][Added] - Add `IntBuffer` and `DoubleBuffer` entry types to MapBuffer for compact homogeneous int/double arrays

landed-with-radar-review

Reviewed By: zeyap

Differential Revision: D109848476

fbshipit-source-id: f9e86b7c094dea796d9a8b725e53eb948c1390ca

Summary:
Pull Request resolved: #57360

Introduces a dedicated `MapBufferList` `DataType` for an ordered array of nested MapBuffers, instead of overloading the `Map` type for lists. This makes a list of MapBuffers self-describing and distinguishable from a single nested `Map` (they were byte-distinct in payload but previously shared the `Map` type tag). Updates the C++ builder (`putMapBufferList`), the Kotlin `MapBuffer` interface, `ReadableMapBuffer`, and `WritableMapBuffer`, and adds cross-language JNI round-trip coverage in the serialization instrumentation test.

Changelog:
[Android][Added] - Add a dedicated `MapBufferList` type to `MapBuffer` for ordered lists of nested `MapBuffer`s

landed-with-radar-review

Reviewed By: zeyap

Differential Revision: D109848477

fbshipit-source-id: 7f590d5999d0cc4ee2d9d28cc34ae9220e442e18

Summary:
Pull Request resolved: #57361

Broadens the former header-shrink change into a single representation-optimization commit for MapBuffer. It bundles three layout optimizations that were previously split: (1) the header is reduced to a single 2-byte `count` field; (2) multi-byte values are read via `memcpy` so unaligned access is well-defined on all platforms; (3) every dynamic-data entry (`String`, `Map`, `MapBufferList`, `IntBuffer`, `DoubleBuffer`) packs its `[offset][byteLength]` into the bucket's 8-byte value instead of writing an in-band length prefix into the dynamic data section.

Net effect: 4 fewer bytes per dynamic entry, one fewer indirection on read (the length is already in the bucket), and every dynamic entry becomes self-delimiting from its bucket alone. No public API change — only the internal serialized representation.

Changelog: [Internal]

landed-with-radar-review

Reviewed By: lenaic, zeyap

Differential Revision: D109848478

fbshipit-source-id: 30749aaa1c2d9fc9b1f8684a3b67815ef44632e8

Summary:
Deprecates `ImageBackground` as part of the effort to keep core lean. It is a thin wrapper around a `View` and an `Image`, and can easily be replaced by composing a `View` with an absolutely positioned `Image` and layering children on top:

```tsx
import type { ReactNode, Ref } from "react";
import {
  Image,
  StyleSheet,
  View,
  type ImageProps,
  type ViewProps,
} from "react-native";

type ImageBackgroundProps = Omit<ImageProps, "style"> & {
  children?: ReactNode;
  ref?: Ref<View>;
  style?: ViewProps["style"];
};

export const ImageBackground = ({
  children,
  importantForAccessibility,
  ref,
  style,
  ...props
}: ImageBackgroundProps) => {
  const { height, width } = StyleSheet.flatten(style);

  return (
    <View
      ref={ref}
      accessibilityIgnoresInvertColors={true}
      importantForAccessibility={importantForAccessibility}
      style={style}
    >
      <Image
        {...props}
        importantForAccessibility={importantForAccessibility}
        style={[StyleSheet.absoluteFill, { height, width }]}
      />
      {children}
    </View>
  );
};
```

## Changelog:

[GENERAL] [DEPRECATED] - Deprecate `ImageBackground`, use a `View` with an absolutely positioned `Image` instead

Pull Request resolved: #57412

Test Plan:
- `deprecated` shows a strikethrough on `ImageBackground` in editors.
- Importing/rendering `ImageBackground` logs the deprecation warning once.

Reviewed By: javache

Differential Revision: D110484567

Pulled By: cortinico

fbshipit-source-id: 0f70893a0680b9bb34e1442bfef41e9210c08d07

Summary:
Pull Request resolved: #57424

With commit branching (enableFabricCommitBranching), commits from React land on
a separate revision (currentReactRevision_) that is later merged into the main
tree. React-branch revisions are numbered off the main revision, so two React
commits that occur before the main revision advances get the SAME revision
number.

mergeReactRevision decided whether to clear currentReactRevision_ by comparing
revision *numbers*. When a newer React revision landed before the merge of the
previous one completed, its coincidentally-equal number caused it to be cleared,
silently dropping a pending update. It also cleared the revision even when the
merge commit did not succeed.

Fix:
- Clear currentReactRevision_ by comparing root shadow node identity instead of
  the revision number, and only when the merge commit actually succeeded.
- Compute the React-branch revision number from the snapshot taken under the
  shared lock instead of reading currentRevision_ without the (deferred) unique
  lock.

Changelog: [General][Fixed] Fixed potential revision drop during merge

Reviewed By: rubennorte

Differential Revision: D110577969

fbshipit-source-id: b3f1f5aad8b3783e5080fde851571b62ceceaf94

…detached (#57423)

Summary:
On Android 9 and below (`SDK_INT <= P`) in touch mode, `ReactEditText.clearFocusAndMaybeRefocus()` unconditionally casts `rootView` to `ViewGroup`:

```kotlin
val rootViewGroup = rootView as ViewGroup
```

`View.getRootView()` returns the view **itself** when the view is detached from the window. An IME editor action is delivered asynchronously over Binder (`IInputConnectionWrapper`), so a submit-key press can arrive after the EditText has already been removed from the hierarchy (screen unmount/navigation racing the keyboard). When that happens the cast throws and kills the app:

```
java.lang.ClassCastException: com.facebook.react.views.textinput.ReactEditText cannot be cast to android.view.ViewGroup
  at com.facebook.react.views.textinput.ReactEditText.clearFocusAndMaybeRefocus (ReactEditText.kt:379)
  at com.facebook.react.views.textinput.ReactTextInputManager.addEventEmitters$lambda$3 (ReactTextInputManager.kt:933)
  at android.widget.TextView.onEditorAction (TextView.java:6615)
  at com.android.internal.widget.EditableInputConnection.performEditorAction (EditableInputConnection.java:138)
  at android.view.inputmethod.InputConnectionWrapper.performEditorAction (InputConnectionWrapper.java:190)
  at com.android.internal.view.IInputConnectionWrapper.executeMessage (IInputConnectionWrapper.java:360)
```

We see this steadily in production Crashlytics (RN 0.86, New Architecture): all events are on Android 7–9 devices (Samsung SM-J710GN / SM-G610F on 8.1.0, etc.), zero on Android 10+, because API > 28 takes the plain `super.clearFocus()` branch and never reaches the cast.

This change replaces the unchecked cast with a safe cast and falls back to a plain `clearFocus()` when the root is not a `ViewGroup`. That fallback is correct because the only reason the root isn't a `ViewGroup` is that the view is already detached — there is no surviving focus hierarchy to protect with the `descendantFocusability` workaround, and `hideSoftKeyboard()` still runs afterwards.

Behavior is unchanged on API > 28, in non-touch mode, and in the normal attached case on old Android.

## Changelog:

[ANDROID] [FIXED] - Fix ClassCastException crash on Android 9 and below when an IME submit action races the unmount of a TextInput

Pull Request resolved: #57423

Test Plan:
The race is timing-dependent, so it is exercised by the scenario rather than a unit test:

1. On an API 26–28 emulator/device, render a single-line `<TextInput>` with default `submitBehavior` (`blurAndSubmit`), focused, keyboard open.
2. Unmount the input (conditional render / navigation) in the same frame as pressing the keyboard's submit key. The IME action arrives over Binder after the view is detached.
3. Before this change: `getRootView()` returns the detached `ReactEditText` itself → `ClassCastException` (stack above). After this change: the safe cast falls back to `super.clearFocus()` + `hideSoftKeyboard()`, no crash, no behavioral difference otherwise.

Also verified:
- On the attached path (normal blur-on-submit on API ≤ 28), `rootView` is the DecorView, the safe cast succeeds, and the existing descendant-focusability logic runs exactly as before.
- On API > 28 the first branch is taken, unchanged.

Reviewed By: cortinico

Differential Revision: D110567654

Pulled By: javache

fbshipit-source-id: eb580aed7d0d029eb265b815ba7bed5e5ac85b4c