Improve compatibility with VS Code Webview URI

[sdirix]

Background

VS Code offers the webview API which can be leveraged to generate resource URIs for web views via webview.asWebviewUri.

Example results of calling toString() on such a generated URI object:

• Theia: http://905a98b2-a9cc-4822-9bba-4f6c8ac0d81d.webview.localhost:3000/webview/theia-resource/file///c%3A/Dev/theia/plugins/my-extension/assets/myImage.png
• VS Code: https://file%2B.vscode-resource.vscode-cdn.net/c%3A/Dev/my-project/assets/myImage.png

As can be seen Theia uses /webview/theia-resource/{{scheme}}//{{authority}}/{{path}} to mark the resource while VS Code for example adds the resource scheme into the authority of the URI.

As a consequence, if a user calls path or fsPath on the URI object of a file resource, they receive the full absolute path in VS Code, e.g. c:\Dev\my-project\assets\myImage.png while in Theia they get the marker mixed in, e.g. \webview\theia-resource\file\\\c:\Dev\theia\plugins\my-extension\assets\myImage.png.

Compatibility

VS Code extensions relying on path or fsPath then break in Theia. They would need to be Theia aware and strip \webview\theia-resource\file\\\ from their paths to get the actual path.

Potential adaptations

Similar to the VS Code implementation, we could change our URIs, for example to also hack the authority to place our markers there. However this then requires all our code to handle this new URI format.

A simpler and less intrusive adaptation would be to customize the URI object which we return from webview.asWebviewUri. For example we could proxy the returned object and adapt the getters for path and fsPath to strip our known prefix. The implementation can be found here. Note that we have an additional implementation for Notebooks, we might need to adapt that one too.

Technically we would break the "real" expected behavior of URIs, but I think this makes sense here to improve compatibility. I'm not aware of any use case we would break with the adapted behavior.

[rschnekenbu]

Thanks @sdirix for this detailed analysis!
I would be in favor of the proxy adaptation, as it would clearly isolate and mark this as a compatibility solution.

[msujew]

I also think that this is a reasonable solution. While encoding the info in the URI scheme would be a more elegant solution, I would assume that this would lead to issues with adopters that have built reverse proxy solutions based on the existing behavior.