Render logger throws SecurityError on a cross-origin iframe, corrupting React's scheduler

[meirelon]

Summary

When a page mounts a cross-origin iframe, the devtools' render logger walks into it and throws a SecurityError. That leaves React's fiber scheduler in a bad state, and from then on controlled inputs stop committing anywhere on the page for the rest of that page load.

The visible symptom is not a devtools error — it's that typing into any <input> in the app silently does nothing. That makes it expensive to diagnose: the app looks fine, and the failure appears to be in whatever component you happen to be working on.

Versions

• @tanstack/react-devtools 0.10.7
• @tanstack/devtools-vite 0.8.0
• React 19, TanStack Start, Vite 8, dev mode only (devtools are import.meta.env.DEV-gated)

Reproduction

1. Mount <TanStackDevtools> in the root route, gated on import.meta.env.DEV.
2. Anywhere in the authenticated tree, mount a component that injects a cross-origin iframe. In our case it is the Spotify Web Playback SDK (https://sdk.scdn.co/spotify-player.js), which creates its own iframe.
3. Load any page under that tree in dev.
4. Type into any controlled input.

Observed console output, in order:

SecurityError: Failed to read a named property from 'Window': Blocked a frame with
origin "http://127.0.0.1:3939" from accessing a cross-origin frame.

then

Error: Should not already be working.

After the second error, controlled-input commits fail for the remainder of the page load — including inputs entirely unrelated to the iframe, such as a login form on a different route.

Workaround

Blocking the third-party script prevents the iframe from being created, and everything behaves normally:

await page.route('**sdk.scdn.co/**', (r) => r.abort())

Not mounting the iframe-owning component in dev also works. Both are avoidance rather than fixes.

Suggested fix

Guard the render logger's DOM traversal so a cross-origin frame is skipped rather than entered — accessing a frame's contentWindow properties should be wrapped, or iframe elements whose origin differs should be excluded from the walk. A third-party embed (payment, video, audio SDK, maps) is common enough that any app with one plus these devtools will hit this.

Happy to test a patch against the repro above.

[github-actions]

Thanks for the detailed write-up and analysis, @meirelon - this is a great description of the symptom and root cause.

Our bug report template asks for a minimal, runnable reproduction (e.g. a CodeSandbox/StackBlitz link or a small repo), and that piece is missing here. Since this involves a third-party SDK creating a cross-origin iframe, could you put together a minimal repro that swaps in something simpler than the Spotify SDK (any <iframe src="https://example.com"> mounted from a different origin should trigger the same SecurityError)? That would let us confirm the exact code path in the render logger that's walking into the frame and verify a fix against it.

Once we have that, this should be quite actionable - thanks for offering to help test a patch as well!