Only OSC 8 terminal hyperlinks with http/https scheme seem be to working

[jaminthorns]

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

• VS Code Version: 1.76.1
• OS Version: macOS 13.2.1 (22D68)

Steps to Reproduce

1. Print an OSC 8 hyperlink that uses a schema other than http or https. For example, the vscode URL scheme:

printf '\e]8;;vscode://file//Users/jaminthornsberry/.gitconfig:10\e\\Take me to git config!\e]8;;\e\n'

2. The text renders as a hyperlink (dotted underline), but isn't cmd/ctrl+clickable like other like OSC 8 hyperlinks with the http/https scheme. Other OSC 8-capable terminals (like WezTerm) will open the link correctly.

Demonstration

Here's a video demonstrating the issue with several other URL schemes:

Screen.Recording.2023-03-10.at.11.28.03.AM.mov

As you can see, only http and https URL schemes result in clickable links.

Comments

If I remember correctly, this regressed in the 1.74 -> 1.75 update, which leads me to believe it might be related the link improvements introduced in that version.

This functionality can be super useful for tools like Delta, which let you add hyperlinks to line numbers in diffs. When this functionality worked in VS Code 1.74, those links would be clickable:

[flying-sheep]

Since everything supported this, I relied on it, damn.

Would be amazing to have this back. Only non-heuristic way to get clickable file links in the terminal that handle all paths (e.g. paths with spaces)

[Tyriar]

We currently do not allow non-http(s) links due to allowNonHttpProtocols here:

vscode/src/vs/workbench/contrib/terminalContrib/links/browser/terminalLinkManager.ts

Lines 97 to 131 in d89cac9

	this._xterm.options.linkHandler = {
	activate: (_, text) => {
	this._openers.get(TerminalBuiltinLinkType.Url)?.open({
	type: TerminalBuiltinLinkType.Url,
	text,
	bufferRange: null!,
	uri: URI.parse(text)
	});
	},
	hover: (e, text, range) => {
	activeHoverDisposable?.dispose();
	activeHoverDisposable = undefined;
	activeTooltipScheduler?.dispose();
	activeTooltipScheduler = new RunOnceScheduler(() => {
	const core = (this._xterm as any)._core as IXtermCore;
	const cellDimensions = {
	width: core._renderService.dimensions.css.cell.width,
	height: core._renderService.dimensions.css.cell.height
	};
	const terminalDimensions = {
	width: this._xterm.cols,
	height: this._xterm.rows
	};
	activeHoverDisposable = this._showHover({
	viewportRange: convertBufferRangeToViewport(range, this._xterm.buffer.active.viewportY),
	cellDimensions,
	terminalDimensions
	}, this._getLinkHoverString(text, text), undefined, (text) => this._xterm.options.linkHandler?.activate(e, text, range));
	// Clear out scheduler until next hover event
	activeTooltipScheduler?.dispose();
	activeTooltipScheduler = undefined;
	}, this._configurationService.getValue('workbench.hover.delay'));
	activeTooltipScheduler.schedule();
	}
	};

https://github.com/Tyriar/xterm.js/blob/48184cc94f8d16f9dc240a30edae85973ecd7c92/src/browser/OscLinkProvider.ts#L70-L81

This may just be a case of adding that property to linkHandler, but we need to make sure it won't introduce a security issue.

[flying-sheep]

Hm, running code in a terminal generally means one trusts it. After all at this point it has access to a lot of things. Displaying data from untrusted sources without stripping ANSI escapes is more a problem of the tool displaying the data.

I think when a terminal link is hovered, VS Code should just show a little link target floaty thing that shows where the link points to. Other terminal emulators do that.

If you’re being paranoid, show a little ⚠ when a link label looks like an URI but the corresponding link points to another URI. But that’s a situation people have in the web all the time, so they should know it can happen.

[Tyriar]

