Web extension host debug adapters not working with codespaces/github.dev
thegecko opened this issue · 5 comments
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?
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?
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
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:
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?
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.