Description
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.