@flying-sheep sure, but you can cat some file and it will evaluate sequences which is a common attack vector. The user is typically unaware that cat could result in execution and/or malicious links being inserted. The hover is probably sufficient, I would want to double check with someone on the team who has done some general URI handling when looking at the PR.

[jaminthorns]

@Tyriar I understand the reasoning for disabling this, as VS Code focuses pretty strongly on security given its popularity (workspace trust, confirmations when opening links, well-defined extension API), but would it be possible to allow non-HTTP hyperlinks in the terminal via a setting? Something like terminal.integrated.allowNonHttpHyperlinks = true?

It seems like implementing this would be a simple pass-through to xterm.js's allowNonHttpProtocols property on ILinkHandler (which you previously linked to). The setting could even have a security warning in its description. It'd be really nice to have this functionality back.

[flying-sheep]

Who needs to sign off on a decision here? This is affecting me pretty much daily (since my testing framework uses this and I simply can’t make VS Code behave)

[gaborcsardi]

If would be nice to support at least file:// links, so that one could open files within VS Code, by clicking on a link in a terminal.

[michprev]

+1, our framework uses OSC 8 links as one of the exclusive features vs competitors. Missing support in VS Code makes it irrelevant and degrades our productivity.

[Tyriar]

Easy testing below, only the first 2 work:

printf '\e]8;;http://github.com\e\\http scheme\e]8;;\e\n'
printf '\e]8;;https://github.com\e\\https scheme\e]8;;\e\n'
printf '\e]8;;file:///Users/tyriar/dev/microsoft/vscode\e\\file scheme\e]8;;\e\n'
printf '\e]8;;vscode://file/Users/tyriar/dev/microsoft/vscode:10\e\\vscode scheme (with line number)\e]8;;\e\n'
printf '\e]8;;mailto:foo@bar.com\e\\mailto scheme\e]8;;\e\n'

Note that we wouldn't be able to support any arbitrary link without additional work as there are security concerns.

[andreamah]

Easy testing below, only the first 2 work:

printf '\e]8;;http://github.com\e\\http scheme\e]8;;\e\n'
printf '\e]8;;https://github.com\e\\https scheme\e]8;;\e\n'
printf '\e]8;;file:///Users/tyriar/dev/microsoft/vscode\e\\file scheme\e]8;;\e\n'
printf '\e]8;;vscode://file/Users/tyriar/dev/microsoft/vscode:10\e\\vscode scheme (with line number)\e]8;;\e\n'
printf '\e]8;;mailto:foo@bar.com\e\\mailto scheme\e]8;;\e\n'

Note that we wouldn't be able to support any arbitrary link without additional work as there are security concerns.

Which terminal type should we test this in to verify the issue? @Tyriar

[Tyriar]

@andreamah bash should work

[jackzzs]

Is it possible to open "file:///Users/tyriar/dev/microsoft/vscode" link in vscode by default? In WSL, this link will do nothing.

[Tyriar]

@jackzzs yeah the file needs to exist for it to work

[jackzzs]

In Windows it works, but doesn't seem to work in WSL2.

This may be due to the fact that accessing the file link calls the system's open command, and wsl2 does not handle this kind of command.

Considering that the link is opened in vscode, is it a better way to open it in the current vscode editor instead of calling the system's open command to open another vscode window? And this will also fix the WSL problem.

[Tyriar]

@jackzzs are you connected to the window via the Remote - WSL extension? If not this is as expected currently.

[jackzzs]

Yes,

1. If I connect to the window using WSL remote extension, clicking the file:// url link will do nothing despite the file is existing. This is not so convenient.

2. If I connect to the window without remote extensions, clicking the file:// url link will open the file using system open call, resulting in a new vscode window. This is also not so convenient, especially for some rich logging libraries (that use file:// rather than vscode://file/ url for source file location)

[Tyriar]

@jackzzs created #211443 to track your 1. For 2 right now proper WSL link support only works within Remote - WSL windows, so making this work well in local windows would be a new feature request.

[jackzzs]

Thank you very much for your patient inspection and answer, looking forward to the fix.