chore: merge React Native 0.87 fork point - #3066
Closed
Saadnajmi wants to merge 549 commits into
Closed
Conversation
…renderer/animated/drivers/DecayAnimationDriver.cpp (react#57104) Summary: Pull Request resolved: react#57104 Reviewed By: javache Differential Revision: D107634657 fbshipit-source-id: 4f5afc57f461a9ab53c1e0c0d6565304bd6b71af
Summary: This PR is part of Android Gradle Plugin v9 adoption. With this PR, we adopt the AGP9 repository wide and address the deprecated APIs with the newer ones. This is in combination with react#57038 <details> <summary> <b>Changes to `configureBuildConfigFieldsForLibraries` and `configureNamespaceForLibraries`</b> </summary> <br/> These helpers are called from `ReactPlugin.apply`, but they currently iterate over `rootProject.allprojects`. Since `com.facebook.react` is applied by multiple Android library projects, each application of the plugin repeats the same traversal and attempts to register `finalizeDsl` callbacks for every Android library project. The first traversal can register the callbacks successfully. However, a later traversal can reach a project whose Android DSL finalization phase has already completed. Starting with AGP 9, AGP explicitly errors when `finalizeDsl` is called after that phase has passed, which causes the build failure. [see](https://issuetracker.google.com/issues/436595826) To understand this, consider following modules: ``` :react-native-safe-area-context :react-native-mmkv :react-native-skia ``` The current code on main, would result in executing the following block 3 times: ```kt fun configureBuildConfigFieldsForLibraries(appProject: Project) { appProject.rootProject.allprojects { subproject -> println("=== subproject ${subproject.name}") subproject.pluginManager.withPlugin("com.android.library") { subproject.extensions .getByType(LibraryAndroidComponentsExtension::class.java) .finalizeDsl { ext -> ext.buildFeatures.buildConfig = true } } } } ``` The output would be: ``` > Configure project: react-native-safe-area-context === subproject RNProject === subproject app === subproject react-native-safe-area-context === subproject react-native-mmkv === subproject react-native-skia > Configure project: react-native-mmkv === subproject RNProject === subproject app === subproject react-native-safe-area-context === subproject react-native-mmkv === subproject react-native-skia > Configure project: react-native-skia === subproject RNProject === subproject app === subproject react-native-safe-area-context === subproject react-native-mmkv === subproject react-native-skia ``` Now with AGP9, the same code will throw this error: ``` > Configure project: react-native-safe-area-context === subproject RNProject === subproject app === subproject react-native-safe-area-context === subproject react-native-mmkv === subproject react-native-skia > Configure project: react-native-mmkv === subproject RNProject === subproject app === subproject react-native-safe-area-context === subproject react-native-mmkv * What went wrong: A problem occurred evaluating project': react-native-mmkv'. > Failed to apply plugin 'com. facebook. react' > It is too late to call finalizeDst as the DSL finalization blocks have already been executed. \n In particular, you cannot call 'finalizeDsl' within the "beforeVariants' or "onVariants' blocks. Instead, you must call finalizeDsl' directly within the "androidComponents' block ``` **Solution:** Since these helpers are only intended to configure Android library projects that apply the React plugin, we can configure the current project inside `pluginManager.withPlugin("com.android.library")` instead of repeatedly configuring all projects from every plugin application. ```kt fun configureBuildConfigFieldsForLibraries(project: Project) { project.extensions .getByType(LibraryAndroidComponentsExtension::class.java) .finalizeDsl { ext -> ext.buildFeatures.buildConfig = true } } ``` ```kt fun configureNamespaceForLibraries(project: Project) { project.extensions .getByType(LibraryAndroidComponentsExtension::class.java) .finalizeDsl { ext -> if (ext.namespace == null) { val manifestFile = project.layout.projectDirectory.file("src/main/AndroidManifest.xml").asFile manifestFile .takeIf { it.exists() } ?.let { file -> getPackageNameFromManifest(file)?.let { packageName -> ext.namespace = packageName } } } } } ``` One important note for `configureNamespaceForLibraries` is that the old `com.android.build.gradle.LibraryExtension` is deprecated in favor of `com.android.build.api.dsl.LibraryExtension` - which does not expose `manifestFile` from the `sourceSets`. So we have to define a path for it. For most libraries, this should be OK but for the ones which define custom path, this will fail. Hence, I believe, if it's important to have this fallback, we take this tradeoff. Otherwise, since there has been 2 years passed for AGP8 adoption and the time when this fallback was added, we may safely remove this function as almost all libraries now define a `namespace` in `android { }` DSL. With the above in place, we make one final change and that is to move these two functions inside the `withPlugin("com.android.library")` as these are only intended for libraries and that way, we also ensure that these will only be applied once the `com.android.library` plugin has been applied. ```kt project.pluginManager.withPlugin("com.android.library") { configureBuildConfigFieldsForLibraries(project) configureNamespaceForLibraries(project) configureCodegen(project, extension, rootExtension, isLibrary = true) } ``` </details> ## 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 --> [ANDROID] [BREAKING] - Adopt AGP v9 Pull Request resolved: react#57038 Test Plan: - CI passes - Verified on RN Tester - Verified on Local RN App https://github.com/user-attachments/assets/b424c211-6876-42b0-a5d1-f9ecade39a3a Reviewed By: cipolleschi Differential Revision: D107656378 Pulled By: cortinico fbshipit-source-id: 38fd7191e089ce29ccb84fa25bff6d9e920cf322
Summary: Pull Request resolved: react#57093 This is only pulled in by a few targets. Changelog: [Internal] Reviewed By: christophpurrer Differential Revision: D107651646 fbshipit-source-id: fa9a441dabf50e36ca7549cfc09591ebae67b75c
…57107) 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: react#57107 Test Plan: - CI Passing - Verified Locally Reviewed By: cortinico Differential Revision: D107880136 Pulled By: cipolleschi fbshipit-source-id: 81cf2fe53c1c2285f79db538aa5aa3cb745f796d
…eact#57103) Summary: Pull Request resolved: react#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: react/yoga#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: Add missing \n on helloworld gradle.properties ## Changelog: [INTERNAL] - Pull Request resolved: react#57113 Test Plan: CI Reviewed By: fkgozali, Abbondanzo Differential Revision: D107894162 Pulled By: cortinico fbshipit-source-id: 71d5ca5a4bde9ae550a6f17bb65a7cfad56d4f4c
Summary: Pull Request resolved: react#57111 D104680895 replaced the native Android `UnderlineSpan`/`StrikethroughSpan` with custom `CanvasEffectSpan` canvas drawing to support `textDecorationStyle`. The custom drawing enforces a minimum stroke thickness of `1.5f * density` (1.5dp), which is noticeably thicker than what the native framework spans produce. This diff removes the 1.5dp minimum for SOLID style so the decoration thickness matches the native `Paint.getUnderlineThickness()` value, restoring the pre-D104680895 visual behavior. The minimum is kept for all other styles (DOUBLE, DOTTED, DASHED, WAVY) since they need the thickness for their visual patterns to render correctly (dash intervals, dot sizes, bezier wavelength). **Remaining work:** the underline position (`baseline + thickness + 1f` in `ReactUnderlineSpan.kt`) also depends on thickness, so with a thinner SOLID stroke the underline sits closer to the text than before D104680895. The pre-D104680895 behavior used the native framework `UnderlineSpan` which positions the underline via `Paint.getUnderlinePosition()`. Attempted using `baseline + paint.underlinePosition + thickness / 2f` and `+ thickness` on API 29+ but neither matched the native positioning exactly. This needs further investigation to match the original vertical gap between text and underline. Changelog: [Android] [Fixed] - Fix text decoration line thickness regression on Android Reviewed By: javache Differential Revision: D107866867 fbshipit-source-id: 72635418181a2f4332cd4c06136a3104ca4609ba
…ct#57112) Summary: Pull Request resolved: react#57112 `UIManagerModule` was recently converted from Java to Kotlin. The nested `CustomEventNamesResolver` interface has a single abstract method, but was declared as a regular `interface` rather than `fun interface`. In Java, single-method interfaces support SAM (Single Abstract Method) conversion in Kotlin callers. After the Kotlin conversion, SAM conversion no longer works unless the interface is declared as `fun interface`. This breaks downstream libraries like `react-native-reanimated` that use lambda syntax to instantiate `CustomEventNamesResolver`: ``` UIManagerModule.CustomEventNamesResolver { eventName -> ... } ``` Adding `fun` restores SAM conversion support. This is backward compatible — existing `object : CustomEventNamesResolver { ... }` code continues to work. Reviewed By: cipolleschi Differential Revision: D107891295 fbshipit-source-id: da3f76aad4716a9646fd3841df3e13f610642453
Summary: Pull Request resolved: react#57109 changelog: [internal] The RAM bundle format stores offsets and lengths in little-endian, which previously required pulling in folly's byte-swapping library. This removes the folly dependency by implementing a simple little-endian decoder inline, cutting the build graph and making the code more self-contained. Reviewed By: javache Differential Revision: D107870286 fbshipit-source-id: c6f8399785189fad743123ecc51434c0feff9706
react#57099) Summary: Pull Request resolved: react#57099 Replaces the long-lived `GHA_NPM_TOKEN` automation token with npm Trusted Publishing (OIDC) for every `npm publish` invoked from this repo's GitHub Actions. Why a reusable workflow: npmjs.com Trusted Publishing accepts only ONE (org, repo, workflow_filename, environment) tuple per package. Today, packages are published from multiple workflow files: - `react-native` from publish-release.yml + nightly.yml - every `react-native/*` from nightly.yml + publish-bumped-packages.yml A naive per-workflow OIDC migration would require two Trusted Publisher entries per package, which npm doesn't support. Instead, this diff funnels every `npm publish` through one new file — `.github/workflows/publish-npm.yml` — invoked via `workflow_call` from the existing top-level workflows. The OIDC `job_workflow_ref` claim therefore always resolves to `publish-npm.yml`, so each package needs exactly one Trusted Publisher entry pointing here. What changes: * New `.github/workflows/publish-npm.yml`: reusable workflow with a `mode` input. `mode: react-native` runs the full Android + iOS prebuilt + JS build path (used by release & nightly, publishes `react-native` and — in nightly mode — every `react-native/*` package via `scripts/releases-ci/publish-npm.js`). `mode: monorepo-packages` runs only the JS build and publishes the delta-bumped packages via `scripts/releases-ci/publish-updated-packages.js` (used by publish-bumped-packages.yml). Both jobs grant `id-token: write` so the npm CLI can mint the OIDC token for Trusted Publishing. * `.github/workflows/publish-release.yml`: replace the `build_npm_package` job's inline build/publish steps with a `uses: ./.github/workflows/publish-npm.yml` call. The template-publish, rn-diff-purge, npm-verify, and Maven-verify steps move into a new `post_publish` follow-up job that `needs: [build_npm_package]`. Drops `GHA_NPM_TOKEN` from the env. * `.github/workflows/nightly.yml`: same — `build_npm_package` now delegates to the reusable workflow. Drops `GHA_NPM_TOKEN` and the obsolete `Verify NPM token` precheck (Trusted Publishing has no pre-mintable token to validate; failures surface at `npm publish` time). * `.github/workflows/publish-bumped-packages.yml`: shrinks to a thin trigger wrapper that calls the reusable workflow with `mode: monorepo-packages`. * `.github/workflows/create-release.yml`: drop the obsolete `Verify NPM token` step. * `.github/actions/build-npm-package`: drop the `gha-npm-token` input and the `Set npm credentials` step that wrote `_authToken`. Pass `registry-url: https://registry.npmjs.org` to setup-node so `actions/setup-node@v6` writes a `.npmrc` configured to consume the OIDC token at publish time. * `.github/actions/setup-node`: thread a new `registry-url` input through to `actions/setup-node@v6`. The publish scripts themselves (`scripts/releases-ci/publish-npm.js`, `scripts/releases-ci/publish-updated-packages.js`, `scripts/releases/utils/npm-utils.js`) are unchanged: they shell out to plain `npm publish`, which performs the OIDC exchange transparently when it sees a GitHub Actions OIDC environment and a Trusted Publisher configured for the package on npmjs.com. Note: this diff only changes the workflow definitions. Each package on npmjs.com must additionally be configured with a Trusted Publisher pointing at: - org: facebook - repo: react-native - workflow filename: publish-npm.yml - environment: npm-publish The npm CLI's OIDC exchange returns 404 until that registry-side config is in place. Trusted Publisher entries are additive on npmjs.com (don't enable "Require Trusted Publishing" yet) so the existing token-based flow keeps working through the cutover. See the stack landing notes for the full package list and UI steps. Backport: this also needs picking back to `*-stable` branches before "Require Trusted Publishing" is enabled on any package, since GitHub Actions runs the workflow file from the ref that triggers it. Changelog: [Internal] Reviewed By: cortinico, cipolleschi Differential Revision: D107805971 fbshipit-source-id: 7a360dff9666c4b0952504331d26c0af74148789
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: react#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
…eact#57130) Summary: Pull Request resolved: react#57130 The 0.86 release notes were split across four release-candidate sections (rc.0 through rc.3). Merge them into one v0.86.0 section without changing any entry text: - Combine all four RC sections under a single v0.86.0 heading - Organize entries under the standard Added / Changed / Deprecated / Fixed / Security categories, each with general / Android specific / iOS specific subsections - Sort entries within every subsection by their bold prefix - No entries were added, removed, or reworded (124 entries preserved) Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D107887110 fbshipit-source-id: c63f6fc7310eac0a58cc04ec25347093717b2175
Summary: fixes react/yoga#1659. **problem:** `YGNodeFree` called `owner->removeChild(node)` to detach the node from its parent, but never called `owner->markDirtyAndPropagate()`. the parent's layout stayed stale after the free, so a subsequent `YGNodeCalculateLayout` wouldn't recompute it. `YGNodeRemoveChild` has always called `markDirtyAndPropagate` — `YGNodeFree` was just missing the same call. `YGNodeFreeRecursive` was already correct for its recursive child removals (it calls `YGNodeRemoveChild` internally), but the terminal `YGNodeFree(root)` inherited the bug. **fix:** added `owner->markDirtyAndPropagate()` after `node->setOwner(nullptr)` in `YGNodeFree`. regression tests: `dirty_parent_when_child_freed` and `dirty_parent_when_subtree_freed_recursive` in `YGDirtyMarkingTest.cpp`. bypass-github-export-checks ## Changelog [General][Changed] - mark parent dirty when child is freed X-link: react/yoga#1969 Reviewed By: javache Differential Revision: D107895988 Pulled By: cipolleschi fbshipit-source-id: 5dce726e13147e8b7735bf72c441e80bb0c9b5a3
…ct#57116) Summary: Pull Request resolved: react#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: `textDecorationStyle` is declared on `TextStyleIOS` in the public types but `wavy` is silently dropped: Fabric's C++ enum doesn't include `Wavy`, and UIKit's `NSUnderlineStyle` has no native wavy pattern bit. Separately, `dotted` and `dashed` map to `NSUnderlineStylePatternDot` / `NSUnderlineStylePatternDash` which don't match browser geometry on iOS. This PR adds `TextDecorationStyle::Wavy` to the shared Fabric primitives / conversions (also unblocks the same value on Android, see companion PR react#56768) and renders wavy / dotted / dashed decorations with custom Core Graphics paths. **Implementation:** - Wavy ranges are tagged with a custom `RCTCustomDecorationAttributeName` (storing the line kinds, stroke color, and style key) in `RCTAttributedTextUtils.mm` and painted by `RCTTextLayoutManager.mm` after `drawGlyphsForGlyphRange:`. Wavy uses an adaptation of WebKit's formula from `Source/WebCore/style/InlineTextBoxStyle.cpp` (`controlPointDistance = thickness * 1.5 + 0.5`, one cubic Bezier per wavelength, control points at the midpoint above and below the y-axis). At iOS point sizes the literal Blink amplitude renders as a very pronounced wave because Core Graphics paints in points (not device pixels), so the constants are dialed back to read as a clear-but-subtle browser-style wave at typical text sizes. - Dotted uses a custom CG path with a zero-length dash + round line caps, producing actual circular dots at `2 * thickness` spacing. - Dashed uses a custom CG path with `[2 * thickness, thickness]` intervals — short rectangular dashes with a tight gap, closer to Safari's geometry than UIKit's default. - Solid and double continue to use UIKit's native `NSUnderlineStyle` pattern bits, so this PR does not touch the long-standing iOS Arial+bold solid-underline rendering bug tracked in react#53935. - The wavy 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). Companion PRs (independent, also targeting `main`): - react#56767 — fix(android): textDecorationColor on underlines + strikethroughs. Resolves react#4579 (2015). - react#56768 — feat(android): textDecorationStyle solid/double/dotted/dashed/wavy. Shares the `TextDecorationStyle::Wavy` enum addition; whichever lands first leaves the other with a trivial conflict to resolve. ## Changelog: [IOS] [ADDED] - `textDecorationStyle: 'wavy'` for `<Text>` (custom CoreGraphics path) [IOS] [CHANGED] - `textDecorationStyle: 'dotted'` and `'dashed'` for `<Text>` render with custom CoreGraphics paths instead of UIKit pattern bits, matching browser geometry more closely Pull Request resolved: react#56769 Test Plan: See the screenshot comparisons here: https://www.internalfb.com/compare-screenshots-from-diff/D104680636 {F1990979243} ---- Side-by-side comparison on iPhone 17 sim (iOS 26.4) of a `<Text>` with `textDecorationLine="underline"` and `textDecorationStyle` cycling through `solid` / `double` / `dotted` / `dashed` / `wavy`, verified against Safari rendering of the same CSS. Trailing periods now fall under the wavy stroke. Verified with `textDecorationColor` set distinct from the foreground color. ```tsx <Text style={{ color: 'black', textDecorationLine: 'underline', textDecorationStyle: 'wavy', textDecorationColor: '#ff00aa', }}> Hello </Text> ``` Reviewed By: cipolleschi Differential Revision: D104680636 Pulled By: cortinico fbshipit-source-id: ac96e5b36530f7d243a4b85a67c576b62fe99866
Summary: Adds a temporary debug step to both jobs of the reusable npm publish workflow that requests the GitHub Actions OIDC token (npm audience) and prints its decoded claims. This makes it possible to compare the token claims against the npm Trusted Publisher configuration when the OIDC exchange fails. Only the decoded claims are printed, never the raw token. Changelog: [Internal] bypass-github-export-checks Reviewed By: cortinico, cipolleschi Differential Revision: D108108630 fbshipit-source-id: 6ae8be8c9e9e2e611b6941b336230a21f876e134
Summary: iOS I18nManager.isRTL is not wrong but often misinterpreted. This PR adds a comment to clarify what the native call does, since Apple doesn't. Undocumented behavior made me waste several hours hunting for an i18n issue that incorrectly made me think RN had a bug. It's impossible to know this code is working as intended as original commit does not state why the code exist, only that it was changed, no mentions in changelogs, and no official docs from neither RN nor from Apple explains the combined or individual behavior. ## 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 --> [iOS] [Added] - Added comment to clarify why i18nManager.isRTL may not return the expected value Pull Request resolved: react#51661 Test Plan: This project demonstrates that compiling and running will give you the "wrong"/unexpected isRTL value when using Hebrew https://github.com/scarlac/rtl-test When Hebrew is added to the Xcode project under "Internationalization" then you will observe that `.isRTL` starts returning `true`. Note that Xcode has a nasty caching bug that means that removing Hebrew: 1. Will Not remove Hebrew (you need to remove it twice) 2. Will Not cause `.isRTL` to revert behavior The solution is to remove Hebrew 2x, and then to clear DerivedData (or Product -> Clean Build Folder..., or CMD+Shift+K) In addition to these issues, it's important to note that calling .forceRTL or .allowRTL are persisted across restarts. This is clearly intentional but also not clearly documented, so you cannot "clear" these states. A reinstall is necessary, or a counter-value call is necessary. The demo project does not use these calls, so it's not an issue there. Reviewed By: javache Differential Revision: D108129627 Pulled By: cortinico fbshipit-source-id: 34f5b5509f48c0f102d4234f0315c5f58e30e773
…erface (react#57159) Summary: The hand-written TypeScript types declare only **12 of the 20** pointer event handlers that `ViewProps` actually exposes (per the Flow source and the generated `react-native-strict-api` types). The `PointerEvents` interface in `Libraries/Types/CoreEventTypes.d.ts` is missing: - `onPointerOver` / `onPointerOverCapture` - `onPointerOut` / `onPointerOutCapture` - `onGotPointerCapture` / `onGotPointerCaptureCapture` - `onLostPointerCapture` / `onLostPointerCaptureCapture` These are part of the W3C Pointer Events API. They are declared in the Flow source — `Libraries/Components/View/ViewPropTypes.js` (all typed `(e: PointerEvent) => void`) — and in the generated `react-native-strict-api` types, but were missing from the hand-written TypeScript types, so TypeScript users get a type error using them on any built-in component: ``` Property 'onPointerOver' does not exist on type '... ViewProps'. Did you mean 'onPointerMove'? ``` This adds the 8 missing handlers to the `PointerEvents` interface (matching the existing 12) and a type test covering them. ## Changelog: [GENERAL] [FIXED] - Add missing pointer event handler types (`onPointerOver`, `onPointerOut`, `onGotPointerCapture`, `onLostPointerCapture`, and their `*Capture` variants) to the TypeScript types Pull Request resolved: react#57159 Test Plan: `yarn test-typescript` passes. Verified before/after with `tsc -p packages/react-native/types/tsconfig.json`: - **Before** (props absent): the added type test fails with `Property 'onPointerOver' does not exist on type '... ViewProps'`. - **After**: passes — `<View onPointerOver={e => e.nativeEvent.pointerId} … />` type-checks for all 8 handlers, with the event correctly inferred as `PointerEvent`. Reviewed By: huntie Differential Revision: D108114655 Pulled By: fabriziocucci fbshipit-source-id: 08d364d2e156953027c0d951ab3d895a1eeab159
Summary: X-link: react#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: X-link: react#57125 Fixes a crash (`java.lang.RuntimeException` via `NoSuchElementException`) in `SkewMatrixHelper.isAffine2DTransformWithSkew` and `buildAffine2DMatrix` when a transform array contains an empty map entry (no keys). Changelog: [Android][Fixed] Fix crash in SkewMatrixHelper Reviewed By: Abbondanzo Differential Revision: D107763077 fbshipit-source-id: d61819e875e2334c6d6b121aba1876ec3153c002
Summary: X-link: react#57134 `telemetryTimePointToSecondsSinceEpoch()` in `ReactCommon/react/utils/Telemetry.h` was a `static inline` helper that converted a `TelemetryTimePoint` to seconds since the UNIX epoch, but it had no callers anywhere. This is a pure dead-code removal. The sibling `clockCast` helper it used is left in place (it remains part of the public API surface). Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D108012910 fbshipit-source-id: 5361ef87aaae3c676b542059c0a9d6475b33de45
Summary: X-link: react#57135 `ClearableSynchronizedPool` (an `internal` Kotlin class in `ReactAndroid/.../common/`) was a variant of androidx `Pools.SynchronizedPool` adding a `clear()` method, but it was never instantiated or referenced anywhere. The live event pools (`OnLayoutEvent`, `PointerEvent`, `TouchEvent`, `ScrollEvent`) use androidx `SynchronizedPool` directly. This removes the orphaned class. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D108012905 fbshipit-source-id: d5972b4c47d054310c8b7803482fa4e6b7a9928e
Summary: X-link: react#57136 `ReactRootView.simulateAttachForTesting()` was a package-private `VisibleForTesting` helper that set up the attach flags and dispatchers, but no test or production code ever called it. `RootViewTest` exercises `startReactApplication`/`unmountReactApplication` and the sibling `simulateCheckForKeyboardForTesting`, never this method. This removes the orphaned helper. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D108012908 fbshipit-source-id: ee550f66fae07bfeb75fd59b85d5d812fea7e2c1
Summary: X-link: react#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: react#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: react#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: react#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: react#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: react#57138 `getWarningHighlightColor` in `LogBox/UI/LogBoxStyle.js` was an exported color helper with no importers. It is a duplicate of the live `getHighlightColor` (identical `rgba(252, 176, 29, ...)` value), which is the one actually used by LogBox UI. This removes the dead duplicate. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D108012913 fbshipit-source-id: dd22adcf191284eb3c81778f92a8c72be15f9d30
Summary: X-link: react#57139 `RCTJSCSetOptionType` was a file-local `using` alias (`BOOL (*)(const char *)`) in `RCTPerfMonitor.mm` that was never referenced. The concrete `RCTJSCSetOption` function is called directly at its two call sites; no code ever used the function-pointer typedef. This removes the dead alias. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D108012902 fbshipit-source-id: 2d8b207c6d216356a5b4eef9b71effda47db5744
Summary: Add test for `onabort` prop ## Changelog: [INTERNAL] [ADDED] - Add `AbortSignal::onabort` test Pull Request resolved: react#57431 Test Plan: ```bash yarn fantom abort-api/__tests__/AbortController-itest.js --watch ``` Reviewed By: javache Differential Revision: D110787344 Pulled By: Abbondanzo fbshipit-source-id: 1d9b02faa62d7ddb22fb3fccdf5efb6570b924f4
Summary: Pull Request resolved: react#57453 Metro release notes: https://github.com/react/metro/releases/tag/v0.86.0 Changelog: [General][Changed] Metro to 0.86.0 Reviewed By: huntie Differential Revision: D110789092 fbshipit-source-id: 4b999bf533c3c61b7915a73366ff3ca13257c3dc
…podspec (react#57449) Summary: Pull Request resolved: react#57449 Removes duplicate `React-jserrorhandler` dependency declaration from the React-runtimescheduler.podspec file. The dependency was listed twice (lines 50 and 52), now consolidated to a single entry. Changelog: [Internal] Differential Revision: D110778944 fbshipit-source-id: 9e2e091a24cb0c9289a61d7c758917264c6fdacf
…renderer/attributedstring/ParagraphAttributes.cpp (react#57456) Summary: Pull Request resolved: react#57456 Reviewed By: cortinico Differential Revision: D110867849 fbshipit-source-id: 8dc4e0408480f9b09b5b5c604545c369dc2fc473
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The canonical Doxygen 1.16.1 Linux output is byte-stable without the fork-local path-based enum deduplication, and matches the output produced with it. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Regenerate all nine snapshots with the upstream Linux toolchain: Doxygen 1.16.1 and Python 3.12. The outputs are byte-identical across independent runs. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Embed the helper script in the podspec so CocoaPods executes it from the downloaded Hermes source root without serializing the checkout path. This preserves the quoted-script behavior from upstream react#45316 while making local podspec checksums portable. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The prior 4a3daf regeneration used unbundled CocoaPods 1.15.2. Regenerate with the repository-pinned Bundler 2.4.12 and CocoaPods 1.14.2 so local pod checksums, including Hermes, match the canonical toolchain. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Pass the existing BUILD_TYPE value into the host hermesc CMake configure step. Hosted prebuild CI otherwise stops at Hermes CMake configuration because CMAKE_BUILD_TYPE is unset. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…work Newer Hermes tags remove the legacy inspector header directories while retaining the other packaged API surfaces. Guard the top-level and chrome globs independently in both Apple packaging paths. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Saadnajmi
changed the title
Collaborator
Author
|
🤖 Copilot: Closing this replacement PR because JJ will remain the topology and evolution tool. Continue review on #3037. |
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.
Supersedes
Replaces #3037 with the locally recreated DAG node.
d8c588e4a67cbe9d3cdebb27a8909a93448807cd754e6051819af4b6076a17e663e8d45dabcc5a801cd2e8bb301d7b1f233d5bd7d3b3d20dc624b18f03bfd6dbbab535f06399d26f775464ba137b19c7saadnajmi/dag/0.86-mergeRecreation evidence
The ordered-parent DAG, conflict provenance, consumer-liveness checks, tree-delta confinement, validation logs, and verified bundle are archived in the Phase 1 evidence package. Published as a draft replacement for review.