Document Content Providers are being passed URI-unescaped paths when invoked through the DAP

[thloke]

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

• VS Code Version: 1.74.3
• OS Version: Win11 22H2 22621.1105

Steps to Reproduce:

1. We have an implementation of the DAP for our language server, and in response to the stacktrace call, we return stackframes which contain URI-escaped filenames as the Path property of Source. Something like this:
   

2. When VSCode handles this response and calls our document content provider, it has un-escaped the URI. This generates an invalid filename.
   

We'd expect that the Path sent to the document content provider is the same as the Path we sent as part of the stacktrace call.

[thloke]

@roblourens - any update on this? We're getting more issues in our extension because of this.

[minaskats]

This starts to be a very big problem for us. We can not debug the CODE of A/L making it a lot harder to solve our customers problems.

[mynhardt7]

Are this being worked on? It's been open for months and breaks the Microsoft AL debugger.

[DanielGoehler]

+1

[GhOnBc]

Starting to get very annoying.. Can we please have an update

[roblourens]

Sorry, I investigated this a couple months ago and couldn't find a good way to fix it, I will take another look when I'm able

[roblourens]

@jrieken, I was reviewing some of the past issues here, #25852, #83645, #32026, etc. Do you have any suggestions what to do in this case?

Here I use URI.parse on this uri string which is passed back over DAP. Then that goes to the extension's document content provider, which is expecting percent-encoded slashes as part of the path.

@thloke, you also might want to look into whether you can work around this on your end, since this issue of handling escape sequences in URIs has a long history

[jrieken]

I am very sorry for this but it is something we have acknowledged but cannot fix it anymore. #83645 (comment) summarises the problem in more detail and the only path forward is to allow URL (newly'ish standard object) in addition to URI. (Tho, don't assume URL is perfect and identical across browsers...)

[roblourens]

That means that the document content provider would have to support taking a URL? Are we planning on doing this for extension API anywhere yet?

[jrieken]

No plans. It doesn't necessarily mean to accept URL in the document content provider, more like allowing them in DAP. I believe we could create a good URI from this (using URI.from)

[roblourens]

DAP isn't using URIs, it's using a string, so if there's a way to parse a uri string into components that I can pass to URI.from then I can already do that, but I think that is what URI.parse is which is the problem

[jrieken]

but I think that is what URI.parse is which is the problem

Yeah, you could try new URL and then construct a URI via from from it but no guarantees that this doesn't break another thing

[roblourens]

Do you think it would make sense to let an extension opt-into new behavior for the URIs it provides, with a flag like preserveEncodedURICharacters?

[jrieken]

opt-into new behavior for the URIs it provides, with a flag like preserveEncodedURICharacters?

I'd say high risk because URL doesn't seem to decode at all. Look at the ü for instance. If you need inter-op with VS Code (open editors etc ppp) than it's better to stay with its URI world.