Repository navigation
[Bug]: Local HTML files open to a blank viewer in T3 Code Desktop #11191
Description
Activity
Triage
Confirmed as a real desktop file-viewer bug, not a duplicate of #7212, #10935, or #9533.
Opening a local
.htmlfile in the Desktop file explorer uses the in-panel renderer (WorkspaceBrowserPreviewinapps/web/src/components/files/FilePreviewPanel.tsx): a signed/api/assets/…URL in a sandboxed<iframe>. Source view and Markdown do not use that iframe, which matches the report.On Desktop the renderer CSP in
apps/desktop/src/electron/ElectronProtocol.tsis still:frame-src 'self' https://challenges.cloudflare.comimg-src/media-srcalready allowhttp:/https:for environment asset URLs; frames do not. Chromium then navigates the iframe tochrome-error://chromewebdata/and the pane stays blank, with no load-error UI.This is the same CSP miss as blank PDF previews. Open PR #10541 already widens
frame-srctohttp:/https:and should unblock HTML as well. It has not landed (security review on relaxingframe-src). #9143 added the HTML/PDF iframe viewer without updating this policy.#10935 is a separate follow-on: compressed assets can lose
Content-Typeand render as plain text. That is not thischrome-errorblank page.Suggested fix
- Land fix(desktop): allow PDF previews from connected environments #10541 or an equivalent desktop
frame-srcchange, and verify a local.htmlfile in Desktop (not only PDF). - Optional: surface iframe load failures so a blocked document is not a silent white pane.
Workaround
Use Show HTML source, open the file in an external browser, or use the globe “Open in preview browser” control if the integrated browser is available.
- Land fix(desktop): allow PDF previews from connected environments #10541 or an equivalent desktop
I’m seeing similar behavior in T3 Code 0.0.42 alpha on macOS, with agent-generated HTML plans and mockups stored under
~/.t3.Steps to reproduce
- Ask an agent to create an HTML plan or mockup, saved under
~/.t3. - Click the HTML file link in the agent’s response.
- The preview browser opens but displays a blank screen. No error message appears.
Expected: The generated HTML document renders in the preview browser.
Actual: The preview remains blank, with no indication of why loading failed.
Workaround: Right-click the file link, reveal it in Finder, and open it in an external browser. The same file renders correctly there.
The
~/.t3location may be relevant. I haven’t confirmed whether files inside the project folder behave differently, or whether this has the same underlying cause as the original report.- Ask an agent to create an HTML plan or mockup, saved under
Fixed by #11265: the desktop CSP now allows http(s) frames, so local HTML files render. If a file under
~/.t3still opens blank, please open a new issue.
Before submitting
Area
apps/desktop
Steps to reproduce
.htmlfile.docs/issues-log-effort.html)..mdfile as a comparison; its contents display normally.Expected behavior
The local HTML document should render in the embedded viewer. If rendering fails, the pane should show an actionable error instead of a blank page.
Actual behavior
The HTML file opens as a completely blank white pane. The embedded document resolves to
chrome-error://chromewebdata/with no visible error or recovery controls.The HTML source view works and shows the file's contents, and an adjacent Markdown file opens normally, so the failure appears isolated to rendered HTML files in the desktop file viewer.
Related but not an exact duplicate: #7212 concerns a failed floating browser preview; #10935 concerns compressed assets rendering as plain text.
Impact
Major degradation or frequent failure
Version or commit
T3 Code 0.0.40 (Stable)
Environment
macOS; T3 Code Desktop 0.0.40 Stable; local checkout
Logs or stack traces
Embedded viewer document URL: `chrome-error://chromewebdata/`Screenshots, recordings, or supporting files
No response
Workaround
Toggle Show HTML source to read the file, open it in an external browser, or use a Markdown version instead.