Adopt VS Code's 'asWebviewUri' API

[mjbvz]

Hi, I maintain VS Code's Webview API

Issue

Our telemetry suggests that your extension uses webviews and may be loading resources in these webviews using hardcoded vscode-resource: URIs. These URIs have some important limitations and don't work properly when VS Code is run in a browser. We are also making changes in the desktop version of VS Code that may cause these URIs to not work properly in future versions of VS Code.

While we are making our best effort to continue support existing webview extensions that use vscode-resource: URIs on desktop versions of VS Code, we will not able to fully support all uses cases.

Fix

To ensure that your extension continues to work in as many environments as possible—including on web and remotely—please:

• Switch to use the Webview.asWebviewUri function for loading resources.

• Switch to use the Webview.cspSource property in content security policies.

These APIs shipped around 2 years ago so they should be available in all modern versions of VS Code. You can find additional information about the issue here: microsoft/vscode#97962

Let me know if you have any questions about this change

[emackey]

Hi @mjbvz, thanks for reaching out.

The .asWebviewUri function presents a special challenge to this VSCode extension. A primary feature of this extension is to display 3D models in glTF format. These are JSON files that reference a couple other files by name, including a binary file and a small number of JPG or PNG image files.

The files are being loaded by 3rd-party JavaScript frameworks such as BabylonJS, CesiumJS, and ThreeJS, embedded in the Webview. When these frameworks load the file, they will be looking for relative paths from the glTF file's root folder, to find the binary and image files that belong to the 3D model.

Because .asWebviewUri causes paths to no longer be relative, the raw glTF file becomes unusable in the Webview. One idea I had is to have the extension itself attempt to parse the glTF document before handing it off to the webview, and replace all occurrences of relative URIs with webview URIs, before it gets into the WebGL frameworks.

I'm still looking into this, but this appears to be a massively breaking change, at least for formats like glTF.

[mjbvz]

asWebviewUri should still work with relative urls. In fact, we already try to rewrite all hardcoded vscode-resource: urls to use the same url scheme that asWebviewUri produces. If vscode-resource: works today, then asWebviewUri should also work

[emackey]

Thanks @mjbvz. Somehow I had the idea in my head that paths couldn't be relative, but you're right, they still are.

It still took some doing but I now have PR #185 open that I believe fixes this extension the correct way, without rewriting the glTF.

[emackey]

Version 2.2.11 published.