Clicking a CSS path from inspector fails with remote environment

[aaronpowell]

If you open a repo using a VS Code remote environment (issue has been tested on WSL + Containers, assuming it's the same in SSH) and try to click on a link to a CSS file in the inspector (source map generated or otherwise) the file fails to load.

After some debugging I found that the following error was being generated:

rejected promise not handled within 1 second: Error: cannot open file:///vscode-remote%3A/wsl%252Bubuntu/home/aaron/code/github/supercharging-web-dev-toolbox/src/pages/CreateGame.module.css. Detail: Unable to read file '\vscode-remote:\wsl%2Bubuntu\home\aaron\code\github\supercharging-web-dev-toolbox\src\pages\CreateGame.module.css' (Error: Unable to resolve non-existing file '\vscode-remote:\wsl%2Bubuntu\home\aaron\code\github\supercharging-web-dev-toolbox\src\pages\CreateGame.module.css')
stack trace: Error: cannot open file:///vscode-remote%3A/wsl%252Bubuntu/home/aaron/code/github/supercharging-web-dev-toolbox/src/pages/CreateGame.module.css. Detail: Unable to read file '\vscode-remote:\wsl%2Bubuntu\home\aaron\code\github\supercharging-web-dev-toolbox\src\pages\CreateGame.module.css' (Error: Unable to resolve non-existing file '\vscode-remote:\wsl%2Bubuntu\home\aaron\code\github\supercharging-web-dev-toolbox\src\pages\CreateGame.module.css')
    at vscode-file://vscode-app/c:/Program%20Files/Microsoft%20VS%20Code%20Insiders/resources/app/out/vs/workbench/workbench.desktop.main.js:2390:64553

My debugging shows that the line that the error comes from is https://github.com/microsoft/vscode-edge-devtools/blob/main/src/devtoolsPanel.ts#L309

I'll use comments to detail my findings around a possible fix

[aaronpowell]

My debugging has led me to find a few things that, together, might be causing the issue here.

Fundamentally, the Uri generated on https://github.com/microsoft/vscode-edge-devtools/blob/main/src/devtoolsPanel.ts#L298 thinks that it's working with a file scheme, whereas the scheme really needs to be vscode-remote so that it opens using a remote handler.

So, unwinding a little more, the url that we are trying to resolve the file on disk is:

'webpack://src/pages/CreateGame.module.css'

And this is converted to sourcePath of:

'vscode-remote:\wsl%2Bubuntu\home\aaron\code\github\supercharging-web-dev-toolbox\src\pages\CreateGame.module.css'

There are two problems with this string here, first is that the scheme is broken, it really should be vscode-remote:\\wsl... not vscode-remote:\wsl..., there's a missing \ in it. Additionally, the path separators are \ when they should be /, since (for this use case) I'm connecting to Linux file system.

This brings us to the question, why did the path separators flip, and what happened to one of the \ from the scheme?

For that we need to dig into https://github.com/microsoft/vscode-edge-devtools/blob/main/src/utils.ts#L475, specifically the call to debugCore.utils.properJoin.

When we make this call, mappedPath has the following value:

'vscode-remote://wsl%2Bubuntu/home/aaron/code/github/supercharging-web-dev-toolbox/src/pages/CreateGame.module.css'

But the return of the call to properJoin (and thus, the value of mappedPath now is:

'vscode-remote:\\wsl%2Bubuntu\\home\\aaron\\code\\github\\supercharging-web-dev-toolbox\\src\\pages\\CreateGame.module.css'

Notice the \ switch and we've lost one of the starting separators (meaning we no longer have a scheme).

So, what happened? Well, for that we dig into https://github.com/microsoft/vscode-chrome-debug-core/blob/main/src/utils.ts#L677-L685 and notice that it's using the path library from Node.js to do path normalisation. Unfortunately, since we're running in a remote (detectable using vscode.env.remoteName) the Node.js process will be executed on the host, which might not be the same OS as the remote (such as if you're using WSL, host in Windows, remote is Linux).

I guess there needs to be a way to detect if it's a remote, and if it is, do path normalisation based on the remote file system semantics, or can you get around not doing path normalisation?

[aaronpowell]

Again, using the debugger, I edited the value that is assigned to sourcePath to be what mappedPath has and then continue through debugging.

The next problem is that using vscode.Uri.file doesn't seem to understand remotes and see the scheme as file when it needs to be vscode-remote. Here's a debugger dump of what the uri has:

vscode.Uri.file(sourcePath)
c {scheme: 'file', authority: '', path: '/vscode-remote://wsl%2Bubuntu/home/aaron/code/…b-dev-toolbox/src/pages/CreateGame.module.css', query: '', fragment: '', …}
_formatted:null
_fsPath:null
authority:''
fragment:''
fsPath (get):ƒ fsPath(){return this._fsPath||(this._fsPath=d(this,!1)),this._fsPath}
path:'/vscode-remote://wsl%2Bubuntu/home/aaron/code/github/supercharging-web-dev-toolbox/src/pages/CreateGame.module.css'
query:''
scheme:'file'
__proto__:p

I just so happened to have other files open in the editor at the time and if we have a look at the Uri of an open file, here's what we see:

_formatted:'vscode-remote://wsl%2Bubuntu/home/aaron/code/github/supercharging-web-dev-toolbox/.devcontainer/Dockerfile'
_fsPath:'\\home\\aaron\\code\\github\\supercharging-web-dev-toolbox\\.devcontainer\\Dockerfile'
authority:'wsl+Ubuntu'
fragment:''
fsPath (get):ƒ fsPath(){return this._fsPath||(this._fsPath=d(this,!1)),this._fsPath}
path:'/home/aaron/code/github/supercharging-web-dev-toolbox/.devcontainer/Dockerfile'
query:''
scheme:'vscode-remote'
__proto__:p

Things of most interest are the authority being wsl+ubuntu and scheme being vscode-remote. These are required so VS Code knows how to open a file using the remote (and that's about all I have figured out 🤣).

So, how do we generate that? Using vscode.Uri.parse instead! Here's what it looks like:

_formatted:'vscode-remote://wsl%2Bubuntu/home/aaron/code/github/supercharging-web-dev-toolbox/src/pages/CreateGame.module.css'
_fsPath:null
authority:'wsl+ubuntu'
fragment:''
fsPath (get):ƒ fsPath(){return this._fsPath||(this._fsPath=d(this,!1)),this._fsPath}
path:'/home/aaron/code/github/supercharging-web-dev-toolbox/src/pages/CreateGame.module.css'
query:''
scheme:'vscode-remote'
__proto__:p

The value of _fsPath is null, but that seems to be fine.

So by using the debugger to hack the value of sourcePath and uri to be what seems to work, and then passing it to vscode.workspace.openTextDocument the file opens as expected in the target VS Code instance! 🎉

[aaronpowell]

I'd love to work with you folks to find a way to implement a proper solution to this, not just the really hacky one that I have for testing 🤣

[aaronpowell]

Just tested this wit 1.3.1 and it looks like the changes from #467 have regressed (possibly in #475)

Now when you click a link in the CSS inspector on WSL remote it pops an error dialog showing a message:

Unable to open file in editor. vscode-remote://wsl%2Bubuntu/home/aaron/code/github/supercharging-web-dev-toolbox/src/pages/CreateGame.module.css does not map to a local file.

@vidorteg @mliao95

[captainbrosset]

This has unfortunately gotten stale. Let me ping @vidorteg again to put this back on his radar. It'd be good to track this regression and work on a fix.

[paule96]

This looks stale again. I get right now the message:

Unable to open file in editor. vscode-remote://dev-container%2B7b227265706f7369746f727950617468223a227373683a2f2f70616a6540742d73797374656d732d6d6d732e6465407466732e742d73797374656d732d6d6d732e65753a373939392f6167696c652f534f4c494d41542f5f6769742f536f6c696d61742e46726f6e74656e642e416e67756c6172222c22766f6c756d654e616d65223a225f5f554e495155455f5f222c22666f6c646572223a22536f6c696d61742e46726f6e74656e642e416e67756c6172222c22636c6f6e65496e666f223a7b2275726c546f436c6f6e65223a227373683a2f2f70616a6540742d73797374656d732d6d6d732e6465407466732e742d73797374656d732d6d6d732e65753a373939392f6167696c652f534f4c494d41542f5f6769742f536f6c696d61742e46726f6e74656e642e416e67756c6172227d2c22696e7370656374566f6c756d65223a66616c73657d/workspaces/xxx/xxx/xxx/xxx/xxx/xxx/xxx/xxx/xxx/xxx.ts does not map to a local file.

[vidorteg]

Thanks for bringing awareness to this bug, probably fell through the cracks. Adding @codepo8 and @hkal to raise visibility.

[captainbrosset]

From @chris-mcdonald-dev in #1589:

---

Environment (please complete the following information):

OS: Windows 11 WSL - Ubuntu
Extension version: 2.1.2
Describe the bug:

Trying to change CSS properties has no effect on the linked CSS file in VS code.

Repro steps:

Start any server in WSL and open it in the extension's browser.
Change any CSS property in the DevTools panel that has a link to the stylesheet you're editing in VS Code.

Expected behavior:

Expected the updated devtools styles to reflect in VS Code (CSS Mirroring feature).

Additional context:

This was mentioned in feedback for the initial CSS Mirroring issue (#476), but I wasn't able to find any comments addressing it or references to it in the pinned Known Issues (#1317). Is this something that isn't planned on being fixed? Thanks for everything!

---

[ja-why-son]

This issue should be fixed with #1804 so I'll close the issue. Feel free to open a new issue if you're still able to repro the bug.