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

Comece na travessia do DOM do render logger e reproduza o problema com um cross-origin iframe, como o Spotify Web Playback SDK iframe, em um ambiente de desenvolvimento do React 19. Rastreie o SecurityError e o scheduler error subsequente, depois verifique se os controlled inputs continuam fazendo commit após o iframe ser montado. Está concluído quando o cross-origin frame é ignorado com segurança e o repro não interrompe mais os input commits.

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.