The previous commit swapped HtmlPreview to a blob: URL on the basis
of a round-4 reviewer claim that Chromium blob: frames get a fresh
policy container. Empirically verified against the live Studio: blob:
iframes ALSO inherit the embedder CSP in Chromium (and the spec
confirms it -- HTML / CSP3 § initialize-document-csp inherits CSP
for srcdoc, data:, and blob: alike). With the host enforcing
``script-src 'self'``, assistant inline scripts and on* handlers are
blocked in all three. Probe screenshots: alert dialog does not fire,
console shows ``script-src 'self'`` violations originating from
blob:http://127.0.0.1:8901/...
Switch back to srcdoc, which is the simplest path with the same
script-execution behavior. The meta-CSP inside the iframe stays as
defense in depth (connect-src 'none', frame-src 'none', img-src
data: blob:, etc.) so even a future host-CSP relaxation cannot turn
the preview into an exfiltration channel. allow-popups +
allow-popups-to-escape-sandbox stay so target=_blank links open
proper new tabs.
Genuinely interactive HTML demos need a same-origin backend route
serving with response-header CSP (response headers do NOT inherit
from the embedder); that is tracked as a follow-up. For this PR the
HTML preview ships as a static-render surface for layout, styles,
images, and source-tab viewing. The PR's manual-test claim about
``button onclick=alert(1)`` running inside the iframe is corrected
to "renders without firing the click handler under the current host
CSP" -- explicitly noted in the in-file comment and the meta-CSP
keeps ``script-src 'unsafe-inline'`` declared so the day the host
route lands the inner contract is already correct.
frame-src in the host CSP is reverted to ``'self'`` only.
115ff8978c