Repository navigation
[Bug]: Local HTML files open to a blank viewer in T3 Code Desktop #11191
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/desktop
Steps to reproduce
- In T3 Code Desktop, open a project containing a local
.htmlfile. - In the right-hand workspace file explorer, click the HTML file (reproduced with
docs/issues-log-effort.html). - Leave the embedded rendered-page view selected.
- Observe the center viewer pane.
- Toggle to Show HTML source and confirm that the file contains normal HTML content.
- Open an adjacent
.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.
Activity
juliusmarminge commentedon Sep 11, 2026
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
frame-srcchange, and verify a local.htmlfile in Desktop (not only PDF).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.
mylesthedev commentedon Sep 28, 2026
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
~/.t3.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.juliusmarminge commentedon Oct 7, 2026
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.