fix(sdk-ui): decode screenshots via createImageBitmap so host CSPs can't block capture

[Ripwords]

The bug

Reported from a live embed: after accepting the native "Share this tab?" prompt, the page appeared to freeze on a "Capturing…" overlay forever.

Root cause is the host page's CSP:

img-src 'self' data: …        # no blob:

The reporter turned the captured screenshot into a blob: object URL and assigned it to an <img>. That's a resource load, so it's checked against img-src. Under such a policy the load is refused, error fires instead of load, and the error handler only revoked the URL — it never set bg nor closed the reporter. The wizard is gated on bg (reporter.tsx), so it sat on the overlay indefinitely with body.overflow = "hidden" locking the page behind it.

script-src/connect-src on that site both allow the dashboard origin, which is why loading and uploading worked and only the image broke.

The fix

Decode the Blob with createImageBitmap — an in-process decode with no fetch, so img-src never applies, on any host CSP. No embedder config needed, which keeps the zero-config embed promise.

The native capture path is unchanged. getDisplayMedia, the "Share this tab?" prompt, preferCurrentTab, ImageCapture.grabFrame() all still run. Only the Blob → drawable hop moved.

Also in here:

• Preview + thumbnails render from the blob via <canvas> (BlobImage) instead of <img src="blob:">. The same CSP broke these silently (broken thumbnails rather than a hang). CSS selectors widened, since object-fit/aspect-ratio apply to <canvas> as a replaced element.
• No more silent hangs. A decode failure now closes the reporter with a warning, and the <img> fallback is bounded by a timeout.
• Types. bg is now ImageSource, which let the as unknown as { naturalWidth?: number } casts in canvas.tsx, flatten.ts and step-annotate.tsx go away.

previewUrl stays on the shared Attachment type — the Expo SDK carries a file:// uri in it (provider.tsx). Only the web path stops using it.

Verification

Replayed the reported site's real CSP against a built bundle in Chromium with tab-capture auto-accepted:

	Before	After
Annotate step	"Capturing…" overlay forever	real screenshot + toolbar
Details step	n/a (unreachable)	preview renders, form intact

• 369 SDK tests pass; new decode-image.test.ts locks in "decodes without minting a blob: URL" and "returns null instead of hanging".
• attachment-list.test.ts now asserts the thumbnail renders from the blob with previewUrl absent.
• bun run check clean (0 errors).

Note: the Chrome extension is affected too

The extension loads the SDK via chrome.scripting.executeScript({ world: "MAIN" }), which gets no CSP exemption. Measured on a CSP page:

blob: <img> in MAIN world     -> BLOCKED by page CSP
blob: <img> in ISOLATED world -> LOADED (CSP bypassed)

So the extension hit the same hang — on exactly the CSP-strict sites it exists to inject into. It already proxies fetch around connect-src, but there was no equivalent for img-src. It bundles @reprojs/core at build time (sync-sdk.ts), so it picks this up on its next build + release.

Release plan

Three patch releases needed, since each artifact ships the bundle separately:

• sdk-v0.4.2 → @reprojs/core on npm (npm embedders)
• v0.6.5 → dashboard Docker image, which bakes and serves /sdk/repro.iife.js (fixes the reporting site)
• extension-v0.1.4 → Chrome Web Store

🤖 Generated with Claude Code