[Bug]: Cannot load gpkg in vscode.dev

[HemanthJabalpuri]

Description

Hello @zknpr

I found that when trying to open gpkg in vscode.dev, it is stuck with loading page. I tried the same in your website and it works. So, problem is something to do with the extension code in vscode.dev

Thank you
Hemanth

Steps to Reproduce

Open any gpkg in vscode.dev

Expected Behavior

Data should load

Actual Behavior

Not loading

Extension Version

1.3.5

VS Code Version

1.122.1

Operating System

VS Code for Web (browser)

SQLite Backend

None

Relevant Logs

[zknpr]

Correction — real root cause (replaces my earlier text in this comment)

Correcting myself: an earlier version of this comment quoted a default-src 'none' / "no worker-src / child-src fallback" CSP error. That was wrong — I had not actually captured it. Here is the real evidence, captured from the published 1.3.6 running in real vscode.dev (webview console, seen twice, and reproduced directly):

TypeError: Failed to construct 'Worker': This document requires 'TrustedScriptURL' assignment.
This document requires 'TrustedScriptURL' assignment. The action has been blocked.

Actual cause: VS Code Web applies a CSP with require-trusted-types-for 'script' (Trusted Types) and a fixed trusted-types policy allowlist. src/workerFactory.ts spawns the SQLite worker with new Worker(blobUrl) where blobUrl is a plain string — Trusted Types requires a TrustedScriptURL, and the allowlist only contains VS Code's own policy names, so the construction is blocked. (Note: worker-src 'self' blob: IS present in the CSP — the block is Trusted Types, not worker-src.) The worker never starts → every host→worker RPC times out → "stuck loading", for all DB file types.

WebAssembly instantiation IS allowed in that context (verified).

PR #419's parentPort change was a real but downstream bug; the worker is killed at construction, before that code runs, so #419 could not fix #418. My earlier local repros didn't enforce Trusted Types, which is why this was missed until testing in real vscode.dev.

Fix: in browser mode, run the sql.js engine in-process in the extension host (no Worker) — WASM is permitted there. Desktop keeps the worker thread. PR incoming.