21472 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
Sebastian "Sebbie" Silbermann	561ed529b3	Fix formatting (#36332)	2026-04-23 21:16:35 +02:00
Kotha Dhakshin	142cfde89e	Fix FragmentInstance listener leak: normalize boolean vs object capture options per DOM spec (#36047) ... ## Summary `FragmentInstance.addEventListener` and `removeEventListener` fail to cross-match listeners when the `capture` option is passed as a **boolean** in one call and an **options object** in the other. This violates the [DOM Living Standard](https://dom.spec.whatwg.org/#dom-eventtarget-removeeventlistener), which states that `addEventListener(type, fn, true)` and `addEventListener(type, fn, {capture: true})` are identical. ### Root Cause In `ReactFiberConfigDOM.js`, the `normalizeListenerOptions` function generates a listener key string for deduplication. The boolean branch generates a **different format** than the object branch: ```js // Boolean branch (old) — produces "c=1" return `c=${opts ? '1' : '0'}`; // Object branch — produces "c=1&o=0&p=0" return `c=${opts.capture ? '1' : '0'}&o=${opts.once ? '1' : '0'}&p=${opts.passive ? '1' : '0'}`; ``` Because the keys differ, `indexOfEventListener` cannot match them — so `removeEventListener('click', fn, {capture: true})` silently fails to remove a listener registered with `addEventListener('click', fn, true)`, and vice versa. This causes a **memory leak and event listener accumulation** on all Fragment child DOM nodes. ### Fix Normalize the boolean branch to produce the same full key format: ```js // Boolean branch (fixed) — now produces "c=1&o=0&p=0" (matches object branch) return `c=${opts ? '1' : '0'}&o=0&p=0`; ``` This makes both forms produce an identical key, matching the DOM spec behavior. ### When Was This Introduced This bug has been present since `FragmentInstance` event listener tracking was first added. It became reachable in production as of [#36026](https://github.com/facebook/react/pull/36026) which enabled `enableFragmentRefs` + `enableFragmentRefsInstanceHandles` across all builds (merged 3 days ago). ### Tests Added two new regression tests to `ReactDOMFragmentRefs-test.js`: 1. `removes a capture listener registered with boolean when removed with options object` 2. `removes a capture listener registered with options object when removed with boolean` Both tests were failing before this fix and pass after. ## How did you test this change? Added two new automated tests covering both cross-form removal directions. Existing tests continue to pass. ## Changelog ### React DOM - **Fixed** `FragmentInstance.removeEventListener()` not removing capture-phase listeners when the `capture` option form (boolean vs options object) differs between `add` and `remove` calls.	2026-04-22 09:40:34 -04:00
vmx906	94643c3b85	Suggest correct casing for misspelled credentialless iframe attribute (#36322) ... ## Summary Follow-up to #36148 (which added credentialless as a recognized boolean attribute for iframes). Adds credentialless to possibleStandardNames so React's dev warning can suggest the correct casing when users write it as Credentialless (or another incorrect case). Includes an SSR test asserting the "Did you mean credentialless?" warning fires. ## Test plan - yarn test ReactDOMComponent passes, including the new should warn about incorrect casing on the credentialless property (ssr) case	2026-04-21 10:33:45 +01:00
vmx906	306a01b4e0	Add credentialless as a recognized boolean attribute for iframes (#36148) ... ## Summary The `credentialless` attribute is a boolean HTML attribute for `<iframe>` elements that loads the iframe in a new, ephemeral context without access to the parent's credentials (cookies, client certificates, etc.). This change adds it to all boolean attribute switch/case lists in React DOM so it is properly handled as a boolean (set when true, removed when false) rather than being treated as an unknown string attribute. Per the [Anonymous iframe spec (WICG)](https://wicg.github.io/anonymous-iframe/): > The credentialless attribute enables loading documents hosted by the iframe with a new and ephemeral storage partition. It is a boolean value. The default is false. ``` partial interface HTMLIFrameElement { attribute boolean credentialless; }; ``` Changes: - ReactDOMComponent.js: Added to both `setProp` and `diffHydratedGenericElement` - ReactFizzConfigDOM.js: Added to `pushAttribute` for server-side rendering - ReactDOMUnknownPropertyHook.js: Added to both validation switch/case lists ## Test plan - Added unit test in DOMPropertyOperations-test.js verifying `credentialless={true}` sets the attribute to `''` and `credentialless={false}` removes it - All tests pass in source and www channels (590 tests each) - Flow type checking passes (dom-node renderer) - Prettier and lint pass	2026-04-20 18:37:33 +01:00
Jack Pope	3ee1fe4a8e	Fix contributor attribution for ESLint v10 support ... Updated the changelog to reflect the correct contributor for the ESLint v10 support addition.	2026-04-20 11:40:34 -04:00
Zeya Peng	1ddff43c41	Add null check before calling fabricSuspendOnActiveViewTransition (#36310) ... ## Summary - Adds a null check before calling `fabricSuspendOnActiveViewTransition()` in the Fabric renderer's `suspendOnActiveViewTransition` export - Prevents crashes on hosts where `nativeFabricUIManager` does not yet implement `suspendOnActiveViewTransition` ## Test plan - Verified the change compiles correctly - Hosts with `suspendOnActiveViewTransition` implemented continue to work as before - Hosts without `suspendOnActiveViewTransition` no longer crash when view transitions are active	2026-04-17 13:21:41 -04:00
mofeiZ	d1727fbf98	[eprh] Update changelog for 7.1.1 (#36308) eslint-plugin-react-hooks@7.1.1	2026-04-17 12:43:35 -04:00
mofeiZ	bc249804d3	[eprh] Add back a no-op for removed component-hook-factories rule (#36307) ... The `component-hook-factories` rule was removed in #35825 as part of a feature flag cleanup, but was listed in the README as part of the manual config example. This broke users who used a manual config (copied from the old README) in eslint-plugin-react-hooks 7.1.0. This adds back a deprecated no-op rule as a fix. #35825 removed other rules (`automatic-effect-dependencies` and `fire`), but these were for experimental features that did not ship. These were also not referenced in the README.	2026-04-17 12:31:24 -04:00
Sebastian "Sebbie" Silbermann	da9325b519	[Fiber] Double invoke Effects in StrictMode after Fast Refresh (#35962)	2026-04-17 18:14:50 +02:00
Sebastian "Sebbie" Silbermann	67e47593b6	[Fiber] Double invoke Effects in Strict Mode during Hydration (#35961)	2026-04-17 18:09:37 +02:00
Sebastian "Sebbie" Silbermann	23fcd7cea1	Minify prod error messages for all browser bundles (#36277)	2026-04-17 18:01:56 +02:00
Zeya Peng	bf45a68dd3	Remove legacy Paper renderer shim cleanup from artifact commit workflow (#36297) ... ## Summary PR #36285 deleted the Paper (legacy) renderer, including the shim file `scripts/rollup/shims/react-native/ReactNative.js`. However, the `runtime_commit_artifacts` workflow still tries to `rm` this file after moving build artifacts into `compiled-rn/`. Since the file no longer exists in the build output, `rm` (without `-f`) fails and kills the entire step. This has caused **every run of the Commit Artifacts workflow to fail since #36285 landed on April 16**, blocking both `builds/facebook-www` and `builds/facebook-fbsource` branches from receiving new build artifacts. This in turn blocks DiffTrain from syncing React changes into Meta's internal monorepo.	2026-04-17 10:26:22 +01:00
mofeiZ	77319e2af0	[eprh] Update changelog for 7.1.0 (#36292) eslint-plugin-react-hooks@7.1.0	2026-04-16 18:03:13 -04:00
Josh Story	4b073f4887	[Fizz] add additional task reentrancy protections (#36291) ... The prior fix for finishedTask reentrancy solved an observed failure. This change adds a bit of defensive bookeeping to protect against other theoretical reentrant task finishing that might fail in simlar ways but where we don't have a clear demonstration of the bug.	2026-04-16 14:15:06 -07:00
Zeya Peng	f6fe4275c7	Wire up createViewTransitionInstance and suspendOnActiveViewTransition in Fabric (#36196) ... ## Summary - Wires up the native `fabricCreateViewTransitionInstance` call in `createViewTransitionInstance` which will create a ShadowNode for old pseudo element - Extracts tag allocation logic into a shared `allocateTag()` function exported from `ReactFiberConfigFabric` - Imports `allocateTag` in `ReactFiberConfigFabricWithViewTransition` - Reuses `allocateTag()` in `createInstance` and `createTextInstance` instead of inline tag incrementing - Wires up native `fabricSuspendOnActiveViewTransition` call in `suspendOnActiveViewTransition` which suspends another view transition when the previous one is not yet finished ## Test plan - Existing Fabric renderer tests should continue to pass - ViewTransition instance creation now properly allocates a tag and calls the native module	2026-04-16 16:59:54 -04:00
Zeya Peng	fe5160140d	Wire up startViewTransitionReadyFinished in Fabric (#36246) ... ## Summary - Imports `startViewTransitionReadyFinished` from `nativeFabricUIManager` in `ReactFiberConfigFabricWithViewTransition` - Calls `fabricStartViewTransitionReadyFinished()` when the view transition `ready` promise resolves This is not a config function, but it's helpful to have it notify fabric ViewTransition runtime when ready callback is done. Right now we're testing animation kicked off from view transition event handlers, this is signal to know when animations that belong to a transition have all started. ## Test plan - Existing Fabric renderer tests should continue to pass - View transition ready callback now notifies the native module when finished	2026-04-16 16:41:05 -04:00
Josh Story	ea6792026f	[Fizz] prevent reentrant finishedTask from calling completeAll multiple times (#36287) ... It is possible for the fallback tasks from a Suspense boundary to trigger an early `completeAll` call which is later repeated due to `finishedTask` reentrancy. For node.js in particular this might be problematic since we invoke a callback on each `completeAll` call but in general it just isn't the right semantics since the call is running slightly earlier than the completion of the last `finishedTask` invocation. This change ensures that any reentrant `finishedTask` calls (due to soft aborting fallback tasks) omit the `completeAll` call by temporarily incrementing the total pending tasks.	2026-04-16 13:26:34 -07:00
Rubén Norte	56922cf751	[react-native-renderer] Delete Paper (legacy) renderer (#36285) ... ## Summary The Paper renderer is no longer used in React Native. This commit removes all remaining Paper source code, tests, build system references, and Paper backward-compatibility branches in shared code. Deleted Paper-only source files: - ReactNativeRenderer.js, ReactNativeInjection.js, ReactFiberConfigNative.js - ReactNativeComponentTree.js, ReactNativeEventEmitter.js - ReactNativeFiberHostComponent.js, ReactNativeGlobalResponderHandler.js - ReactNativeAttributePayload.js, NativeMethodsMixinUtils.js - ReactFiberConfig.native.js (reconciler fork) - index.js (Paper entry point) Cleaned up shared files: - ReactNativePublicCompat.js: removed _nativeTag checks, UIManager/ legacySendAccessibilityEvent Paper fallbacks - ReactNativeFiberInspector.js: removed getInspectorDataForViewTag, UIManager.measure fallback, Paper branch in getInspectorDataForViewAtPoint - ReactFiberConfigFabric.js: removed _nativeTag backward compat in getPublicInstance, removed getInspectorDataForViewTag from devtools config - ReactNativeTypes.js: removed ReactNativeType (Paper API type) Cleaned up build system: - inlinedHostConfigs.js: removed shortName 'native' config - forks.js: removed dead 'react-native-renderer' case - Deleted ReactNative.js shim and Paper-only test mocks ## How did you test this change? Manually synced the renderer to RN and passed all Fantom tests. Manually verified the differences in the generated `ReactFabric-dev.js` file. Only Paper compat logic has been removed. <details> <summary>diff</summary> ```diff --- /tmp/react-fabric-baseline/ReactFabric-dev.js 2026-04-16 16:42:42 +++ build/react-native/implementations/ReactFabric-dev.js 2026-04-16 18:08:43 @@ -30,43 +30,19 @@ : emptyObject; } function createHierarchy(fiberHierarchy) { - return fiberHierarchy.map(function (fiber$jscomp$0) { + return fiberHierarchy.map(function (fiber) { return { - name: getComponentNameFromType(fiber$jscomp$0.type), + name: getComponentNameFromType(fiber.type), getInspectorData: function () { return { - props: getHostProps(fiber$jscomp$0), + props: getHostProps(fiber), measure: function (callback) { - var hostFiber = findCurrentHostFiber(fiber$jscomp$0); - if ( - (hostFiber = - null != hostFiber && - null !== hostFiber.stateNode && - hostFiber.stateNode.node) - ) + var hostFiber = findCurrentHostFiber(fiber); + (hostFiber = + null != hostFiber && + null !== hostFiber.stateNode && + hostFiber.stateNode.node) && nativeFabricUIManager.measure(hostFiber, callback); - else { - hostFiber = ReactNativePrivateInterface.UIManager; - var JSCompiler_temp_const = hostFiber.measure, - JSCompiler_inline_result; - a: { - for (var fiber = fiber$jscomp$0; fiber; ) { - null !== fiber.stateNode && - 5 === fiber.tag && - (JSCompiler_inline_result = findNodeHandle( - fiber.stateNode - )); - if (JSCompiler_inline_result) break a; - fiber = fiber.child; - } - JSCompiler_inline_result = null; - } - return JSCompiler_temp_const.call( - hostFiber, - JSCompiler_inline_result, - callback - ); - } } }; } @@ -1805,18 +1781,6 @@ } return null; } - function doesFiberContain(parentFiber, childFiber) { - for ( - var parentFiberAlternate = parentFiber.alternate; - null !== childFiber; - - ) { - if (childFiber === parentFiber || childFiber === parentFiberAlternate) - return !0; - childFiber = childFiber.return; - } - return !1; - } function traverseVisibleHostChildren( child, searchWithinHosts, @@ -16986,44 +16950,6 @@ function getCurrentFiberForDevTools() { return current; } - function findNodeHandle(componentOrHandle) { - var owner = current; - null !== owner && - isRendering && - null !== owner.stateNode && - (owner.stateNode._warnedAboutRefsInRender || - console.error( - "%s is accessing findNodeHandle inside its render(). render() should be a pure function of props and state. It should never access something that requires stale data from the previous render, such as refs. Move this logic to componentDidMount and componentDidUpdate instead.", - getComponentNameFromType(owner.type) || "A component" - ), - (owner.stateNode._warnedAboutRefsInRender = !0)); - if (null == componentOrHandle) return null; - if ("number" === typeof componentOrHandle) return componentOrHandle; - if (componentOrHandle._nativeTag) return componentOrHandle._nativeTag; - if ( - null != componentOrHandle.canonical && - null != componentOrHandle.canonical.nativeTag - ) - return componentOrHandle.canonical.nativeTag; - if ( - (owner = - ReactNativePrivateInterface.getNativeTagFromPublicInstance( - componentOrHandle - )) - ) - return owner; - componentOrHandle = findHostInstanceWithWarning( - componentOrHandle, - "findNodeHandle" - ); - return null == componentOrHandle - ? componentOrHandle - : null != componentOrHandle._nativeTag - ? componentOrHandle._nativeTag - : ReactNativePrivateInterface.getNativeTagFromPublicInstance( - componentOrHandle - ); - } function getNodeFromInternalInstanceHandle(internalInstanceHandle) { return ( internalInstanceHandle && @@ -17134,12 +17060,9 @@ } return instance.canonical.publicInstance; } - return null != instance.containerInfo && - null != instance.containerInfo.publicInstance + return null != instance.containerInfo ? instance.containerInfo.publicInstance - : null != instance._nativeTag - ? instance - : null; + : null; } function getPublicInstanceFromHostFiber(fiber) { fiber = getPublicInstance(fiber.stateNode); @@ -18017,7 +17940,6 @@ DefaultEventPriority = 32, IdleEventPriority = 268435456, searchTarget = null, - instanceCache = new Map(), bind = Function.prototype.bind, valueStack = []; var fiberStack = []; @@ -20041,24 +19963,19 @@ _nativeFabricUIManage.unstable_getCurrentEventPriority, extraDevToolsConfig = { getInspectorDataForInstance: getInspectorDataForInstance, - getInspectorDataForViewTag: function (viewTag) { - viewTag = instanceCache.get(viewTag) || null; - return getInspectorDataForInstance(viewTag); - }, getInspectorDataForViewAtPoint: function ( inspectedView, locationX, locationY, callback ) { - var closestInstance = null, - fabricNode = - ReactNativePrivateInterface.getNodeFromPublicInstance( - inspectedView - ); - fabricNode + var closestInstance = null; + (inspectedView = + ReactNativePrivateInterface.getNodeFromPublicInstance( + inspectedView + )) ? nativeFabricUIManager.findNodeAtPoint( - fabricNode, + inspectedView, locationX, locationY, function (internalInstanceHandle) { @@ -20109,32 +20026,9 @@ } } ) - : null != inspectedView._internalFiberInstanceHandleDEV - ? ReactNativePrivateInterface.UIManager.findSubviewIn( - findNodeHandle(inspectedView), - [locationX, locationY], - function (nativeViewTag, left, top, width, height) { - var inspectorData = getInspectorDataForInstance( - instanceCache.get(nativeViewTag) || null - ); - callback( - assign({}, inspectorData, { - pointerY: locationY, - frame: { - left: left, - top: top, - width: width, - height: height - }, - touchedViewTag: nativeViewTag, - closestPublicInstance: nativeViewTag - }) - ); - } - ) - : console.error( - "getInspectorDataForViewAtPoint expects to receive a host component" - ); + : console.error( + "getInspectorDataForViewAtPoint expects to receive a host component" + ); } }, getViewConfigForType = @@ -20368,23 +20262,12 @@ ); }; exports.dispatchCommand = function (handle, command, args) { - var nativeTag = - null != handle._nativeTag - ? handle._nativeTag - : ReactNativePrivateInterface.getNativeTagFromPublicInstance(handle); - null == nativeTag - ? console.error( + handle = ReactNativePrivateInterface.getNodeFromPublicInstance(handle); + null != handle + ? nativeFabricUIManager.dispatchCommand(handle, command, args) + : console.error( "dispatchCommand was called with a ref that isn't a native component. Use React.forwardRef to get access to the underlying native component" - ) - : ((handle = - ReactNativePrivateInterface.getNodeFromPublicInstance(handle)), - null != handle - ? nativeFabricUIManager.dispatchCommand(handle, command, args) - : ReactNativePrivateInterface.UIManager.dispatchViewManagerCommand( - nativeTag, - command, - args - )); + ); }; exports.findHostInstance_DEPRECATED = function (componentOrHandle) { var owner = current; @@ -20402,14 +20285,46 @@ : componentOrHandle.canonical && componentOrHandle.canonical.publicInstance ? componentOrHandle.canonical.publicInstance - : componentOrHandle._nativeTag - ? componentOrHandle - : findHostInstanceWithWarning( - componentOrHandle, - "findHostInstance_DEPRECATED" - ); + : findHostInstanceWithWarning( + componentOrHandle, + "findHostInstance_DEPRECATED" + ); }; - exports.findNodeHandle = findNodeHandle; + exports.findNodeHandle = function (componentOrHandle) { + var owner = current; + null !== owner && + isRendering && + null !== owner.stateNode && + (owner.stateNode._warnedAboutRefsInRender || + console.error( + "%s is accessing findNodeHandle inside its render(). render() should be a pure function of props and state. It should never access something that requires stale data from the previous render, such as refs. Move this logic to componentDidMount and componentDidUpdate instead.", + getComponentNameFromType(owner.type) || "A component" + ), + (owner.stateNode._warnedAboutRefsInRender = !0)); + if (null == componentOrHandle) return null; + if ("number" === typeof componentOrHandle) return componentOrHandle; + if ( + null != componentOrHandle.canonical && + null != componentOrHandle.canonical.nativeTag + ) + return componentOrHandle.canonical.nativeTag; + if ( + (owner = + ReactNativePrivateInterface.getNativeTagFromPublicInstance( + componentOrHandle + )) + ) + return owner; + componentOrHandle = findHostInstanceWithWarning( + componentOrHandle, + "findNodeHandle" + ); + return null == componentOrHandle + ? componentOrHandle + : ReactNativePrivateInterface.getNativeTagFromPublicInstance( + componentOrHandle + ); + }; exports.getNodeFromInternalInstanceHandle = getNodeFromInternalInstanceHandle; exports.getPublicInstanceFromInternalInstanceHandle = function ( @@ -20433,14 +20348,6 @@ : null; }; exports.isChildPublicInstance = function (parentInstance, childInstance) { - if ( - parentInstance._internalFiberInstanceHandleDEV && - childInstance._internalFiberInstanceHandleDEV - ) - return doesFiberContain( - parentInstance._internalFiberInstanceHandleDEV, - childInstance._internalFiberInstanceHandleDEV - ); parentInstance = ReactNativePrivateInterface.getInternalInstanceHandleFromPublicInstance( parentInstance @@ -20449,9 +20356,27 @@ ReactNativePrivateInterface.getInternalInstanceHandleFromPublicInstance( childInstance ); - return null != parentInstance && null != childInstance - ? doesFiberContain(parentInstance, childInstance) - : !1; + if (null != parentInstance && null != childInstance) { + a: { + for ( + var parentFiberAlternate = parentInstance.alternate; + null !== childInstance; + + ) { + if ( + childInstance === parentInstance || + childInstance === parentFiberAlternate + ) { + parentInstance = !0; + break a; + } + childInstance = childInstance.return; + } + parentInstance = !1; + } + return parentInstance; + } + return !1; }; exports.render = function ( element, @@ -20521,22 +20446,12 @@ return element; }; exports.sendAccessibilityEvent = function (handle, eventType) { - var nativeTag = - null != handle._nativeTag - ? handle._nativeTag - : ReactNativePrivateInterface.getNativeTagFromPublicInstance(handle); - null == nativeTag - ? console.error( + handle = ReactNativePrivateInterface.getNodeFromPublicInstance(handle); + null != handle + ? nativeFabricUIManager.sendAccessibilityEvent(handle, eventType) + : console.error( "sendAccessibilityEvent was called with a ref that isn't a native component. Use React.forwardRef to get access to the underlying native component" - ) - : ((handle = - ReactNativePrivateInterface.getNodeFromPublicInstance(handle)), - null != handle - ? nativeFabricUIManager.sendAccessibilityEvent(handle, eventType) - : ReactNativePrivateInterface.legacySendAccessibilityEvent( - nativeTag, - eventType - )); + ); }; exports.stopSurface = function (containerTag) { var root = roots.get(containerTag); ``` </details>	2026-04-16 18:34:03 +01:00
Sebastian "Sebbie" Silbermann	00f063c31d	[test] Make enableSuspenseyImages dynamic (#36274)	2026-04-15 18:11:27 +02:00
Rubén Norte	0418c8a8b6	[RN] Move new event dispatching pipeline to RN (#36266) ... ## Summary We found a bug in the logic in https://github.com/facebook/react/pull/36253 and we realized it's very inconvenient to iterate on the implementation when it's in this repository, as we're forced to then synchronize it to RN to test changes. This moves the entire implementation to RN for simplicity and also to simplify some clean ups in the future (like removing `top` prefixes from native event types). ## How did you test this change? The changes are gated. Will test e2e in RN.	2026-04-14 18:10:33 +01:00
Rubén Norte	568244232e	[react-native-renderer] EventTarget-based event dispatching (#36253) ... ## Summary Set up the experiment to migrate event dispatching in the React Native renderer to be based on the native EventTarget API. Behind the `enableNativeEventTargetEventDispatching` flag, events are dispatched through `dispatchTrustedEvent` instead of the legacy plugin system. Regular event handler props are NOT registered via addEventListener at commit time. Instead, a hook on EventTarget (`EVENT_TARGET_GET_DECLARATIVE_LISTENER_KEY`) extracts handlers from `canonical.currentProps` at dispatch time, shifting cost from every render to only when events fire. The hook is overridden in ReactNativeElement to look up the prop name via a reverse mapping from event names (built lazily from the view config registry). Responder events bypass EventTarget entirely. `negotiateResponder` walks the fiber tree directly (capture then bubble phase), calling handlers from `canonical.currentProps` and checking return values inline. Lifecycle events (`responderGrant`, `responderMove`, etc.) call handlers directly from props and inspect return values — `onResponderGrant` returning `true` blocks native responder, `onResponderTerminationRequest` returning `false` refuses termination. This eliminates all commit-time cost for responder events (no wrappers, no addEventListener, no `responderWrappers` on canonical). ## How did you test this change? Flow Tested e2e in RN using Fantom tests (that will land after this).	2026-04-14 12:43:41 +01:00
Ruslan Lesiutin	fef12a01c8	fix: explicitly warn for infinite loops discovered only via enableInfiniteRenderLoopDetection (#36195) ... My change in https://github.com/facebook/react/pull/35999 did not cover all possible scenarios for emitting a warning, instead of throwing. The instrumentation not only enables the identification for the infinite loop via execution context checks, but also adds the check to more lifecycle methods, like `markRootPinged` and `markRootUpdated`. See the newly added test to understand a potential scenario. Before the fix, the error would be thrown: <img width="1192" height="424" alt="Screenshot 2026-04-08 at 17 21 51" src="https://github.com/user-attachments/assets/ba8ea379-0271-4938-ae45-e37ee75e1963" /> With the current changes, the warning is logged with `console.error`.	2026-04-13 12:28:42 -04:00
Eugene Choi	705268dcd1	Fix require('ReactFeatureFlags') in eslint-plugin-react-hooks www build (#36243) ... PR #35951 added FB_WWW_DEV builds for eslint-plugin-react-hooks to get www-specific feature flag values. However, the FB_WWW build uses the full ReactFeatureFlags.www.js fork, which contains: const dynamicFeatureFlags = require('ReactFeatureFlags'); This is a www Haste module that only exists in the www runtime. Rollup can't tree-shake CJS require() calls (they're assumed side-effectful), so the bare require('ReactFeatureFlags') survives in the build output even though the eslint plugin only uses the static eprh_* exports. When the built artifact is synced to www at scripts/lint/eslint/rules/eslint-plugin-react-hooks/index.js, Node.js fails with "Cannot find module 'ReactFeatureFlags'" because Haste modules aren't available in the Node.js lint environment. Create a dedicated fork (ReactFeatureFlags.eslint-plugin.www.js) that exports only the static eprh_* flags with www values, without the require('ReactFeatureFlags') dependency. Wire it up in forks.js for the eslint-plugin-react-hooks entry point. <!-- Thanks for submitting a pull request! We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory. Before submitting a pull request, please make sure the following is done: 1. Fork [the repository](https://github.com/facebook/react) and create your branch from `main`. 2. Run `yarn` in the repository root. 3. If you've fixed a bug or added code that should be tested, add tests! 4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch TestName` is helpful in development. 5. Run `yarn test --prod` to test in the production environment. It supports the same options as `yarn test`. 6. If you need a debugger, run `yarn test --debug --watch TestName`, open `chrome://inspect`, and press "Inspect". 7. Format your code with [prettier](https://github.com/prettier/prettier) (`yarn prettier`). 8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only check changed files. 9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`). 10. If you haven't already, complete the CLA. Learn more about contributing: https://reactjs.org/docs/how-to-contribute.html --> Co-authored-by: Eugene Choi <eugenechoi@meta.com>	2026-04-09 12:14:54 -04:00
Jack Pope	733d3aaf99	Fix FB_WWW eprh bundle dev guard (#36238) ... We use FB_WWW bundle to inject internal feature flag values, but need to use NODE guard type because this is a node script -- __DEV__ is breaking internal builds Follow up to https://github.com/facebook/react/pull/35951	2026-04-08 16:12:35 -04:00
Sebastian "Sebbie" Silbermann	404b38c764	[Flight] Add more cycle protections (#36236)	2026-04-08 21:01:27 +02:00
Dmitrii	808e7ed8e2	[compiler] Fix set-state-in-effect false negative with NewExpression default param (#36107) ... ## Summary Fixes #36101 When a component function has a destructured prop with a `NewExpression` default value (e.g. `{ value = new Number() }`), the React Compiler bails out during HIR construction when trying to lower the default value via `lowerReorderableExpression`. This causes `validateNoSetStateInEffects` to never run, silently suppressing the `set-state-in-effect` diagnostic. **Root cause:** `isReorderableExpression` did not have a case for `NewExpression`, so it fell through to the `default: return false` branch. `lowerReorderableExpression` then recorded a `Todo` error and aborted compilation of the function before any validation passes ran. **Fix:** Add a `NewExpression` case to `isReorderableExpression` that mirrors the existing `CallExpression` case — the expression is safe to reorder when the callee and all arguments are themselves reorderable (e.g. global identifiers and literals). ## How did you test this change? Added a new compiler fixture `invalid-setState-in-useEffect-new-expression-default-param` that reproduces the bug from the issue. The fixture verifies that the `EffectSetState` diagnostic is correctly emitted for a component with a `NewExpression` default prop value. All 1720 compiler snapshot tests pass.	2026-04-08 14:52:49 -04:00
Sebastian "Sebbie" Silbermann	0c44b96e97	[DevTools] Remove spurious warnings when creating Suspense timeline from a Transition (#36133)	2026-04-08 18:49:35 +02:00
Hendrik Liebau	1b45e24392	Add Flight SSR benchmark fixture (#36180) ... This PR adds a benchmark fixture for measuring the performance overhead of the React Server Components (RSC) Flight rendering compared to plain Fizz server-side rendering. ### Motivation Performance discussions around RSC (e.g. #36143, #35125) have highlighted the need for reproducible benchmarks that accurately measure the cost that Flight adds on top of Fizz. This fixture provides multiple benchmark modes that can be used to track performance improvements across commits, compare Node vs Edge (web streams) overhead, and identify bottlenecks in Flight serialization and deserialization. ### What it measures The benchmark renders a dashboard app with ~25 components (16 client components), 200 product rows with nested data (~325KB Flight payload), and ~250 Suspense boundaries in the async variant. It compares 8 render variants: Fizz-only and Flight+Fizz, across Node and Edge stream APIs, with both synchronous and asynchronous apps. ### Benchmark modes - **`yarn bench`** runs a sequential in-process benchmark with realistic Flight script injection (tee + `TransformStream`/`Transform` buffered injection), matching what real frameworks do when inlining the RSC payload into the HTML response for hydration. - **`yarn bench:bare`** runs the same benchmark without script injection, isolating the React-internal rendering cost. This is best for tracking changes to Flight serialization or Fizz rendering. - **`yarn bench:server`** starts an HTTP server and uses `autocannon` to measure real req/s at `c=1` and `c=10`. The `c=1` results provide a clean signal for tracking React-internal changes, while `c=10` reflects throughput under concurrent load. - **`yarn bench:concurrent`** runs an in-process concurrent benchmark with 50 in-flight renders via `Promise.all`, measuring throughput without HTTP overhead. - **`yarn bench:profile`** collects CPU profiles via the V8 inspector and reports the top functions by self-time along with GC pause data. - **`yarn start`** starts the HTTP server for manual browser testing. Appending `.rsc` to any Flight URL serves the raw Flight payload. ### Key findings during development On Node 22, the Flight+Fizz overhead compared to Fizz-only rendering is roughly: - **Without script injection** (`bench:bare`): ~2.2x for sync, ~1.3x for async - **With script injection** (`bench:server`, c=1): ~2.9x for sync, ~1.8x for async - **Edge vs Node** adds another ~30% for sync and ~10% for async, driven by the stream plumbing for script injection (tee + `TransformStream` buffering) The async variant better represents real-world applications where server components fetch data asynchronously. Its lower overhead reflects the fact that Flight serialization and Fizz rendering can overlap with I/O wait times, making the added Flight cost a smaller fraction of total request time. The benchmark also revealed that the Edge vs Node gap is negligible for Fizz-only rendering (~1-2%) but grows to ~15% for Flight+Fizz sync even without script injection. With script injection (tee + `TransformStream` buffering), the gap roughly doubles to ~30% for sync. The async variants show smaller gaps (~5% without, ~10% with injection).	2026-04-02 19:00:28 +02:00
Bodhi Russell Silberling	80b1cab397	Fix typos: occured->occurred, teh->the, accomodate->accommodate (#35616) ... Fixed spelling errors in comments and error messages: - Fixed 'occured' -> 'occurred' in ReactAsyncActions-test.js - Fixed 'teh' -> 'the' in ReactFiberConfigDOM.js - Fixed 'occured' -> 'occurred' in ErrorBoundary.js - Fixed 'accomodate' -> 'accommodate' in InferMutationAliasingEffects.ts <!-- Thanks for submitting a pull request! We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory. Before submitting a pull request, please make sure the following is done: 1. Fork [the repository](https://github.com/facebook/react) and create your branch from `main`. 2. Run `yarn` in the repository root. 3. If you've fixed a bug or added code that should be tested, add tests! 4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch TestName` is helpful in development. 5. Run `yarn test --prod` to test in the production environment. It supports the same options as `yarn test`. 6. If you need a debugger, run `yarn test --debug --watch TestName`, open `chrome://inspect`, and press "Inspect". 7. Format your code with [prettier](https://github.com/prettier/prettier) (`yarn prettier`). 8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only check changed files. 9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`). 10. If you haven't already, complete the CLA. Learn more about contributing: https://reactjs.org/docs/how-to-contribute.html --> ## Summary <!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? --> ## How did you test this change? <!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes the user interface. How exactly did you verify that your PR solves the issue you wanted to solve? If you leave this empty, your PR will very likely be closed. -->	2026-03-31 16:01:58 -07:00
ALİ DENİZ TARTMA	044d56f390	docs: fix typos and improve abbreviation usage in DESIGN_GOALS.md (#36170) ... Hi! While reviewing the React Compiler documentation, I noticed a few minor issues in DESIGN_GOALS.md: - Fixed a typo: `outweight` → `outweigh` in the Non-Goals section. - Updated all instances of `ie` to the standard `i.e.` for better consistency and clarity throughout the document. Happy to contribute! <!-- Thanks for submitting a pull request! We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory. Before submitting a pull request, please make sure the following is done: 1. Fork [the repository](https://github.com/facebook/react) and create your branch from `main`. 2. Run `yarn` in the repository root. 3. If you've fixed a bug or added code that should be tested, add tests! 4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch TestName` is helpful in development. 5. Run `yarn test --prod` to test in the production environment. It supports the same options as `yarn test`. 6. If you need a debugger, run `yarn test --debug --watch TestName`, open `chrome://inspect`, and press "Inspect". 7. Format your code with [prettier](https://github.com/prettier/prettier) (`yarn prettier`). 8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only check changed files. 9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`). 10. If you haven't already, complete the CLA. Learn more about contributing: https://reactjs.org/docs/how-to-contribute.html --> ## Summary Fixed a typo (outweight -> outweigh) and standardized abbreviation usage (ie -> i.e.) in the DESIGN_GOALS.md file for the React Compiler documentation. This improves the overall professionalism and readability of the document. ## How did you test this change? This is a documentation-only change. I verified the formatting and consistency of the edits.	2026-03-30 16:25:51 -07:00
mofeiZ	2c2fd9d12c	[compiler][playground] parse compiler configs using json5 (#36159) ... Compiler config parsing is currently done with new Function(...) which is a XSS vulnerability. Replacing this with json parsing for safety reasons. Almost all compiler options (except for moduleTypeProvider) are json compatible, so this isn't a big change to capabilities. Previously created playground URLs with non-default configs may not be compatible with this change, but we should be able to get the correct config manually (by reading the JS version)	2026-03-30 13:04:50 -04:00
Sebastian "Sebbie" Silbermann	74568e8627	[Flight] Transport AggregateErrors.errors (#36156)	2026-03-28 18:18:21 -07:00
Andrew Clark	9627b5a1ca	[Fiber] Fix context propagation into Suspense fallbacks (#36160) ... ## Summary When a context value changes above a Suspense boundary that is showing its fallback, context consumers inside the fallback do not re-render — they display stale values. `propagateContextChanges`, upon encountering a suspended Suspense boundary, marks the boundary for retry but stops traversing into its children entirely (`nextFiber = null`). This skips both the hidden primary subtree (intentional — those fibers may not exist) and the visible fallback subtree (a bug — those fibers are committed and visible to the user). The fix skips the primary OffscreenComponent and continues traversal into the FallbackFragment, so fallback context consumers are found and marked for re-render. In practice this often goes unnoticed because it's uncommon to read context inside a Suspense fallback, and when some other update (like a prop change) flows into the fallback it sidesteps the propagation path entirely. React Compiler makes the bug more likely to surface since it memoizes more aggressively, reducing the chance of an incidental re-render masking the stale value. ## Test plan - Added regression test `'context change propagates to Suspense fallback (memo boundary)'` in `ReactContextPropagation-test.js` - Verified the test fails without the fix and passes with it - All existing context propagation, Suspense, memo, and hooks tests pass	2026-03-27 18:04:53 -04:00
Pavan Shinde	f944b4c535	Fix typos in comments (#35701) ... <!-- Thanks for submitting a pull request! We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory. Before submitting a pull request, please make sure the following is done: 1. Fork [the repository](https://github.com/facebook/react) and create your branch from `main`. 2. Run `yarn` in the repository root. 3. If you've fixed a bug or added code that should be tested, add tests! 4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch TestName` is helpful in development. 5. Run `yarn test --prod` to test in the production environment. It supports the same options as `yarn test`. 6. If you need a debugger, run `yarn test --debug --watch TestName`, open `chrome://inspect`, and press "Inspect". 7. Format your code with [prettier](https://github.com/prettier/prettier) (`yarn prettier`). 8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only check changed files. 9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`). 10. If you haven't already, complete the CLA. Learn more about contributing: https://reactjs.org/docs/how-to-contribute.html --> ## Summary This PR fixes a few small spelling errors in comments across the codebase (`teh`→`the`, `occuring`→`occurring`, `occured`→`occurred`). No behavior changes. <!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? --> ## How did you test this change? <!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes the user interface. How exactly did you verify that your PR solves the issue you wanted to solve? If you leave this empty, your PR will very likely be closed. --> This is a comments-only change. I verified the diff is limited to comment text and does not affect logic or runtime behavior.	2026-03-27 14:55:10 -07:00
o-m12a	677818e4a2	Fix typos in tests and comments (#35627) ... <!-- Thanks for submitting a pull request! We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory. Before submitting a pull request, please make sure the following is done: 1. Fork [the repository](https://github.com/facebook/react) and create your branch from `main`. 2. Run `yarn` in the repository root. 3. If you've fixed a bug or added code that should be tested, add tests! 4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch TestName` is helpful in development. 5. Run `yarn test --prod` to test in the production environment. It supports the same options as `yarn test`. 6. If you need a debugger, run `yarn test --debug --watch TestName`, open `chrome://inspect`, and press "Inspect". 7. Format your code with [prettier](https://github.com/prettier/prettier) (`yarn prettier`). 8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only check changed files. 9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`). 10. If you haven't already, complete the CLA. Learn more about contributing: https://reactjs.org/docs/how-to-contribute.html --> ## Summary <!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? --> I just fixed typos as followings. - `succesful` → `successful` - `becuase` → `because` - `enought` → `enough` - `defualt` → `default` ## How did you test this change? <!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes the user interface. How exactly did you verify that your PR solves the issue you wanted to solve? If you leave this empty, your PR will very likely be closed. --> This PR only includes test case description, dummy strings for test, and comments updates, so it has no impact on runtime behavior. Therefore, I manually reviewed changed texts to ensure correctness.	2026-03-27 14:53:32 -07:00
Bodhi Russell Silberling	2233b7d728	Fix typos: explicitlyu->explicitly, intialized->initialized (#35621) ... Fixed spelling errors: - Fixed 'explicitlyu' -> 'explicitly' in compiler/CLAUDE.md - Fixed 'intialized' -> 'initialized' in InferReactiveScopeVariables.ts (comment) - Fixed 'intialized' -> 'initialized' in InferMutationAliasingEffects.ts (error message) <!-- Thanks for submitting a pull request! We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory. Before submitting a pull request, please make sure the following is done: 1. Fork [the repository](https://github.com/facebook/react) and create your branch from `main`. 2. Run `yarn` in the repository root. 3. If you've fixed a bug or added code that should be tested, add tests! 4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch TestName` is helpful in development. 5. Run `yarn test --prod` to test in the production environment. It supports the same options as `yarn test`. 6. If you need a debugger, run `yarn test --debug --watch TestName`, open `chrome://inspect`, and press "Inspect". 7. Format your code with [prettier](https://github.com/prettier/prettier) (`yarn prettier`). 8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only check changed files. 9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`). 10. If you haven't already, complete the CLA. Learn more about contributing: https://reactjs.org/docs/how-to-contribute.html --> ## Summary <!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? --> ## How did you test this change? <!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes the user interface. How exactly did you verify that your PR solves the issue you wanted to solve? If you leave this empty, your PR will very likely be closed. -->	2026-03-27 14:52:23 -07:00
Bodhi Russell Silberling	ba833da405	Fix typo: accomodate -> accommodate (#35623) ... Fixed spelling error in comment: - Fixed 'accomodate' -> 'accommodate' in InferMutationAliasingEffects.ts <!-- Thanks for submitting a pull request! We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory. Before submitting a pull request, please make sure the following is done: 1. Fork [the repository](https://github.com/facebook/react) and create your branch from `main`. 2. Run `yarn` in the repository root. 3. If you've fixed a bug or added code that should be tested, add tests! 4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch TestName` is helpful in development. 5. Run `yarn test --prod` to test in the production environment. It supports the same options as `yarn test`. 6. If you need a debugger, run `yarn test --debug --watch TestName`, open `chrome://inspect`, and press "Inspect". 7. Format your code with [prettier](https://github.com/prettier/prettier) (`yarn prettier`). 8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only check changed files. 9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`). 10. If you haven't already, complete the CLA. Learn more about contributing: https://reactjs.org/docs/how-to-contribute.html --> ## Summary <!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? --> ## How did you test this change? <!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes the user interface. How exactly did you verify that your PR solves the issue you wanted to solve? If you leave this empty, your PR will very likely be closed. -->	2026-03-27 14:51:37 -07:00
Jack Pope	3cb2c42013	Add ReactFeatureFlags support to eprh (#35951) ... We're currently hardcoding experimental options to `eslint-plugin-react-hooks`. This blocks the release on features that might not be ready. This PR extends the ReactFeatureFlag infra to support flags for `eslint-plugin-react-hooks`. An alternative would be to create a separate flag system for build tools, but for now we have a small number of these and reusing existing infra seems like the simplest approach. I ran a full `yarn build` and checked the output resolved the flag values as expected: _build/oss-stable-semver/eslint-plugin-react-hooks/cjs/eslint-plugin-react-hooks.development.js_ ```js var eprh_enableUseKeyedStateCompilerLint = false; var eprh_enableVerboseNoSetStateInEffectCompilerLint = false; var eprh_enableExhaustiveEffectDependenciesCompilerLint = 'off'; ``` _build/facebook-www/ESLintPluginReactHooks-dev.classic.js_ ```js var eprh_enableUseKeyedStateCompilerLint = true; var eprh_enableVerboseNoSetStateInEffectCompilerLint = true; var eprh_enableExhaustiveEffectDependenciesCompilerLint = 'extra-only'; ``` --------- Co-authored-by: lauren <lauren@anysphere.co>	2026-03-24 23:13:27 -07:00
Rahul salunke	c0c29e8906	Fix typos in the documentation (#35439) ... <!-- Thanks for submitting a pull request! We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory. Before submitting a pull request, please make sure the following is done: 1. Fork [the repository](https://github.com/facebook/react) and create your branch from `main`. 2. Run `yarn` in the repository root. 3. If you've fixed a bug or added code that should be tested, add tests! 4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch TestName` is helpful in development. 5. Run `yarn test --prod` to test in the production environment. It supports the same options as `yarn test`. 6. If you need a debugger, run `yarn test --debug --watch TestName`, open `chrome://inspect`, and press "Inspect". 7. Format your code with [prettier](https://github.com/prettier/prettier) (`yarn prettier`). 8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only check changed files. 9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`). 10. If you haven't already, complete the CLA. Learn more about contributing: https://reactjs.org/docs/how-to-contribute.html --> ## Summary <!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? --> So in this PR the typo mistakes in the docs are corrected such as the 1. **Ie** it should be **"i.e"**. 2. **errros** should be the **"errors"**. 3. **consdier** should be the **"consider"**. 4. **CreatFrom** should be **"CreateForm"**. ## How did you test this change? <!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes the user interface. How exactly did you verify that your PR solves the issue you wanted to solve? If you leave this empty, your PR will very likely be closed. --> I verified the fixes by reviewing the updated files locally to ensure the corrected terms appear consistently and accurately in the documentation. --------- Co-authored-by: Yummy_Bacon5 <68166338+YummyBacon5@users.noreply.github.com>	2026-03-24 16:09:59 -07:00
dan	c0d218f0f3	Fix useDeferredValue getting stuck (#36134) ... Fixes https://github.com/facebook/react/issues/35821 Written/debugged by Claude. ## Test Plan - Verify undoing the source fix fails the newly added test - Verify building a bundle with the fix solves https://github.com/gaearon/react-udv-bug/ repro	2026-03-24 00:49:05 +00:00
Ruslan Lesiutin	ed69815ceb	[DevTools] feat: display subtree for Activity and dim in hidden mode (#36094) ... With this change, Components panel will display subtree of the Activity. When it is in hidden mode, the subtree will be dimmed. Added Jest tests and a sandbox case to `react-devtools-shell`. Demo: https://github.com/user-attachments/assets/69a2e8d6-585d-4fcd-b57e-e9ae06d0a1b3	2026-03-23 14:29:38 +00:00
Ruslan Lesiutin	8b2e903a74	[DevTools] chore: extract getInternalReactConstants (#35986) ... The test is quite naive, but worth having as additional check for changes in this logic.	2026-03-20 14:17:15 +00:00
Zeya Peng	6a04c369f1	Enables Basic View Transition support for React Native Fabric renderer (#35764) ... ## Summary Enables Basic View Transition support for React Native Fabric renderer. **Implemented:** - Added FabricUIManager bindings for view transition methods: `applyViewTransitionName`, `startViewTransition` - Implemented `startViewTransition` with proper callback orchestration (mutation → layout → afterMutation → spawnedWork → passive) - Added fallback behavior that flushes work synchronously when Fabric's `startViewTransition` returns null (e.g., when the ViewTransition ReactNativeFeatureFlag is not enabled) - Added Flow type declarations for new FabricUIManager methods - Stubbed with `__DEV__` warnings for all the other view transition config functions that are not yet implemented This allows React Native apps using Fabric to leverage the View Transition API for coordinated animations during state transitions, with graceful degradation when the native side doesn't support it. Below are diagrams of proposed architecture in fabric, and observation of what/when config functions get called during a basic shared transition example <img width="2290" height="1529" alt="Untitled-2026-03-19-1240" src="https://github.com/user-attachments/assets/192c9169-bc25-449c-a33b-dfec67179e7f" /> ## How did you test this change? - [x] `yarn flow fabric` - Flow type checks pass - [x] `yarn lint` - Lint checks pass - [x] Manually tested in Android catalyst app with `enableViewTransition` and `enableViewTransitionForPersistenceMode `in `ReactFeatureFlags.test-renderer.native-fb.js` and View Transition enabled via ReactNativeFeatureFlag - [x] Verified in the minified `ReactFabric-dev.fb.js` that the 'shim' config functions are not included - [x] Verified fallback behavior logs warning in `__DEV__` and flushes work synchronously when ViewTransition flag isn't enabled in Fabric	2026-03-19 17:58:29 -04:00
Jack Pope	d594643e5e	Turn on enableViewTransition for RN FB build (#36106) ... Its now enabled everywhere other than keeping it dynamic in www	2026-03-19 14:51:37 -04:00
Ruslan Lesiutin	b4546cd0d4	[enableInfiniteRenderLoopDetection] Warn about potential infinite loop, instead of interrupting (#35999) ... The `enableInfiniteRenderLoopDetection` feature flag is currently disabled everywhere. When attempted to roll out this at Meta, we've observed multiple false-positives, where counter-based approach would interrupt the render that would've resolved at some later iteration. This change gates the scenarios that are only discovered with the instrumentation behind `enableInfiniteRenderLoopDetection` flag to warn about potential infinite loop, instead of throwing an error and hitting an error boundary. The main reason is to see if we can a signal on which possible area of scenarios this new approach to infinite loops covers. The gist of the approach is to ensure that we are still throwing error and breaking the infinite loop, if we were doing this without `enableInfiniteRenderLoopDetection` feature flag enabled. This will log multiple errors if there is an infinite loop, but this should be fine, and it also aligns with the pattern for warnings about passive effects infinite loop. I've validated that tests in `ReactUpdates-test.js` are passing independently whether the feature flag is enabled or not.	2026-03-18 14:11:30 +00:00
Kid	3f0b9e61c4	Update CSS shorthand property list (#35636)	2026-03-17 14:54:06 +01:00
Sebastian "Sebbie" Silbermann	12ba7d8129	[Flight Reply] Early bailout if backing entry for Blob deserialization is not a Blob (#36055) ... Co-authored-by: Hendrik Liebau <mail@hendrik-liebau.de>	2026-03-17 11:50:27 +01:00
Jack Pope	c80a075095	Fix focus set for delegated and already focused elements (#36010) ... I found two focus bugs when working on documentation for Fragment Refs. 1) If an element delegates focus handling, it will return false from setFocusIfFocusable even though a focus event has occured on a different element. The fix for this is a document level event listener rather than only listening on the current element. For example, if you have a form with multiple nested label>inputs. Calling focus on the label will focus its input but not fire an event on the label. setFocusIfFocusable returns false and you end up continuing to attempt focus down the form tree. 2) If an element is already focused, setFocusIfFocusable will return false. The fix for this is checking the document's activeElement with an early return. In the same form example, if the first input is already focused and you call fragmentInstance.focus() at the form level, the second input would end up getting focused since the focus event on the first is not triggered.	2026-03-12 14:36:28 -07:00
Ruslan Lesiutin	8f41506054	[DevTools] fix: don't show empty suspended by section (#36011) ... The potential paddings and margins for the empty block are already handled via CSS selectors.	2026-03-12 14:19:21 -07:00
Hendrik Liebau	5e9eedb578	[Flight] Clear chunk reason after successful module initialization (#36024) ... When `requireModule` triggers a reentrant `readChunk` on the same module chunk, the reentrant call can fail and set `chunk.reason` to an error. After the outer `requireModule` succeeds, the chunk transitions to initialized but retains the stale error as `reason`. When the Flight response stream later closes, it iterates all chunks and expects `reason` on initialized chunks to be a `FlightStreamController`. Since the stale `reason` is an `Error` object instead, calling `chunk.reason.error()` crashes with `TypeError: chunk.reason.error is not a function`. The reentrancy can occur when module evaluation synchronously triggers `readChunk` on the same chunk — for example, when code called during evaluation tries to resolve the client reference for the module that is currently being initialized. In Fizz SSR, `captureOwnerStack()` can trigger this because it constructs component stacks that resolve lazy client references via `readChunk`. The reentrant `requireModule` call returns the module's namespace object, but since the module is still being evaluated, accessing the export binding throws a TDZ (Temporal Dead Zone) `ReferenceError`. This sets the chunk to the errored state, and the `ReferenceError` becomes the stale `chunk.reason` after the outer call succeeds. This scenario is triggered in Next.js when a client module calls an instrumented API like `Math.random()` in module scope, which synchronously invokes `captureOwnerStack()`.	2026-03-12 19:17:24 +01:00