Use cross-origin HTML preview renderer

[mwtrew]

This moves preview rendering to an iframe with a document loaded cross-origin as a source. This enforces cross-origin separation and gives the preview window it's own localstorage, isolated from the parent. Content is injected into the doc via postMessage().

Most of the logic in the new HtmlRenderer component (besides message handling) has been moved over from HtmlRunner.

[Copilot]

Pull request overview

This pull request restructures the HTML preview rendering to use a cross-origin iframe approach instead of the previous blob URL method. The renderer is moved to a separate application that loads at HTML_RENDERER_URL, and content is communicated via postMessage. This enforces security isolation and gives the preview window its own isolated localStorage.

Changes:

• Create a new webpack configuration and entry point for the HTML renderer as a separate application
• Refactor HtmlRunner to use postMessage instead of directly manipulating blob URLs in the iframe
• Create new HtmlRenderer component to handle HTML rendering and message passing
• Move iframe origin validation logic to a shared utility module
• Remove legacy test cases that were specific to the old blob URL approach

Reviewed changes

Copilot reviewed 14 out of 15 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
webpack.html-renderer.config.js	New webpack configuration for building the HTML renderer as a separate bundle
src/html-renderer.jsx	New entry point for the HTML renderer application
src/utils/iframeUtils.js	New utility module for iframe security validation and message constants
src/components/Editor/Runners/HtmlRunner/HtmlRenderer.jsx	New component that handles HTML rendering and cross-origin communication
src/components/Editor/Runners/HtmlRunner/HtmlRunner.jsx	Refactored to use postMessage instead of blob URLs
src/components/ScratchEditor/ScratchIntegrationHOC.jsx	Updated to use shared iframe utility function
src/components/Editor/Runners/HtmlRunner/HtmlRunner.test.js	Removed tests specific to old blob URL approach
.github/workflows/deploy.yml	Updated deployment pipeline to build and deploy HTML renderer separately
package.json	Added build and start scripts for HTML renderer
Other supporting files	Added HTML template, styles, and configuration files

Comments suppressed due to low confidence (1)

cypress/e2e/spec-html.cy.js:1

• All end-to-end Cypress tests for HTML functionality have been removed from spec-html.cy.js, including critical tests for localStorage blocking (authKey, OIDC keys), permission validation for external links, and internal link navigation. These behaviors should be covered by E2E tests to ensure the preview functionality works correctly.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[zetter-rpf]

I was thinking about the seperate webpack config and tasks to run and build.

Is the intention to have the iframe deployed and served from the same bucket as editor-ui?
If it is, I wondered if there is value in having the seperate webpack config (instead of just a new entrypoint in the existing config). There is a benefit to having the iframe served from a different port in development, but it does add complexity to starting the server. Having the same config will still mean that we can test having the iframe on a separate port in development when included from standalone, it's only the local editor test page that won't be the same.