Support testing of the file system API with Web Extension

[thegecko]

I'm developing a Web Extension which needs access to the filesystem.

As outlined in the docs, I'm using the vscode.workspace.fs.* commands along with vscode.Uri paths.

I'm testing this locally with a vscode build from main and running vscode-test-web, e.g.:

vscode-test-web --sourcesPath=$HOME/Projects/vscode --extensionDevelopmentPath=. .

However accessing any files throws the error:

Error: No file system handle registered

As thrown here

I've tried:

• Running the vscode web build directly (both code-web.sh and code-server.sh --launch) and installing my extension
• Installing various extensions which offer remote file systems, e.g. github repositories, github codespaces
• Running the vscode-mock-debug example which has the same functionality

And all of the above fail on a locally built vscode.

The vscode-mock-debug extension works as expected in https://vscode.dev, but I can't test there as I require some modifications in the vscode source.

How can file system APIs be tested from a web extension in a local build of vscode?

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: Main branch (web)
• OS Version: MacOS

Steps to Reproduce:

1. Build VSCode from main
2. Run the web version
3. Install and use the vscode-mock-debug extension

[aeschli]

It's currently not possible. I think what missing is the capability to open on an empty workspace so that local file folders can be added.

[thegecko]

Thanks @aeschli . This may not be limited to vscode-test-web as I was unable to test the same using code-server which i believe uses a different mechanism for running the web application.

I wonder, how is this tested/developed by the vscode team?

what missing is the capability to open on an empty workspace so that local file folders can be added

Happy to help depending on how large this task is

[thegecko]

I've been able to work around this issue by forcing the scheme of any URIs used in my extension to be vscode-test-web and prepending mount/ to the path.

e.g.

let uri = vscode.Uri.file(path);

if (VSCODE_TEST_WEB) {
    // Use vscode-test-web fs-provider
    uri = uri.with({ scheme: 'vscode-test-web', authority: 'mount', path: `/${uri.authority}` });
}

Perhaps a fix is to rewrite any URIs in the test extension on the fly?

[aeschli]

@thegecko If all you need is to access some local files for testing reasons, then you can use the folderPath command line argument which then internally uses the vscode-test-web scheme, as you discovered. If you want to test the experience that a vscode.dev user has when opening a local folder, that is what I haven't tried yet with the vscode-test-web node module. But code wise, vscode.dev has no additional code. I believe what it does: It opens a multi root workspace add adds a folder with scheme file to it.

[thegecko]

Thanks @aeschli

you can use the folderPath command line argument which then internally uses the vscode-test-web scheme,

Yeah, that was the approach I had. I think the bug here is that web extensions fail to be able to read any files using vscode.workspace.fs.* without rewriting the URIs as described above.

I believe what it does: It opens a multi root workspace add adds a folder with scheme file to it.

I wonder if that can be done here, with a redirection to the vscode-test-web scheme?

[thegecko]

@aeschli I don't see https://github.com/microsoft/vscode-test-web/commit/9a8e6ee35dbc43f57c072e68cb0a95b4da75a629 fixing this issue in v1.0.24. I tested loading files from a web-extension without the scheme rewrite I mentioned above and files cannot be found :(

[aeschli]

@thegecko When you start vscode-test-web without any folder input (e.g. with nxp @vsocde/test-web) this opens now a workspace that is an empty multi root workspace. That gives you the Open Folder button that opens the local file dialog that also grants the browser access to the files.

That matches what we have in vscode.dev and allows you to test things manually.

Now the question is, how can this be used in a automated test. I don't know the answer to this. I think there's no way around the dialog. vscode.commands.executeCommand('workbench.action.files.openFolderViaWorkspace'); would open that. Maybe you can figure out how we can teach playwrite to feed and accept that dialog

[thegecko]

Thanks @aeschli , I was specifying a folder directly on the cli, I'll try this new approach...

[thegecko]

Confirmed to be working as described. 👍

[boltex]

@thegecko Hello, I'm developping an web-extension that uses vscode.workspace.fs.writeFile, and i'm getting "Error: No file system handle registered" when running as a web-extension (either running with vscode-test-web, in local brownser, or on vscode.dev ) I cant seem to be able to use vscode.workspace.fs.writeFile when my extension is running in a browser.

So i was just wondering: Do you have an extension written or some example somewhere that i could look at, at to see an example of using vscode.Uri properly to make valid URI's to be able to 'writeFile' when running as a web-extension ?

Thanks! :D

edit: typo