Implement vscode-file:// support and drop node.js for window loading

[bpasero]

Continuation of #101837

Fixes #98682

Open issues:

• Testing
• UNC support (related: Electron has lots of issues with Windows UNC paths electron/electron#25618)
• V8 cached options support (needs Electron fix)
• Startup Perf validation
• Selfhosting

[bpasero]

After a bit more investigation who is depending on file protocol, I found this place to follow up:

• markdownRenderer.ts: @mjbvz are you the owner? I see a few Schemas.file references and wonder if we need to look into it. We seem to be allowing file paths in markdown but I am not sure who is crafting these. Some clients seem to be custom hover, notebooks, comments.

vscode/src/vs/base/browser/markdownRenderer.ts

Line 95 in ef4df1d

if (options.baseUrl && hrefAsUri.scheme === Schemas.file) { // absolute or relative local path, or file: uri

vscode/src/vs/base/browser/markdownRenderer.ts

Line 218 in ef4df1d

const allowedSchemes = [Schemas.http, Schemas.https, Schemas.mailto, Schemas.data, Schemas.file, Schemas.vscodeRemote, Schemas.vscodeRemoteResource];

[mjbvz]

@bpasero The allowed schemes ones is probably fine. That would be used for cases where markdown from an extension contains a link such as [link](file:///path/to/file.png), which our opener service can handle.

I believe that markdown content can load images using the file: protocol (although I will check that because our content security policy may block it)

[mjbvz]

Yes it looks like our markdown content does allow loading images using the file: protocol:

This is problematic because it allows reading images at any path, while the vscode-file scheme only allows reading from specific directories.

A first step may be to see how often file images are actually being used in markdown content. My guess it that it would not be very common, but maybe there are some extensions that rely on this functionality

[bpasero]

@mjbvz ok, this will no longer work once we enable to block file requests. I gave it a quick try with putting vscode-file URI instead but that was also not working, so I wonder where we actually convert that into HTML and if possibly that scheme is not allowed?

[mjbvz]

@bpasero Yes we limit the allowed scheme in a few places:

• When parsing the markdown:

  vscode/src/vs/base/browser/markdownRenderer.ts

  Line 218 in ee8378e

  const allowedSchemes = [Schemas.http, Schemas.https, Schemas.mailto, Schemas.data, Schemas.file, Schemas.vscodeRemote, Schemas.vscodeRemoteResource];

  Also potentially in

  vscode/src/vs/base/browser/markdownRenderer.ts

  Line 113 in ee8378e

  renderer.link = (href, title, text): string => {

• In the command handlers:

  vscode/src/vs/workbench/services/hover/browser/hoverWidget.ts

  Line 86 in f17d014

  callback: (content) => this._linkHandler(content),

[bpasero]

I just noticed that on Windows, when you cd into a UNC path via PowerShell and you try to run code or code-insiders, Windows will leave the UNC path to a non-UNC path because *.cmd do not support UNC paths. So we maybe OK here to proceed even if UNC paths fail. The only situation where VSCode would fail to start from UNC path is if someone was to start our exe directly.

[bpasero]

This PR is replaced by 169a0ec which gives us a way to enable vscode-file protocol in selfhost via:

• either setting export ENABLE_VSCODE_BROWSER_CODE_LOADING=bypassHeatCheck
• or argv.json entry: "enable-browser-code-loading": "bypassHeatCheck"

Other supported values are: 'none' | 'code' | 'bypassHeatCheck' | 'bypassHeatCheckAndEagerCompile'

I have enabled bypassHeatCheck for process explorer and issue reporter who were already using sandbox and vscode-file.

Turning this on by default is still blocked by electron/electron#27075