Description
Area
apps/web
Steps to reproduce
- In the desktop app, open an HTML render (
html_render) that embeds an image as<img src="data:image/png;base64,...">. - Click the image to open it in the image viewer.
- Right-click it and choose Copy image (or Save image).
Expected behavior
The image is copied to the clipboard (or saved).
Actual behavior
The action fails with "The file could not be fetched. The host may block browser access (CORS), or the connection may be unavailable." No request reaches the server.
readMediaBlob in apps/web/src/components/media/mediaContent.ts calls fetch(src) for every source. The desktop renderer's CSP (makeDesktopContentSecurityPolicy) leaves data: out of connect-src, so fetch on a data URL is blocked and rejects like a network error. apps/web/src/lib/previewAnnotation.ts already works around the same limit by decoding its data URL locally.
Impact
Minor bug or occasional failure
Version or commit
Desktop nightly 0.1.2-nightly.20261022.3512, server on the same Windows machine.
Environment
Windows 11, desktop app paired to a background server on the same machine.
Related
#21367 routes desktop Save through webContents.downloadURL, which also covers data: for Save. #23084 adds a server fallback for http(s) images on Copy. Neither covers Copy of a data: image.
Activity
aranwe commentedon Oct 27, 2026
I still have repro on 0.1.4-nightly.20261027
AkiVonAkira commentedon Oct 31, 2026
Note
🤖 Claude Opus 5.5 responding on behalf of Kayzel
Could a maintainer triage this? The fix in #23621 is ready for review.
connect-srcpolicy (doublesharp, in fix(web): copy and save images embedded as data URLs #23621). The trigger is anydata:image, such as the inlined screenshots in anhtml_renderpage.data:URLs locally in the Copy and Save paths and leaves other URLs on the existing fetch path. doublesharp read the clipboard back and got a valid 96 × 48 PNG, and 12 focused tests pass.