vscode: vscode://file// links no longer working

Type: Bug

All of a sudden, vscode://file// links are no longer working.

Expected behavior:

I click open a link like vscode://file//path-to-a-file-that-really-exists and it then VS Code opens the file. This has always worked for me.

Actual behavior:

I click open a link like vscode://file//path-to-a-file-that-really-exists and it then VS Code becomes focused, but it does not open the desired file.

Please note that I have verified that the file really does exist in the specified path.

VS Code version: Code 1.84.0 (Universal) (d037ac076cee195194f93ce6fe2bdfe2969cc82d, 2023-11-01T11:30:19.406Z) OS version: Darwin arm64 23.0.0 Modes:

System Info
Item Value
CPUs Apple M1 (8 x 24)
GPU Status 2d_canvas: enabled
canvas_oop_rasterization: enabled_on
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
video_decode: enabled
video_encode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: enabled
Load (avg) 3, 3, 3
Memory (System) 16.00GB (0.14GB free)
Process Argv –disable-extensions --crash-reporter-id f43891bf-1e90-4f74-a11c-73425109d857
Screen Reader no
VM 0%
Extensions disabled
A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscoreces:30445986
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593:30376534
pythonvs932:30410667
py29gd2263:30880072
vsclangdf:30486550
c4g48928:30535728
dsvsc012cf:30540253
pynewext54:30695312
azure-dev_surveyone:30548225
282f8724:30602487
89544117:30613380
2i9eh265:30646982
showlangstatbar:30737416
03d35959:30757346
pythonfmttext:30731395
fixshowwlkth:30771522
showindicator:30805244
pythongtdpath:30769146
i26e3531:30792625
pythonnosmt12:30797651
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30869155
dsvsc013:30795093
dsvsc014:30804076
dsvsc015:30845448
pythontestfixtcf:30871695
pythonregdiag2:30871582
pythonmypyd1:30879173
pythoncet0:30874138
pythontbext0:30879054

About this issue

  • Original URL
  • State: closed
  • Created 8 months ago
  • Comments: 19 (7 by maintainers)

Commits related to this issue

Most upvoted comments

Yeah, there is changes needed in VS Code, esp. since now the behaviour is different between having the confirmation setting enabled or not.

I understand now how we are able to support even invalid URL like that because we process each path to open and normalise it, that probably removes the double slashes:

https://github.com/microsoft/vscode/blob/e35641909e4fb6ac143fc8fbc46075d3f13c782a/src/vs/base/common/extpath.ts#L269

Nevertheless, if you can change your tool to produce correct URLs, that would help people until the fix has landed 👍

It’s worth noting that the documentation for this feature is not entirely clear.

https://code.visualstudio.com/docs/editor/command-line#_opening-vs-code-with-urls

The documentation state:

Open a file

vscode://file/{full path to file}

vscode://file/c:/myProject/package.json

Open a file to line and column

vscode://file/{full path to file}:line:column

vscode://file/c:/myProject/package.json:5:10

However on a *nix-like system the {full path to file} would be /some/example/here making the documented URI vscode://file//some/example/here which we are now told is incorrect.

I would argue that this is therefore not a bug in the generating code, but actually in vscode (which is now fixed).

Whilst working around this in the generating code is possiblem I would suggest that it is not correct in the long term.

/verified

Everything is working correctly now! I can’t say for sure that it is fixed because I could not reliably reproduce the bug before, but I trust that the change has solved the problem. Will follow up later if I encounter any other issues. thanks very much for your quick attention to this issue!

@bpasero Thanks! I’ve now fixed my tool to produce the correct links.