Web extension host debug adapters not working with codespaces/github.dev

[thegecko]

Does this issue occur when all extensions are disabled?: No - debug adapter required :)

• VS Code Version: VSCode for Web 1.74.3
• OS Version: Codespaces / github.dev (in Chrome)

As raised on the GitHub discussions, browser-based debug adapters running in the web extension host have stopped working on Codespaces and github.dev due to the file scheme not being handled correctly.

It's not clear if this a codespace issue or VS Code issue, so have raised the issue in both places.

Steps to Reproduce:

To recreate this, install the mock-debug extension in the web extension host of the VSCode for web flavours and observe the differences:

vscode.dev
The debugger runs in the browser and accesses files using the browser filesystem API. All works as expected.

@vscode/test-web
This runs on a developer's machine and I believe should mimic how codespaces/github.dev work. This works as expected.

github.dev
The debugger fails when setting breakpoints or opening files with:

Uncaught (in promise) Error (FileSystemError): Unable to read file '/vscode-vfs://github%2b7b2276223a312c22726566223a7b2274797065223a362c226964223a226d61696e227d7d/arm-debug/mock-debug/readme.md' (Unavailable (FileSystemError): Error: No file system handle registered (/vscode-vfs:/))

codespaces
You must ensure mock-debug is installed "Locally" in the web extension host, (by default it is installed in the codespace host and will work correctly) by modifying the settings:

{
    "remote.extensionKind": {
        "ms-vscode.mock-debug": [
            "ui"
        ]
    }
}

In the web extension host, similar errors are seen as github.dev:

Uncaught (in promise) Error (FileSystemError): Unable to read file '/workspaces/mock-debug/readme.md' (Unavailable (FileSystemError): Error: No file system handle registered (/workspaces))

Unfortunately codespaces and github.dev are also the only environments you cannot sideload or debug extensions in, so debugging this issue is extremely challenging.

I've tried reformatting paths prepending vscode-remote:// and variations on the root fspath but this doesn't work.

How should a debug adapter format paths so they can be opened by the UI in codespaces/github.dev when the scheme and authority aren't present?

[haneefdm]

Hmm. So, this was working a few weeks ago, but not anymore? Unfortunate. Thanks to @thegecko for submitting this issue.

I also tried vscode.devhttps://vscode.dev/

This is all I see when I open a folder. The first para is very confusing. Somehow I can enable a debug extension and they are all disabled?

[thegecko]

This is confusing information, especially as debugging works in vscode.dev with a pure browser debugger and adapter such as https://github.com/Arm-software/vscode-embedded-debug

[thegecko]

I'm very keen to get an update on this or at least to confirm if the issue is with the adapter (there may be a certain path format to use), VS Code or codespaces.

To that end, I've created instructions and a demo example extension to recreate the issue here:

https://github.com/thegecko/vscode-web-test

[thegecko]

A workaround for this issue in mock-debug has been implemented here:

microsoft/vscode-mock-debug#93

This isn't a generic fix and I wonder if it should be the responsibility of the debug adapter developer to ensure this works correctly?

[roblourens]

Sorry, I'm not sure how this would have been working before. This seems correct to me. Here's my understanding

• DAP sends paths that refer to the path of the file independent of any vscode workspace-specific concepts
• mock-debug wants to use vscode APIs to read the content of the file. Since it's in a webworker EH, there are these vscode-scheme URIs so mock-debug would have to translate the path to that URI, which your PR correctly does

So it's kind of a weird case, but I think it's correct. It wouldn't be correct to use the vscode-vfs URI in DAP and it wouldn't be correct to let the vscode API take a basic path without that scheme.

I will close this issue but keep your PR open, I'll look more closely at it later. What a particular DA needs to do likely depends on the situation.