ResponsiveX frames real sites inside iframes. A few things the iframe model cannot fully emulate — when a frame won't load, the diagnostic panel names the most likely cause below.
Some sites run JavaScript that forces top.location to escape framing.
ResponsiveX sandboxes frames (no allow-top-navigation) so this can't
hijack the viewer, but such a site may refuse to render inside a frame. No workaround.
Header stripping (declarativeNetRequest) removes X-Frame-Options /
Content-Security-Policy response headers. A CSP delivered via a
<meta> tag in the HTML, or a login that relies on
SameSite=Strict cookies, is outside that scope and may still block content.
Typically a dev server that isn't running. Check that your localhost /
127.0.0.1 server is up and serving the port in the address bar.
Expected, and not a malfunction. Every screen is an iframe with
sandbox="allow-scripts allow-same-origin …", and Chrome warns about that
combination on principle: a same-origin sandboxed frame could rewrite its own sandbox
attribute. Here the framed page is always cross-origin to the viewer, so it
cannot reach the attribute — while both flags are what make the tool work:
allow-scripts runs the site, allow-same-origin keeps its
cookies, storage and readable stylesheets (breakpoint detection). Dropping either one
breaks ordinary sites; keeping the sandbox is what denies
allow-top-navigation and stops frame-busting from hijacking your tab.
Chrome files the warning under the red Errors button of an unpacked extension in developer mode — one entry per frame. It is safe to clear.
navigator.userAgent). The request header sent to the server is unchanged —
MV3 cannot set it per sub-frame — so server-side UA detection is unaffected.