fix(shared): wrap addObjectToProperties in try-catch to handle cross-origin SecurityError#36451
fix(shared): wrap addObjectToProperties in try-catch to handle cross-origin SecurityError#36451sleitor wants to merge 1 commit into
Conversation
|
Fixed the CI failure ( Root cause: The original test used Fix (this force-push):
In production, |
…origin SecurityError In React 19.2 DEV builds, logComponentRender (called from commitPassiveMountOnFiber) calls addObjectToProperties which performs an unguarded 'for...in' over every prop value. When a component receives a cross-origin Window object (e.g. iframe.contentWindow with srcdoc='' / null origin) as a prop, the enumeration throws SecurityError in browsers that enforce the same-origin policy. This SecurityError propagates out of the commit phase and leaves the work-in-progress fiber broken, causing all subsequent renders to throw 'Should not already be working.' and making the UI completely unresponsive. Fix: - Wrap the 'for...in' loop in addObjectToProperties with try-catch. On SecurityError, show '[CrossOriginObject]' as a placeholder so the render-logger degrades gracefully without corrupting the fiber. - Wrap the 'in' / hasOwnProperty checks in readReactElementTypeof with try-catch so 2795888typeof access never escapes either. Both are DEV-only diagnostic paths and must not affect production builds or corrupt fiber state when iterating untrusted props. Repro: pass iframe.contentWindow (srcdoc iframe, null origin) as a prop to any component in a DEV Vite+React 19.2 app. Fixes facebook#36430
Recent Activity SummaryThe React repository has seen active contributions focused on stability and developer experience. Recent pull requests address cross-origin security errors in DEV builds, infinite loop detection in production useEffect hooks, and documentation consistency. These efforts demonstrate the community's commitment to improving React's robustness across both development and production environments. |
Recent Activity SummaryThe facebook/react repository has been actively addressing critical bugs and documentation improvements. Recent contributions include fixes for cross-origin SecurityError handling in DEV builds, infinite loop detection in production useEffect hooks, and standardization of contribution guide URLs. All three recent PRs focus on improving developer experience and production reliability. |
Recent Activity SummaryThe facebook/react repository shows active development with recent contributions focused on bug fixes and documentation improvements. The most recent pull requests address critical issues including cross-origin SecurityError handling in DEV builds (#36451), infinite loop detection in production builds (#36443), and documentation URL standardization (#36445). Community contributors are actively working on improving both the stability of React's internal mechanisms and the quality of its documentation. |
3 participants
Summary
In React 19.2 DEV builds,
logComponentRender(called fromcommitPassiveMountOnFiber) callsaddObjectToPropertieswhich performs an unguardedfor...inover every prop value. When a component receives a cross-originWindowobject (e.g.iframe.contentWindowwithsrcdoc=""/ null origin) as a prop, the enumeration throwsSecurityErrorin browsers that enforce the same-origin policy.This
SecurityErrorpropagates out of the commit phase and leaves the work-in-progress fiber broken, causing all subsequent renders to throwShould not already be working.and making the UI completely unresponsive.Root Cause
addObjectToPropertiesinpackages/shared/ReactPerformanceTrackProperties.jsrunsfor (const key in object)without any error guard. For a cross-originWindow(null origin iframe), browsers block property enumeration and throwSecurityError. Since this error is not caught, it escapes the commit phase and corrupts the fiber tree.Similarly,
readReactElementTypeofaccesses'2796107typeof' in valuewithout a guard, which can also throw for cross-origin objects.Fix
for...inloop inaddObjectToPropertieswith try-catch. On SecurityError, show[CrossOriginObject]as a placeholder so the render-logger degrades gracefully without corrupting the fiber.in/ hasOwnProperty checks inreadReactElementTypeofwith try-catch so$$typeofaccess never escapes either.Both are DEV-only diagnostic paths and must not affect production builds or corrupt fiber state when iterating untrusted props.
Test
Added a new test in
ReactPerformanceTrack-test.jsthat simulates a cross-originWindowvia a Proxy whoseownKeysandgetOwnPropertyDescriptortraps throw, verifying that:Fixes #36430