Loading external resources in VSCode Extension Webview fails due to CORS Policy

[ahmed-shehata]

Version: 1.47.2
Commit: 17299e4
Date: 2020-07-15T18:18:50.054Z (4 days ago)
Electron: 7.3.2
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Darwin x64 19.5.0

Tested with insiders as well:

Version: 1.48.0-insider
Commit: 6c21258
Date: 2020-07-20T05:27:28.503Z (9 hrs ago)
Electron: 8.3.3
Chrome: 80.0.3987.165
Node.js: 12.13.0
V8: 8.0.426.27-electron.0
OS: Darwin x64 19.5.0

Issue

It seems like this change broke loading external vscode-resources.
A similar issue: #99190

Steps to Reproduce:

Loading external resources (ttf font for example), produces the following error in Webview console

index.html:1 Access to font at 'vscode-webview-resource://users/test/extension/out/fonts/font.ttf' from origin 'vscode-webview://7803497a-8232-4556-988a-7a1636d48b30' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
font.ttf:1 Failed to load resource: net::ERR_FAILED

This used to work fine in previous versions.

I have updated the webview HTML to support the new "vscode-webview-resource" as follows

      <meta http-equiv="Content-Security-Policy"
            content="default-src 'none';
                    font-src * data: blob: 'unsafe-inline' vscode-webview-resource:;
                   ">

Fonts are getting loaded in <style> tag as such:

Related issue: #97777

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

cc: @mjbvz

[mjbvz]

Can you please share some example extension code that demonstrates the issue

[ahmed-shehata]

I have done some digging and cornered down the issue to the following change:

it seems that asWebviewUri API has changed something with regard to the path, specifically adding a file/// in the path.

Before:

After:

Since we are relying on path to join the webview uri to the resource path, this file/// gets normalized to file/, which is a broken uri to VSCode resource management.

The solution/workaround is to pass the full joined path to vscode.Uri.file(...)before calling asWebviewUri on the path.

I'm not sure if this is an intended change or a bug, feel free to close it if it is intended.

[mjbvz]

Yes sounds like it may be a bug in the extension code. Can you share the code that generates the font's uri?

[ahmed-shehata]

Old way (worked before 1.47.2):

JS:

const fontPath = path.join(extensionPath, "out", "fonts", "font.ttf");

CSS:

@font-face {
        font-family: 'Font Name';
        font-style: normal;
        font-weight: normal;
        src:
          url(vscode-resource:${fontPath}) format('truetype');
      }

Fixed way:

JS

const fontPath = panel.webview.asWebviewUri(vscode.Uri.file(
    path.join(extensionPath, "out", "fonts", "font.ttf")
  ));

CSS

 @font-face {
                      font-family: 'Font Name';
                      font-style: normal;
                      font-weight: normal;
                      src:
                        url('${fontPath}') format('truetype');
                    }

[mjbvz]

Thanks. I believe this is expected.

Last iteration, we removed support for vscode-resource urls in favor of requiring extensions call asWebviewUri. While webviews attempt to automatically rewrite vscode-resource urls, it looks like we don't get this right in all cases. Using asWebviewUri is the proper fix and it also make it so your extension's webview just works VS Code is run in a browser.

You can also simplify your code by using joinPath:

const fontPath = panel.webview.asWebviewUri(vscode.Uri.file(
    vscode.Uri.joinPath(extensionUri, "out", "fonts", "font.ttf")
  ));