Conversation
Library builds inline ghostty-vt.wasm as a data: URL, and Ghostty.load() fetched that URL. A page whose Content-Security-Policy connect-src does not include data: blocks the fetch, logs a violation, and the loader then probes ./ghostty-vt.wasm and /ghostty-vt.wasm over the network, both of which usually 404. Decode base64 data: URLs in memory instead. No network request is made, no CSP exception is needed, and the fallback probes no longer run for bundled builds. Loading from file paths and URLs is unchanged.
Ghostty.load() already accepts an explicit path, but init() did not pass one through, so embedders serving dist/ghostty-vt.wasm themselves had no way to point the loader at it. Forward an optional wasmPath from init(). Add a Content-Security-Policy section to the README: the bundled WASM needs no connect-src exception, and compiling WebAssembly requires 'wasm-unsafe-eval' in script-src.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #188.
Library builds inline
ghostty-vt.wasmas a base64data:URL, andGhostty.load()fetched that URL. Under a Content-Security-Policy whoseconnect-srcdoes not includedata:(for exampleconnect-src 'self'), the fetch is blocked and logs a violation. The loader then falls back to./ghostty-vt.wasmand/ghostty-vt.wasm, which resolve against the page and usually 404, soinit()failed and offered no way to point it at the file.Change
Ghostty.load()decodes base64data:URLs in memory instead of fetching them. The bundled WASM now loads with no network request and no CSP exception, and the fallback probes no longer run for bundled builds. Loading from file paths and URLs is unchanged.init(wasmPath?)forwards an explicit path toGhostty.load(), for embedders who servedist/ghostty-vt.wasmthemselves (suggestion 1 in CSP: wasm loads via data: URI fetch (blocked by connect-src 'self') and init() offers no wasm path override #188).'wasm-unsafe-eval'requirement (suggestion 3).Testing
lib/ghostty-load.test.ts: loading from adata:URL succeeds whilefetchrejects, andfetchis never called.bun run fmt && bun run lint && bun run typecheck && bun test && bun run buildall pass, with tests run against a WASM built from this tree (Zig 0.15.2).default-src 'none'; script-src 'self' 'wasm-unsafe-eval'; connect-src 'self'initializes with no CSP violation and no request for a.wasmfile. With the npm 0.4.0 build, the same page logs thedata:violation and requests the fallbacks.