Repository navigation
[Bug]: Download buttons in HTML previews do nothing #14362
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/server
Steps to reproduce
- Have an agent write an HTML file with a download button into the workspace, for example
<a href="data:text/plain,hi" download="hi.txt">Download</a>. - Open it from a chat link or the file preview.
- Click the button.
Expected behavior
The file downloads.
Actual behavior
Nothing happens, and the page shows no error. HTML assets are served with Content-Security-Policy: sandbox allow-scripts allow-forms allow-popups allow-modals (apps/server/src/http.ts), and BrowserDocumentFrame uses the same list for its iframe sandbox. Chromium drops every download from a sandboxed document unless the sandbox includes allow-downloads.
Adding it keeps the opaque origin, so cookies, storage, and the API stay out of reach.
Impact
Minor bug or occasional failure
Version or commit
main @ 0fcd5f9
Environment
macOS, T3 Code (Nightly) desktop. Also reproduced in Playwright Chromium by serving a page with the same header.
Workaround
Open the file outside T3 Code.
Activity
JDeffner commentedon Oct 10, 2026
Additional reproduction and version evidence from Windows: the installed 0.0.45 desktop package reports commit
6c8fed35dded(2026-10-02), and its bundled server still containssandbox allow-scripts allow-forms allow-popups allow-modals. It therefore predates #16950. This is not a report that the merged fix regressed.I tested a separate synthetic page through T3's native preview tools (Electron 44.4.2 / Chromium 152.0.7977.130). Its Export button creates a JSON Blob, clicks a detached
<a download>, and revokes the URL after one second:All three clicks returned normally to the page. A page that reports success after
anchor.click()can therefore display a false success message. The detached anchor and one-second revocation did not cause the failure in this test.There is a related data-loss trap for interactive generated HTML: this sandbox intentionally lacks
allow-same-origin, so localStorage cannot preserve form input. An HTML page that catches that error and says "Export before closing" sends the user to the blocked download path on older builds. Enabling downloads fixes that escape route; it does not enable persistence. Generated review pages need another persistence or copy-out route. I am correcting that guidance on the authoring side, not proposing removal of the storage isolation.I did not reproduce a remote device transfer on this host. A streamed browser saves on its host, which is a different path from a client-side Files iframe; current server-browser delivery is implemented separately. The user's original viewing surface is still being confirmed.