scratch: asset holder (paragraph) - #5
Closed
janicduplessis wants to merge 8803 commits into
Closed
janicduplessis wants to merge 8803 commits into
janicduplessis wants to merge 8803 commits into
Conversation
Summary: Pull Request resolved: react#58139 Classifies `react/nativemodule/idlecallbacks:idlecallbacks` as a private target under the C++ stable API three-tier visibility model. Adds `#include <react/cxxstableapi/PrivateGuard.h>` to the module's single exported header (`NativeIdleCallbacks.h`), and wires the guard dependency into BUCK, CMake, and the podspec. The podspec needs no `USE_FRAMEWORKS` header search path edit: its existing `$(PODS_TARGET_SRCROOT)/../../..` already resolves to `ReactCommon`, so `<react/cxxstableapi/...>` is on the path. The guards are inert unless a consumer defines `RN_STRICT_API`, so there is no behavior change. Changelog: [Internal] Reviewed By: cortinico Differential Revision: D117333873 fbshipit-source-id: d5d51baa78f4568c3445de12144dfd419660165d
Summary: Pull Request resolved: react#58293 Changelog: [Internal] Reviewed By: vzaidman Differential Revision: D118513884 fbshipit-source-id: a33a81eab930ac29663410cf04163aebb87062ad
Summary:
The preset's Babel-API accesses are optional, but invoking it without the Babel API still has two incomplete fallback paths: `preset()` can read properties from an undefined options object, and `getPreset(code, {dev: false})` receives no transform profile and silently falls back to legacy class transforms instead of the normal `hermes-stable` default.
Default options to an empty object, consistently rely on that non-null invariant throughout the configuration builder, and apply `hermes-stable` when neither explicit options nor `babel.caller` provides a profile. Explicit options and caller-provided profiles retain precedence.
## Changelog:
[GENERAL] [FIXED] - Apply normal preset defaults when invoked without a Babel API or options object.
Pull Request resolved: react#58254
Test Plan:
- Added a regression proving `preset()` builds without options or a Babel API.
- Added a transform regression proving no-API invocation preserves classes under the default `hermes-stable` profile; exact baseline lowers the class to helpers.
- Full preset Jest passes: 4/4 suites, 112/112 tests, 16 snapshots.
- Fresh Flow check reports 0 errors.
- Targeted no-ignore ESLint, Prettier, and `git diff --check` pass.
No breaking change: explicit profiles/caller behavior are unchanged, while standalone invocation now matches the preset's documented default path.
Reviewed By: javache
Differential Revision: D118438065
Pulled By: vzaidman
fbshipit-source-id: e952eece72664dfa9d60d25d26955655e057f388
Summary: Development `-main` builds compute the Babel preset transformer cache key from preset JavaScript sources, but omit `package.json`. React Native regularly updates parser and Babel plugin dependencies without changing those source files, so a dependency-only update can preserve the cache key and reuse transforms produced by an older dependency set. Include the preset package metadata bytes in the existing MD5 input. This adds one small file read only to the memoized `-main` slow path; published releases remain keyed directly by their immutable package version. ## Changelog: [INTERNAL] [FIXED] - Invalidate React Native Babel preset development caches when dependency metadata changes. Pull Request resolved: react#58251 Test Plan: - Added an isolated-module regression that supplies two package metadata contents with identical preset source contents; pristine main returns the same key, while the fix returns different keys. - Full preset Jest passes: 5/5 suites, 111/111 tests, 16 snapshots. - Fresh Flow check reports 0 errors. - Targeted no-ignore ESLint, Prettier, and `git diff --check` pass. No transform output, public API, published-release cache behavior, or UI changes. Reviewed By: christophpurrer Differential Revision: D118440621 Pulled By: vzaidman fbshipit-source-id: 21d4df2d5bc0428d6cf2138b2f5230d777b7ddb0
Differential Revision: D118438065 Original commit changeset: e952eece7266 Original Phabricator Diff: D118438065 fbshipit-source-id: 78cab65f148d8e3290a19ced1e00a1b59b739062
… defaults without a Babel API Differential Revision: D118563281 Original commit changeset: 78cab65f148d Original Phabricator Diff: D118438065 fbshipit-source-id: b748a2566173b4d9ac4597062a208d157680cd5a
…tion (react#58297) Summary: Pull Request resolved: react#58297 `PointerEvent.createW3CPointerEvent` built its payload map, then read one field straight back out of that same half-built map to compute another field: ``` pointerEvent.putInt("buttons", getButtons(_eventName, pointerType, buttonState)) ... getPressure(pointerEvent.getInt("buttons"), _eventName) ``` Reading from a `WritableNativeMap` while still writing to it is not free and not safe: - `ReadableNativeMap.getInt` materialises the *whole* map across JNI (`importKeys` + `importValues`) and memoises the result in `keysStorage` / `localMapStorage`. Every subsequent `put*` on the same instance then leaves those caches stale, so a later Kotlin-side read of the map (`hasKey`, `toHashMap`) does not see `pressure`, `tangentialPressure`, `hitPathForEventListener` or the modifier keys. - It happens on the pointer-event hot path, once per pointer index per dispatch, purely to recover a value the caller already has in hand. Keep the value in a local and pass it to `getPressure` directly. The payload is byte-for-byte identical: `getInt` returns exactly the `Int` that `putInt` stored, so `getPressure` receives the same argument as before. Changelog: [Internal] Reviewed By: christophpurrer Differential Revision: D118471070 fbshipit-source-id: 79b06256e8e6e245bcd050a5faa666202fa7a068
…ain/jni/react/reactnativeblob/BlobCollector.cpp (react#58300) Summary: Pull Request resolved: react#58300 Reviewed By: javache Differential Revision: D118604015 fbshipit-source-id: 61769d6987c620e1912f23fbee0dd92bd8a762fd
Summary: Run the RNTester Image flow keyboard dismissal only on Android. Android needs this step because the keyboard obscures the platform test results control. On iOS, the keyboard can dismiss automatically before Maestro reaches `hideKeyboard`, causing the flow to fail with `Could not hide the keyboard`. This has occurred repeatedly in Maestro Cloud since react#58272 landed; for example, [run 33517266090](https://github.com/react/react-native/actions/runs/33517266090/job/99902026553). The flow passed in Maestro Cloud iOS while the dismissal was absent, and the existing platform condition syntax is already used by the neighboring Image flows. ## Changelog: [INTERNAL] [FIXED] - Avoid dismissing an already-hidden keyboard in the iOS Maestro Image flow. Pull Request resolved: react#58288 Test Plan: - `MAESTRO_CLI_NO_ANALYTICS=1 maestro check-syntax packages/rn-tester/.maestro/image.yml` — passed (`OK`) - `./node_modules/.bin/prettier --check packages/rn-tester/.maestro/image.yml` — passed - `git diff --check` — passed - Confirmed the Android dismissal remains present behind `platform: Android`. Reviewed By: christophpurrer Differential Revision: D118457013 Pulled By: cortinico fbshipit-source-id: a8cb212004be0d9eeeff40e148f5d5f7ebee393a
Summary: Replace the immediate template-app startup assertion with `extendedWaitUntil` and a 60-second timeout. The Android ARM64 debug app occasionally becomes accessibility-visible just after the existing assertion times out under native translation. This failed all three attempts in [run 33609361836](https://github.com/react/react-native/actions/runs/33609361836/job/100196578829) and [run 33540863593](https://github.com/react/react-native/actions/runs/33540863593/job/99984608541). In the captured failure artifact, both the screenshot and XML hierarchy contain `Welcome to React Native`, indicating a startup/accessibility timing race rather than an app failure. Release runs remain fast because `extendedWaitUntil` returns as soon as the element is visible. ## Changelog: [INTERNAL] [FIXED] - Wait for the template app to become visible in Maestro E2E tests. Pull Request resolved: react#58289 Test Plan: - `MAESTRO_CLI_NO_ANALYTICS=1 maestro check-syntax scripts/e2e/.maestro/start.yml` — passed (`OK`) - `./node_modules/.bin/prettier --check scripts/e2e/.maestro/start.yml` — passed - `git diff --check` — passed - Inspected the failing Android debug artifact: the expected text is present in both the final screenshot and accessibility hierarchy. Reviewed By: christophpurrer Differential Revision: D118457123 Pulled By: cortinico fbshipit-source-id: d2f5232482933e1decb13a9b2dac7911b205db4f
Summary:
The React Native Babel preset statically replaces `Platform.select({...})` for the target platform. Its property scan currently stops at the first matching key, while JavaScript object-literal evaluation keeps the last duplicate definition. For example, `Platform.select({ios: 1, ios: 2})` runs as `2` but the preset compiles it to `1`.
Scan the already-validated static properties from the end so compiled output matches runtime semantics while preserving O(n), allocation-free lookup. Metro has a parallel transform that can run first; companion [Metro PR https://github.com/react/react-native/issues/1889](https://github.com/react/metro/pull/1889) applies the same correction so output remains transform-order independent.
## Changelog:
[GENERAL] [FIXED] - Inline the last duplicate key from static Platform.select object literals.
Pull Request resolved: react#58249
Test Plan:
- Added a focused preset regression; pristine main emits `const value=1`, while the fix emits `const value=2`.
- Full preset Jest passes: 4/4 suites, 111/111 tests, 16 snapshots.
- Fresh Flow check reports 0 errors.
- Targeted no-ignore ESLint, Prettier, and `git diff --check` pass.
No behavior changes for object literals without duplicate static keys; no UI change.
Reviewed By: christophpurrer
Differential Revision: D118499490
Pulled By: vzaidman
fbshipit-source-id: 3bd58c44c70415c57ed02266a5af2eea242471e4
Summary: `customTransformOptions.unstable_preserveClassPrivate` currently disables private-field and private-method transforms for every profile. With `hermes-legacy`, the preset still lowers the surrounding class syntax, and Babel then aborts because its class transform requires the private transforms. Only preserve private syntax when the selected profile also preserves class syntax. Stable and canary Hermes profiles keep their existing experimental behavior; legacy profiles continue lowering private fields and methods together with classes instead of crashing. ## Changelog: [GENERAL] [FIXED] - Keep private class transforms enabled for profiles that lower classes. Pull Request resolved: react#58253 Test Plan: - Added a focused `hermes-legacy` regression containing both a private field and private method with the preservation option enabled. - Exact baseline throws Babel's private-method transform error; the fixed preset compiles and emits the normal private-field helpers. - Full preset Jest passes: 4/4 suites, 111/111 tests, 16 snapshots. - Fresh Flow check reports 0 errors. - Targeted no-ignore ESLint, Prettier, and `git diff --check` pass. No breaking change: stable/canary preservation is unchanged, while an invalid legacy configuration now compiles correctly. Reviewed By: javache Differential Revision: D118438778 Pulled By: vzaidman fbshipit-source-id: 650a70d8759b135cb06f9bd3f2b45b0ee766762b
Summary: Pull Request resolved: react#58283 Reclassifies `react/renderer/components/image:image` from public to "for frameworks" under the C++ stable API three-tier visibility model. Consumers that opt into `RN_STRICT_API` now get a suppressible warning where they previously got an error pointing at the umbrella, and can acknowledge it with `RN_ALLOW_FRAMEWORKS`; without that flag the guards are inert, so no existing build changes behaviour. Changelog: [Internal] Reviewed By: christophpurrer, javache Differential Revision: D118440296 fbshipit-source-id: 45faf64ef36d3c3c596b1b8c06408fc43d3b59f8
…eact#58295) Summary: Pull Request resolved: react#58295 This is to investigate a crash on ios in C++ Animated rollout. On iOS, Native Animated drives frames from a `CADisplayLink` on the main run loop. While the app is inactive — which includes the whole `UIApplicationWillEnterForeground` → `UIApplicationDidBecomeActive` transition — it is not presenting, so a frame rendered then is never seen. Its commit and synchronous per-view updates still run on the main thread though, competing with the work the app must complete to become responsive. Adds `initWithSkipFramesDuringForegroundTransition:` to `RCTAnimatedModuleProvider`, declared in a new `RCTAnimatedModuleProvider+Private.h`. When YES, `_onDisplayLinkTick` returns early while `applicationState == UIApplicationStateInactive`. **The public API is unchanged.** `RCTAnimatedModuleProvider.h` is untouched and the C++ API snapshots have no delta — `+Private.h` is in the ReactApple `exclude_patterns`. Plain `init` still exists and defaults to NO, so every existing caller is unaffected; only hosts that opt in via the private header see different behaviour. Two properties worth being explicit about: - **The clock is not stopped, only the frame is skipped.** `AnimationDriver` computes progress from a timestamp (`timeDeltaMs = frameTimeMs - startFrameTimeMs_`), so the first frame after activation resolves to the value the animation should have reached rather than resuming from where it was suspended. - **Frames are not skipped while backgrounded** — `Background` is not `Inactive`. Completion handlers, and any app logic they drive, are therefore delayed by at most the length of the transition, not by the time spent in the background. Reading `applicationState` rather than tracking lifecycle notifications also avoids a failure mode: a mirrored flag must be cleared on every path out of the transition, including an abandoned foregrounding (a `willEnterForeground` with no following `didBecomeActive`), or frames are skipped indefinitely. There is no such state to get stuck here. `UIApplicationStateInactive` also covers other non-presenting moments — Control Center, the app switcher, an incoming call banner. Skipping frames there is harmless for the same reason: the clock keeps running and the first frame after activation is correct. The check sits inside the file's existing `TARGET_OS_OSX` guard, since `UIApplication` is iOS-only and this translation unit also builds for macOS. Changelog: [Internal] Reviewed By: javache, christophpurrer Differential Revision: D118188111 fbshipit-source-id: c9f19fafd7bc6f07649a7160fd71b02de888f879
…d calls (react#58264) Summary: Pull Request resolved: react#58264 When an ObjC TurboModule method raises an `NSException`, what happens next depends on how it was called. A sync call converts it into a JSError via `convertNSExceptionToJSError`, which builds `<module>.<method> raised an exception: <reason>`. The async and void paths cannot do that — they run on the module's method queue with no JS runtime to attach the error to — so they rethrow. Both rethrow sites discarded `moduleName` and `methodNameStr`, even though both are captured in the enclosing block and in scope at the throw site. Because void and async methods are dispatched onto the method queue, the rethrown exception is uncaught and terminates the process, and by then every module frame has unwound: the reported stack bottoms out in `objc_exception_rethrow` followed by a libdispatch queue drain. Nothing in the resulting crash says which module or method failed. The practical effect is that all such crashes — regardless of which module raised them, and regardless of whether the underlying bug is a null argument, a wrong-typed argument, or anything else — collapse into a single crash bucket with no owner attached, and cannot be split or routed. This adds an `addModuleIdentityToException` helper next to `convertNSExceptionToJSError` and applies it at both rethrow sites. It preserves the exception's `name` and its existing `userInfo` entries so any predicate-based handling is unaffected, and prefixes `reason` with `<module>.<method>` to match the sync path's wording. A freshly constructed `NSException` captures its call stack at `throw` rather than at the original raise, so the raise-site return addresses are carried across in `userInfo` and nothing is lost. Behaviour is otherwise unchanged: the exception is still thrown, on the same thread, at the same point, with the same name. Nothing is caught, swallowed, logged away, or downgraded. Reviewers should expect the crash grouping to change: the existing aggregate bucket will drain and be replaced by per-module buckets. That is the point of the change, but it is worth knowing before it happens. Changelog: [iOS][Fixed] - Include the module and method name in exceptions rethrown from async and void TurboModule calls Reviewed By: javache Differential Revision: D118144605 fbshipit-source-id: fb51936e73c7705ae4e23f650834d2c66e66a50e
Summary: Pull Request resolved: react#58269 Classifies `react/renderer/animated:animated` as a "for frameworks" target under the C++ stable API three-tier visibility model. Adds `#include <react/cxxstableapi/FrameworksGuard.h>` to the module's 30 non-test headers, and wires the guard dependency into BUCK and CMake. No CocoaPods change is needed: the module ships as a subspec of `React-Fabric`, whose parent spec already declares `React-cxxstableapi` and calls `mark_as_react_native_build`. Consumers that opt into `RN_STRICT_API` now get a warning if they include these headers directly, which they can acknowledge with `RN_ALLOW_FRAMEWORKS`; without that flag the guards are inert, so no existing build changes behaviour. Changelog: [Internal] Reviewed By: christophpurrer Differential Revision: D118256232 fbshipit-source-id: 5ec898e99858980ff1e69a4a1eac6515740d06f1
Summary: Pull Request resolved: react#58285 Reclassifies `react/renderer/components/modal:modal` from public to "for frameworks" under the C++ stable API three-tier visibility model. Consumers that opt into `RN_STRICT_API` now get a suppressible warning where they previously got an error pointing at the umbrella, and can acknowledge it with `RN_ALLOW_FRAMEWORKS`; without that flag the guards are inert, so no existing build changes behaviour. Changelog: [Internal] Reviewed By: christophpurrer Differential Revision: D118440328 fbshipit-source-id: f337645c846cfc669b1e0d03cf83b9c59affe657
Summary: Pull Request resolved: react#58284 Reclassifies `react/renderer/components/text:text` from public to "for frameworks" under the C++ stable API three-tier visibility model. Consumers that opt into `RN_STRICT_API` now get a suppressible warning where they previously got an error pointing at the umbrella, and can acknowledge it with `RN_ALLOW_FRAMEWORKS`; without that flag the guards are inert, so no existing build changes behaviour. Changelog: [Internal] Reviewed By: christophpurrer Differential Revision: D118440348 fbshipit-source-id: 0ec6c4304a81466766d0353bc4aec3d29c958f76
Summary: Pull Request resolved: react#58282 Reclassifies `react/renderer/components/root:root` from public to "for frameworks" under the C++ stable API three-tier visibility model. Consumers that opt into `RN_STRICT_API` now get a suppressible warning where they previously got an error pointing at the umbrella, and can acknowledge it with `RN_ALLOW_FRAMEWORKS`; without that flag the guards are inert, so no existing build changes behaviour. Changelog: [Internal] Reviewed By: christophpurrer Differential Revision: D118440376 fbshipit-source-id: 2f6b74a8e1ead890bc2d8832370cda5384332bcf
Summary: Pull Request resolved: react#58287 Reclassifies `react/renderer/components/scrollview:scrollview` from public to "for frameworks" under the C++ stable API three-tier visibility model. Consumers that opt into `RN_STRICT_API` now get a suppressible warning where they previously got an error pointing at the umbrella, and can acknowledge it with `RN_ALLOW_FRAMEWORKS`; without that flag the guards are inert, so no existing build changes behaviour. Changelog: [Internal] Reviewed By: christophpurrer Differential Revision: D118440409 fbshipit-source-id: 1c2895ed0b59e24bb06396a23af227726a1b7406
Summary: Pull Request resolved: react#58286 Reclassifies `react/renderer/bridging:bridging` from public to "for frameworks" under the C++ stable API three-tier visibility model. Consumers that opt into `RN_STRICT_API` now get a suppressible warning where they previously got an error pointing at the umbrella, and can acknowledge it with `RN_ALLOW_FRAMEWORKS`; without that flag the guards are inert, so no existing build changes behaviour. Changelog: [Internal] Reviewed By: christophpurrer Differential Revision: D118440441 fbshipit-source-id: edf9691028506b7016f32d3a3cff41d905abca41
Summary: Pull Request resolved: react#58083 Classifies `react/featureflags:featureflags` as a public target under the C++ stable API three-tier visibility model and introduces the module umbrella `React/FeatureFlags.h` as its public entry point. This module's headers are generated, so the `UmbrellaGuard.h` include is added to the templates in `scripts/featureflags/templates/common-cxx/` rather than to the headers themselves. `ReactNativeFeatureFlagsOverridesOSSStable.h` is the module's one hand-written header and is edited directly. The umbrella is not generated, and re-exports all eight of the module's headers. The sibling `react/nativemodule/featureflags:featureflags` target is private under the same model. The guards are inert unless a consumer defines `RN_STRICT_API`, so there is no behavior change. Changelog: [General][Added] - Add `<React/FeatureFlags.h>` umbrella header as the public entry point for `react/featureflags` Reviewed By: cortinico Differential Revision: D117172757 fbshipit-source-id: 9cc66e3d9e88842d2caba919c2dd941f1e602da3
…eact#58188) Summary: Pull Request resolved: react#58188 `paperComponentName` is a `codegenNativeComponent` option that makes the generated view config announce the old-architecture (Paper) `RCT`-prefixed ViewManager name instead of the component's own name. We no longer support the old architecture, so core components should announce their real Fabric names. Removes the option from the five core specs where it is provably redundant: | Spec | Name in view config | |---|---| | `ActivityIndicatorViewNativeComponent.js` | `RCTActivityIndicatorView` -> `ActivityIndicatorView` | | `RCTModalHostViewNativeComponent.js` | `RCTModalHostView` -> `ModalHostView` | | `PullToRefreshViewNativeComponent.js` | `RCTRefreshControl` -> `PullToRefreshView` | | `RCTSafeAreaViewNativeComponent.js` | `RCTSafeAreaView` -> `SafeAreaView` | | `SwitchNativeComponent.js` | `RCTSwitch` -> `Switch` | Each new name already resolves natively, so this is a no-op at runtime: - **iOS Fabric** — the plugin keys in `RCTFabricComponentsPlugins.mm` and the `react_fabric_component_plugin_provider` entries in `BUCK` are all unprefixed and match the spec names exactly. Previously the `RCT` prefix was simply stripped again by `componentNameByReactViewName()`, which exists only to undo this legacy prefixing. - **Android Fabric** — mount items carry the C++ descriptor name, not the JS name (`IntBufferBatchMountItem`), so Android is unaffected. `ModalHostView` still maps via `FabricNameComponentMapping`, and `SafeAreaView` still resolves to `ReactSafeAreaViewManager` through the generic `"RCT$className"` fallback in `ViewManagerRegistry`. `PullToRefreshView` and `Switch` are Android-excluded. Deliberately out of scope: - **The codegen option itself is retained.** 24 Meta-internal specs outside `react-native-github` still pass `paperComponentName` (`RCTMapNativeComponent.js`, `SliderNativeComponent.js`, the `AdsLWI` previews, MagicIsland, ...), as do third-party OSS libraries. `getOptions()` does not validate keys, so removing support would silently resolve those components to an unregistered name instead of erroring. - **`RCTInputAccessoryViewNativeComponent.js` keeps the option**, where it is load-bearing: the spec name is `InputAccessory` but the C++ `ComponentName` is `InputAccessoryView`, so dropping it would fall through to `RCTUnimplementedViewComponentView`. Aligning those needs a rename of the codegen'd `InputAccessoryProps`/`InputAccessoryEventEmitter` symbols in handwritten C++/ObjC. - **`paperComponentNameDeprecated`**, which still has 6 internal users. - **Documentation.** The `paperComponentName` section of the `name_mapping.md` docs is refreshed in a separate diff, so this one touches no Markdown. Also updates the `RCTSwitch` fiber-type checks in `ReactTreeSerializer.js` to accept `Switch`, mirroring the existing check in its sibling `DebugInteractions.js`. Snapshot churn is the renamed element names only. The `RCTRefreshControl` entries in the `VirtualizedList`/`RelayPaginationView` snapshots are unchanged because they come from the hardcoded `packages/jest-preset/jest/mocks/RefreshControl.js` mock, not from the view config. ## Changelog: [General][Changed] - Core components (`ActivityIndicatorView`, `ModalHostView`, `PullToRefreshView`, `SafeAreaView`, `Switch`) no longer report legacy `RCT`-prefixed names in their view configs ## Facebook: https://www.internalfb.com/agent-home?session_id=dmh-e2936545-b7bf-43e3-b1a8-4b95325fd16a Reviewed By: GijsWeterings Differential Revision: D117877024 fbshipit-source-id: a738157ec4ffa5c042891b26eb4c358cd5bb2248
…react#57984) Summary: Pull Request resolved: react#57984 `hash_combine` mixes each field into the previous seed, so it forms a dependency chain the CPU cannot overlap and an unset optional still costs a full link. `hash_combine_optionals` folds a run of optionals into one presence-mask link plus the engaged values, so a further optional costs a bit in the mask rather than a link. The mask is what keeps it collision-free: skipping disengaged fields alone would make the same value in two different slots hash identically. Equality moves from `std::tie` to a short-circuit chain ordered cheapest first, with the string and vector fields last, because the dominant caller is a successful cache lookup where the keys are equal and every field has to be examined. Changelog: [Internal] Reviewed By: javache Differential Revision: D115621401 fbshipit-source-id: f164c24f6b085ef8d32cafbeb2b61636eec3d0cf
…eact#58321) Summary: Pull Request resolved: react#58321 `SchedulerDelegateInvalidationTest.DelegateDestroyedWithoutError_PendingRenderingUpdateIsUAF` asserted a real use-after-free through `EXPECT_DEATH`: it destroyed the `RecordingDelegate`, then drained `pendingRenderingUpdates_` so the queued lambda dereferenced the freed object, and expected the process to die. Undefined behaviour is not a reliable process-termination signal, without a sanitizer the freed read can simply succeed, and gtest then reports `Result: failed to die.` The death test also has to `fork()` a multi-threaded process. This replaces the death test with a deterministic assertion on the same property. Instead of destroying the delegate, the test detaches it via `Scheduler::setDelegate(nullptr)` and keeps it alive, then drains the pending rendering update and asserts that the drained lambda still invokes `schedulerShouldRenderTransactions` on the detached delegate. That pins exactly the coverage the death test was after: `Scheduler::setDelegate` is a plain assignment, so a lambda already queued by `uiManagerDidFinishTransaction` keeps the raw delegate pointer it captured, and draining it after the delegate has been detached still calls through that pointer, which is a use-after-free when the delegate has been destroyed rather than merely detached. Same property, no undefined behaviour and no `fork()`. It matches the shape of the existing `UnregisterSurface_DoesNotDrainPendingRenderingUpdates` test in the same file. The underlying window is unchanged: nothing in `Scheduler::setDelegate` cancels rendering updates that are already queued, so closing it needs a shutdown signal at the runtime-scheduler level. That is a design decision for the owners rather than a test fix. Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D118205636 fbshipit-source-id: 87cefd8db0d0ebf55025bb60fcdfd1e4cda46e35
Summary: Pull Request resolved: react#58301 Classifies `react/renderer/telemetry:telemetry` as a "for frameworks" target under the C++ stable API three-tier visibility model. Adds `#include <react/cxxstableapi/FrameworksGuard.h>` to the module's 2 non-test headers, and wires the guard dependency into BUCK and CMake. No CocoaPods change is needed: the module ships as a subspec of `React-Fabric`, whose parent spec already declares `React-cxxstableapi` and calls `mark_as_react_native_build`. Consumers that opt into `RN_STRICT_API` now get a warning if they include these headers directly, which they can acknowledge with `RN_ALLOW_FRAMEWORKS`; without that flag the guards are inert, so no existing build changes behaviour. Changelog: [Internal] Reviewed By: rubennorte Differential Revision: D118612692 fbshipit-source-id: ef8f9ab90699f272d0592d56dd68550ae3b6f84f
Summary: Pull Request resolved: react#58303 Classifies `react/renderer/mounting:mounting` as a "for frameworks" target under the C++ stable API three-tier visibility model. Adds `#include <react/cxxstableapi/FrameworksGuard.h>` to the module's 15 non-test headers, and wires the guard dependency into BUCK and CMake. No CocoaPods change is needed: the module ships as a subspec of `React-Fabric`, whose parent spec already declares `React-cxxstableapi` and calls `mark_as_react_native_build`. Consumers that opt into `RN_STRICT_API` now get a warning if they include these headers directly, which they can acknowledge with `RN_ALLOW_FRAMEWORKS`; without that flag the guards are inert, so no existing build changes behaviour. Changelog: [Internal] Reviewed By: rubennorte Differential Revision: D118612708 fbshipit-source-id: d6cd27d55bd7ca86a70a837919a78a24426176d7
Summary: Pull Request resolved: react#58167 Classifies `react/runtime:runtime` and `react/runtime:runtime-platform` as "for frameworks" targets under the three-tier C++ stable API visibility model. Consumers that opt into `RN_STRICT_API` now get a warning if they include their headers directly, which they can acknowledge with `RN_ALLOW_FRAMEWORKS`; without that flag the guards are inert, so no existing build changes behaviour. The Apple platform layer is covered alongside the core runtime, so `RCTHost.h` and `RCTInstance.h` are in scope. `React-RuntimeCore` already depended on `React-cxxstableapi` from an earlier migration in the same pod; `React-RuntimeApple` gains the dependency here. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D117690303 fbshipit-source-id: 5e80284eefe6be4b556aacf4415c8c8ba228471e
Summary: Pull Request resolved: react#58274 `ReadableNativeMap` materialization copied keys and created temporary JNI references for every imported type. Cache pointers to the stable native values and reuse global `ReadableType` references so importing maps and arrays does less allocation and lookup work. Writable maps can continue mutating after materialization because `folly::dynamic` stores object entries in reference-stable `F14NodeMap` nodes. Changelog: [Internal] Reviewed By: christophpurrer, rubennorte Differential Revision: D118277119 fbshipit-source-id: 955a60ef7f1eb4cb7549d64caa1238416e90b223
…8292) Summary: `npx react-native spm add` writes `HERMES_CLI_PATH` into the app's committed `project.pbxproj` — the absolute path of `hermesc` in the `hermes-compiler` npm package, as resolved on whichever machine ran the command. So every SwiftPM-converted app commits one developer's disk layout. Nothing needs it: `react-native-xcode.sh` already resolves `hermesc` at build time through react-native's own dependency graph when the current value is not a file. A relative setting can't replace it either — `$(REACT_NATIVE_PATH)/../hermes-compiler` breaks on a symlinked `react-native`, and `$(SRCROOT)/../node_modules/…` breaks on hoisted monorepos. So this deletes `resolveHermesCliPathSetting()`, along with the `hermesCliPath` parameter it fed on `injectSpmIntoPbxproj` and `mergeReactBuildSettings`. Already-injected projects self-clean on the next `spm add`/`update`, which strips every scalar recorded in `.spm-injected.json` before re-injecting. ### Scope: SwiftPM only Both pieces involved arrived with SwiftPM in react#57332 and first shipped in 0.87.0 — `scripts/spm/generate-spm-xcodeproj.js` (the whole file, including the write) and the `NODE_HERMESC` build-time fallback in `react-native-xcode.sh`. Everything CocoaPods relies on is older and untouched, all present in 0.86.0: the pod-derived `HERMES_CLI_PATH` default, the "hermesc could not be found" error, and the `hermesc -emit-binary` call. **A CocoaPods build cannot be affected by this change.** That parameter shipped in 0.87.0 and 0.87.1, but SwiftPM is Preview-labelled, so removing it is in scope. Nothing in the repo passed it except the deleted resolver. ## Known limitation The fallback is gated on `PODS_ROOT` being absent, so a SwiftPM app that keeps side-by-side non-RN pods skips it and needs an explicit `HERMES_CLI_PATH`. Evaluating that gate verbatim out of the unchanged script: | app | gate | hermesc | | --- | --- | --- | | no `Pods/` (normal SwiftPM app) | fires | from `node_modules` | | `Pods/`, non-RN pods only | skipped | pod path — absent | | `Pods/` with `hermes-engine` | skipped | the pod's, unchanged | Set it in an xcconfig, not the pbxproj: `createdScalars` cleanup removes by key, so it would drop a hand-edited value too. Keying the gate on the `hermes-engine` directory would close this — left as a follow-up so this PR doesn't touch the bundling script. ## Changelog: [IOS] [FIXED] - SwiftPM: stop baking an absolute, machine-specific HERMES_CLI_PATH into the app's pbxproj; resolve hermesc at build time instead Pull Request resolved: react#58292 Test Plan: Red first — with the source reverted, the new entry-point test fails on a seeded `hermes-compiler` fixture: `✕ writes no HERMES_CLI_PATH, in any configuration or the marker` (1 failed, 76 passed). ``` yarn jest packages/react-native/scripts/spm --no-cache -i Test Suites: 18 passed, 18 total Tests: 835 passed, 835 total ``` `yarn flow-check` (0 errors), plus `yarn eslint --max-warnings 0` and `yarn prettier --check` on the four changed files. End to end: a 0.87.1 SwiftPM app (`shopify/react-native-skia` example, no Pods) with the `HERMES_CLI_PATH` lines removed from its pbxproj builds in Release, the fallback resolving `hermesc` from `node_modules/hermes-compiler`. That build ran against an earlier revision of this branch which also widened the shell gate; with no `Pods/` it is row 1, where both conditions behave identically. There is no shell test harness, and the script is unchanged here. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Reviewed By: cortinico Differential Revision: D118624244 Pulled By: cipolleschi fbshipit-source-id: 5784a2de69af0c50c82129d96423801b0f5b0eba
Summary: Pull Request resolved: react#58599 `AccessibilityState::selected` was a plain `bool` defaulting to `false`, so the native side could not tell a component that is selectable but currently unselected (`accessibilityState={{selected: false}}`) from one that is not selectable at all (`accessibilityState={{}}`). Both arrived as `false`. The JS type is already `selected?: ?boolean`, so this is the bridge discarding a value the public API accepts. Make `selected` a `std::optional<bool>` defaulting to `std::nullopt`. JS accessibilityState native selected (before -> after) {} false -> undefined {selected: false} false -> false {selected: true} true -> true This aligns the representation with ARIA, which `accessibilityState` mirrors: the bool / tri-state split now tracks which ARIA attributes admit an undefined value. field ARIA value type admits undefined representation disabled boolean no bool busy boolean no bool selected boolean yes std::optional<bool> (changed) expanded boolean yes std::optional<bool> checked tristate yes CheckedState (None = unset) That is also why `disabled` and `busy` stay plain `bool`: ARIA gives them no undefined value, so there is no unset state to preserve. `expanded` was made optional for this same reason in react#40881 and `checked` has always carried a `None`; `selected` was the outlier. Nor is "unset" merely "absent" for this attribute. `testing-library/dom` computes it as `boolean | undefined`, documented "false/true if (not)selected, undefined if not selectable" -- the same shape, with the same meaning, that this change introduces. Host platforms need the distinction: on Windows a selectable component must implement ISelectionItemProvider so UIA can report selection state, and with the old representation every component carrying an accessibilityState looked selectable. iOS and Android rendering is unchanged. Trait derivation coalesces the optional with `value_or(false)`, and the Android serializer omits the key when the value is unset, which `BaseViewManager#setViewState` already handles by falling back to `setSelected(false)`. Reviewer note: `std::optional<bool>` is contextually convertible to `bool`, so a bare `if (state.selected)` still compiles but tests engagement rather than value, silently marking an explicitly unselected component as selected. There is a regression test for that specific hazard. Fixes react#46988 Supersedes react#47296, which went stale. Changelog: [General][Breaking] - `AccessibilityState::selected` is now `std::optional<bool>` in C++ props, preserving an unset `selected` instead of coercing it to `false` Reviewed By: javache Differential Revision: D120049025 fbshipit-source-id: 53ac440976f00daffb3f0599c8841ada2a1452a6
…58607) Summary: Pull Request resolved: react#58607 `onHWKeyEvent` tells JS which key was pressed but not when it was pressed, so a listener can only time a press from the moment the device event reaches the JavaScript thread. That delivery is asynchronous, so any latency measured from JS silently excludes the native-to-JS hop — and excludes more of it the busier the JS thread is, which is exactly when the interaction is slowest. Add the originating `KeyEvent.getEventTime()` to the event payload. It is `SystemClock.uptimeMillis()`, the same `CLOCK_MONOTONIC` base that `performance.now()` reads in JS, so a listener can subtract the two directly with no clock conversion. The field is omitted for the focus and blur events, which have no originating hardware event. Additive and behaviour-preserving: no existing payload key changes, and nothing in the framework reads the new one. ## Changelog Changelog: [Android][Added] - Add `eventTime` to the `onHWKeyEvent` device event payload Reviewed By: rozele Differential Revision: D120451212 fbshipit-source-id: a58d239d68071fbe7cd0a4310b1c8be4951cddbb
Summary: X-link: react/metro#1955 Pull Request resolved: react#58608 [changelog](https://github.com/facebook/flow/blob/main/Changelog.md) Changelog: [Internal] Reviewed By: panagosg7 Differential Revision: D120845480 fbshipit-source-id: ccaa780e12d3ca033941de770f0ba31f90c7ad28
Summary: Removes the root `CLAUDE.md`, which only contained `AGENTS.md`. As of [Claude Code v2.1.277](https://github.com/anthropics/claude-code/releases/tag/v2.1.277), Claude Code reads `AGENTS.md` directly in a project with no `CLAUDE.md`, so the import shim is redundant. Keeping a single instruction file avoids the two drifting apart. Scope: only the root `CLAUDE.md`. `AGENTS.md` and `packages/react-native-compatibility-check/AGENTS.md` are unchanged. ## Changelog: [INTERNAL] - Remove redundant root CLAUDE.md in favor of AGENTS.md Pull Request resolved: react#58600 Test Plan: `git grep CLAUDE.md` returns no references to the file anywhere in the repo. No code or tests are touched. Reviewed By: christophpurrer Differential Revision: D120809883 Pulled By: fabriziocucci fbshipit-source-id: c699b3c7bba9d26869dfab83cd5f8fa1b881aef3
Summary: Pull Request resolved: react#58609 Changelog: [Internal] Differential Revision: D120838256 fbshipit-source-id: 1dd13e2748802bf50e6746257182fe1d0e4241ab
Summary: Pull Request resolved: react#58548 The umbrella headers under `ReactCommon/**/React/` were only linked into their nested `ReactCommon/...` include dirs during the iOS SPM prebuild, so `#include <React/Debug.h>` (and the other umbrella headers) could not be resolved by the `React` framework, breaking the build. This diff links each umbrella header directory into the `React` header dir. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D120310677 fbshipit-source-id: b741585ba579b3e109088cfd8a67898487eace42
…eact#58532) Summary: Pull Request resolved: react#58532 Changelog: [Internal] Update the reactperflogger module to use `React/Timing.h` umbrella include instead of a direct one. Reviewed By: cipolleschi Differential Revision: D120116155 fbshipit-source-id: 4a9112a57c05ad91dd7c7da5a54b2fecee08ef56
…ct#58530) Summary: `EventEmitter::experimental_flushSync` only *requests* an event beat; the beat is processed at the next `EventBeat::induce`. On iOS the run loop observer that induces the beat runs before Core Animation's commit observer, so a request made from `layoutSubviews` — inside CA's commit cycle — is only processed one frame later. Anything that reports layout-driven state to JS synchronously (`VirtualView` mode changes, and safe area insets in the PRs that build on this) renders a frame late in exactly the cases that matter. `AppleEventBeat` now also schedules an induce in the **display phase of the current commit cycle**. Core Animation runs a commit as layout → display → commit, so a zero-sized layer marked as needing display during layout gets its `display` call after the whole layout pass and before the transaction is committed. That layer needs to live in the tree being committed, so the beat has to know which tree that is — and the emitter tells it: - `experimental_flushSync` carries the **tag of the emitting view** through `EventDispatcher` and `EventQueue` to `EventBeat::requestSynchronous(Tag)`, with `kNoTag` (react#58531) meaning no view attribution; a no-argument overload keeps unattributed requesters and the existing tests unchanged. The emitter reads the tag from its `ShadowNodeFamily` at flush time; `kNoTag` if the family is already gone. - `AppleEventBeat` resolves the tag to the layer of the view's **window** through a resolver injected by `RCTSurfacePresenter` (`findComponentViewWithTag:` on the mounting registry — nullable, non-creating, main thread) and attaches its flusher layer there. The requesting view's window is by definition the root of the layer tree whose layout emitted the request, so the flusher is guaranteed a display phase in the current commit cycle — including for content UIKit mounts in a window of its own, like a full screen modal or LogBox. Requests within one cycle coalesce into a single induce. One related fix in `EventBeat` itself: a synchronous request is no longer stranded behind an already-scheduled asynchronous beat (it would silently lose its this-frame guarantee, and the leftover flag would make an unrelated later beat blocking). `AppleEventBeat.cpp` becomes `.mm` for the Objective-C. **Risk:** this changes when queued events are flushed on iOS for every `experimental_flushSync` caller — today `VirtualView`, and safe area insets with the PRs on top. The worst case is a beat processed a frame *earlier* than before, inside a Core Animation commit; the run loop observer path is untouched and still catches anything the display phase misses (an emitter with no tag, an unmounted view, a request off the main thread). Android ignores the tag. Revert is self-contained. ## Design Q&A: **What happens when two views in different windows update at once?** Each requesting window gets its own dirty flusher layer (the map is keyed by host layer), and the first `display` to fire induces the beat, which drains the whole event queue — every window's updates mount before that commit presents. The remaining flushers hit the `isEventBeatRequested_` guard and no-op, so it is one beat total, not one per window. If windows ever commit in separate transactions, each request still resolves within its own window's cycle, since its layer sits in the tree that emitted it. Only requesting windows carry a dirty layer. **Can the tag point at the wrong view — after an unmount, or a recycled view?** No. The tag comes from the emitter's `ShadowNodeFamily`, and a family keeps one tag for its whole life, across clones and state updates; if the family is already gone the flush carries `kNoTag` and skips the resolver. What changes over a view's life — its window — is read live: the tag resolves to a view at flush time and `view.window.layer` is looked up then, so a view that moved between windows targets its current tree. A view mid-unmount or recycled resolves to nil (the registry erases the entry and recycled views get tag `0`) and degrades to run-loop-observer timing. The tag only ever influences *where the induce is scheduled*, never what is delivered or to whom, so the blast radius of any staleness is one frame of timing, not correctness. **Does `VirtualView` need changes to benefit?** No — its sync mode-change flush goes through its own emitter, so the tag attribution is automatic. The case this improves is a mode change emitted during Core Animation layout (a resize pulling a virtualized item into view): on `main` that renders one frame late; here the induce lands in the display phase of the VirtualView's own window, including inside a full screen modal. ## Changelog: [INTERNAL] - Process synchronous event beats in the frame that requested them on iOS, scheduling the induce on the requesting view's window Pull Request resolved: react#58530 Test Plan: New unit tests in `EventBeatTest.cpp` cover the beat semantics: a synchronous request during an already-scheduled asynchronous beat, coalescing, and induce ordering. They drive the protected `induce` through a subclass standing in for the platform. On device, with the safe area insets prop from the PRs above merged on top: an RNTester example renders a loud marker (yellow background) while a view observes the safe area but has not received an inset event yet, so any presented marker frame means the dispatch was not synchronous. The full apply → landscape → portrait sequence **inside a full screen modal** on an iPhone 17 Pro simulator, decomposed with ffmpeg into 982 frames and every frame scanned for the marker color — **zero marker frames**, and mid-rotation frames already carry the incoming orientation's insets, so the padding animates with the rotation. Scoped honestly: the first inset event after setting the prop is processed at the call site, so the marker primarily proves no regression; the same-frame path for layout-driven changes rests on the by-construction argument above plus the rotation frames. https://github.com/user-attachments/assets/0f2db837-c9c0-4457-96c2-847b7aecf10e `yarn fantom .../ViewSafeAreaInsets-itest.js` passes 4/4 with the prop merged on top. C++ API snapshots regenerated (`scripts/cxx-api/parser`, Doxygen 1.16.1): the deltas are the `requestSynchronous` overload pair, `EventEmitter::getTag`, the resolver type, and the `AppleEventBeat` constructor and destructor. --- **Stack** — split out of react#57967, which stays open as the prototype and design discussion. GitHub will not take a fork branch as a pull request base, so each of these targets `main` and its diff contains the ones below it until they merge. Each PR is one commit on top of the previous one. This is the bottom of the stack, so its diff is already just this change. 👉 1. react#58530 — Process synchronous event beats in the frame that requested them 2. react#58109 — Add an `experimental_onSafeAreaInsetsChange` view prop 3. react#58110 — Report the window safe area insets through Dimensions 4. react#58112 — Render the internal SafeAreaView from the safe area insets prop 5. react#58113 — Remove the native SafeAreaView and the deprecated public export An earlier variant that targeted the surface's root view instead of the view's window was closed in react#58528; its review thread carries the analysis behind the window-based resolution. react#58108 was the per-window predecessor this supersedes. Reviewed By: javache Differential Revision: D120200496 Pulled By: Abbondanzo fbshipit-source-id: b06ecb30935837abd6561f54674afef0cdf215a8
Summary: Pull Request resolved: react#58558 Generate TurboModule interfaces using the public Bridging C++ entry point so generated consumers remain compatible with the strict API boundary. Export the bridging module include root from its CMake target so source-built consumers can resolve <React/Bridging.h>. Changelog: [Internal] Reviewed By: cortinico Differential Revision: D120357994 fbshipit-source-id: 072d67197daf19acffbb66c110833a10a7094cfb
Summary: The format workflow currently runs on `macos-15`, whose default Xcode 16.4 toolchain does not meet the repository formatter's Swift 6.3 minimum. As a result, `format-swift.js` warns and skips Swift files. Run the format job on `macos-26` and explicitly select Xcode 26.6.0 so that `swift format` 6.3 is available and Swift formatting is actually exercised in CI. This does not include the unrelated C++ formatting change currently making the job red on `main`. ## Changelog: [INTERNAL] [FIXED] - Configure Swift formatting in the format workflow Pull Request resolved: react#58616 Test Plan: - `yarn prettier --check .github/workflows/format.yml` — passes. - `swift format --version` — reports `6.3.0` locally. - [GitHub format run](https://github.com/react/react-native/actions/runs/35590873668/job/106304725401) — the macOS 26 runner accepted Xcode 26.6.0, and `format-swift.js` completed without the missing Swift 6.3 warning. The job remains red because enabling the formatter exposes existing formatting changes (along with the unrelated C++ formatting issue already present on `main`). Reviewed By: cipolleschi Differential Revision: D120988250 Pulled By: cortinico fbshipit-source-id: f21ae2b52041edf84bf142c770ffe0da2821654a
Summary: Apply the repository C++ formatter to `RCTSurfacePresenter.mm`. The lambda parameter added in react#58530 was indented one column too far, causing the `format` job on `main` to produce a tracked diff and fail. ## Changelog: [INTERNAL] [FIXED] - Fix formatting in RCTSurfacePresenter Pull Request resolved: react#58617 Test Plan: - `yarn format-cpp` — completes successfully and changes only `packages/react-native/React/Fabric/RCTSurfacePresenter.mm`. - `node ./scripts/clang-format.js --check packages/react-native/React/Fabric/RCTSurfacePresenter.mm` — passes. - `git diff --check` — passes. - `yarn format-check-cpp` — the repository-wide check still reports pre-existing violations in vendored Hermes sources; the targeted check above passes for the changed file. Reviewed By: cipolleschi Differential Revision: D120989136 Pulled By: cortinico fbshipit-source-id: ccda2f291ad60e9de7b5fffd153f939102dea238
Summary: Pull Request resolved: react#58570 Route public C++ dependencies through their supported umbrella entry points so framework consumers can use the modal module with strict API enforcement enabled. Changelog: [Internal] landed-with-radar-review Reviewed By: cortinico Differential Revision: D120528333 fbshipit-source-id: 2e37837eae930f117f74101b10379ba73c690858
Summary: Pull Request resolved: react#58591 Add safe fallback cases to RendererCore enum conversions so public umbrella consumers compile with Apple's -Wswitch-default policy. Changelog: [Internal] ___ Differential Revision: D120687424 fbshipit-source-id: cb7be5b960835229d484d51ebc1d55ee3f75a751
Summary: Pull Request resolved: react#58613 Automatically mock `NativeAnimatedHelper` in the React Native Jest preset and add a regression test that verifies the helper is mocked. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D120986825 fbshipit-source-id: 5a509a92ea8d699e331224c07b408cfd01c3ad0f
Summary: Artifact uploads can fail on transient network errors such as the `ETIMEDOUT` in https://github.com/react/react-native/actions/runs/35598907154/job/106330670539. This change: - adds a local composite action backed by `actions/upload-artifact` v7.0.1 - retries failed uploads twice, waiting 10 seconds before attempt 2 and 20 seconds before attempt 3 - propagates the third failure to the caller - preserves all v7 inputs and outputs - migrates all 35 artifact upload call sites to the wrapper ## Changelog: [INTERNAL] [FIXED] - Retry artifact uploads to reduce transient CI failures. Pull Request resolved: react#58620 Test Plan: - `node_modules/.bin/prettier --check $(git diff --name-only HEAD^ -- '*.yml' '*.yaml')` — passed - `npx --yes action-validator/cli@0.6.0 .github/actions/upload-artifact/action.yml` — passed - `git diff HEAD^ --check` — passed - Verified no `actions/upload-artifact@v6` references remain under `.github` Reviewed By: andrewdacenko Differential Revision: D121002745 Pulled By: cortinico fbshipit-source-id: e63e30f3e86b0a2cb6c94aa549cdfe5e6dfbdc2b
Summary: Pull Request resolved: react#58592 Add structured-clone coverage for `ResizeObserver`, `ResizeObserverEntry`, and `ResizeObserverSize` using real observer entries. Changelog: [Internal] Reviewed By: andrewdacenko Differential Revision: D120691617 fbshipit-source-id: 974c250d16496b5c46029ffea8dfbcc4162b2914
…eact#58614) Summary: Pull Request resolved: react#58614 Changelog: [Internal] Adds `enableFabricCommitBranchingMergeOnMainThread` feature flag for follow-up diffs. Reviewed By: javache Differential Revision: D120981615 fbshipit-source-id: 2294f6bee061eebc01702e0224c95d0e2c625705
Summary: Upgrade Flow. Reviewed By: gkz Differential Revision: D121017087 fbshipit-source-id: d5e9b717239db8c0369097d9d084c7450857f5d7
…set (react#57974) Summary: Pull Request resolved: react#57974 Adds a mechanism for callers to configure `babel/plugin-transform-runtime` programmatically via Babel caller data, in addition to preset options. - `enableBabelRuntime` (boolean toggle, or a string to pin a specific `babel/runtime` version) can now be read from the Babel caller. - `babelRuntimeModuleName` (the module helpers are imported from) can be provided via preset options or the Babel caller. Both values are passed as separate primitives (Babel only permits primitive caller values). Preset options take precedence over caller data, consistent with how `unstable_transformProfile` is resolved. Changelog: [General][Added] - Allow `react-native/babel-preset` to read `enableBabelRuntime` and `babelRuntimeModuleName` from Babel caller data Reviewed By: vzaidman Differential Revision: D114070686 fbshipit-source-id: c65928adc0886805fa56f944f7fff50a30ae268b
Summary: Pull Request resolved: react#58618 Expose the renderer proxy as `Renderer` from `react-native/unstable-internals-do-not-use`. Generated Codegen modules can be emitted into consumer packages and need a package entry point for dispatching renderer commands without deep imports. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D120991150 fbshipit-source-id: 5808de3dc56d8b0e80bbe4134f740a647ff6151f
Summary: Pull Request resolved: react#58602 Use the React Native root and supported secondary entry points for public APIs used by the Jest preset. Resolve implementation modules through package-relative paths so the preset does not depend on unsupported package subpaths. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D120717568 fbshipit-source-id: d19036571e9d34938a4d616303e36548f508ea96
Summary: Pull Request resolved: react#58603 Generate view configs and Codegen fixtures using supported React Native entry points or values derived from their exports. Generated view config modules can be emitted into arbitrary consumer package locations, so they cannot use a package-relative path back into React Native. Keep `ConditionallyIgnoredEventHandlers` centralized and expose it from the explicitly unstable compatibility entry point instead of duplicating its platform-specific semantics in generated output. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D120717571 fbshipit-source-id: 9f3ea06d393eb8702bbb3ef2767c2d7c5fde1315
Summary: Pull Request resolved: react#58605 Use global DOM APIs, supported React Native entry points, and package-relative implementation imports throughout Fantom. Use the renderer-only private interface for the existing public-instance conversion helpers instead of importing Node internals. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D120717572 fbshipit-source-id: 1aae11b7b9434c783d42ca289e2c6edd17aa887c
Summary: Pull Request resolved: react#58604 Migrate the remaining package consumers to React Native root exports, documented secondary entry points, global web APIs, or package-relative implementation paths. Use feature flags instead of directly invoking web API setup helpers. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D120717573 fbshipit-source-id: bf1bdb8d49340dd0040a46eb388850bd4b8139fc
Summary: Pull Request resolved: react#58612 Remove the RNTester accessibility manager integration test. The native harness has kept it disabled because the underlying native module is unavailable, and its setup depends on a private native-module API. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D120923184 fbshipit-source-id: c75a284f6ee2e5f6a55e293338d858c6f42c56ef
Summary: Pull Request resolved: react#58628 Restore idiomatic Objective-C fast enumeration now that React Native no longer enables the incompatible `cppcoreguidelines-init-variables` check. Changelog: [Internal] Reviewed By: Abbondanzo Differential Revision: D121040575 fbshipit-source-id: 12313370081ee7563c4db02d0d4546bfad728610
Summary: AGP 9.2.1 depends on Kotlin Gradle plugin 2.2.10 (see https://developer.android.com/build/releases/agp-9-2-0-release-notes#compatibility), so every build that applies AGP already runs Kotlin 2.2.10, including this repo (`./gradlew buildEnvironment` shows `kotlin-gradle-plugin:2.2.0 -> 2.2.10`). The version catalogs still declare `kotlin = "2.2.0"`. Related Expo fix: expo/expo#50455 ## Changelog: [ANDROID] [CHANGED] - Bump Kotlin to 2.2.10 to match the version required by AGP 9.2.1 Pull Request resolved: react#58624 Test Plan: - run RN tester ✅ Reviewed By: javache Differential Revision: D121073295 Pulled By: Abbondanzo fbshipit-source-id: 33f077242802c1064693ecae16f8decfcaee1762
`RCTParagraphComponentView` derives the text view's frame and drawing frame in `layoutSubviews`, requested with `setNeedsLayout` from `updateState` and `updateLayoutMetrics`. When a mount runs inside Core Animation's display phase — which is where `AppleEventBeat` processes a synchronous event requested during layout — this transaction's layout pass has already happened, so the text view displays with the new attributed string but the previous drawing frame: the text is cut off at the old width. The queued `layoutSubviews` then updates the drawing frame in the next transaction, but that property does not invalidate the display, so the clipped drawing stays until something else redraws the view. Compute the frames in `finalizeUpdates:` instead. The mounting manager calls it once per view after all of a mutation's `update*` calls, so it coalesces state and layout-metrics changes the same way the layout pass did, without depending on a layout pass that may already be over. One computation per mount, as before, minus the layout pass.
commented
Sep 22, 2026
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: trueThanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Asset holder for a PR comment upstream. Will be closed.