Breaking change in 1.25 in how external webpages are opened

[avanderhoorn]

• VSCode Version: 1.25
• OS Version: All

Steps to Reproduce:

1. Attempt to us vscode.commands.executeCommand('vscode.open', …) as per guidance in issues like Open an Http Url from extension #9651.
2. Below exception occurs

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

With the release of 1.25, people have started running into this exception - https://github.com/Microsoft/vscode/blob/fea449cc7616ce039e2c7e5845fb60136f84405e/src/vs/workbench/services/editor/browser/editorService.ts#L243.

I believe this is caused when we attempt to open an external browser window for auth. Currently we use vscode.commands.executeCommand('vscode.open', …) as per the guidance in issues like this - #9651.

I understand from the issue that we should be using IOpenerService, but I’m wondering if you can confirm that this is a conscious breaking change and not a regression for this user case (as I can’t find any docs on this).

// @bpasero @jrieken

[jrieken]

This is due to https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/services/editor/browser/editorService.ts#L238 and looks like it's done on purpose... I'll push a workaround and let @bpasero do the rest.

[eamodio]

@jrieken is this something extension will need to worry about? Or is this purely an internal thing?

[bpasero]

@jrieken your change makes sense to me, the idea was to stay away from having logic to open windows from http/https URLs in a service that is for opening editors.

I think I would even go one step further and just always use the IOpenerService instead of checking for the schema and using the IEditorService for some cases that can be handled. The IOpenerService is already leveraging the editor service for opening stuff in the editor that is neither http, https or a command. For that the only thing that seems to be missing is a way to forward the ViewColumn where to open.

[jrieken]

Yeah, I would have gone for the opener service but I wasn't sure about all those editor options. I looks like the open-command supports a wide interface, but I might be wrong

[bpasero]

@jrieken I can add those options to the opener service. One sort of breaking change however is that previously we did not support command:// resources from the vscode.open command (because the editor service never behaved like that) and now if we go through the opener service, they would be supported. I think that should be fine though.

[jrieken]

That rings a bell - there are security considerations regarding command links... I'd block them for now.

[bpasero]

Ok, we can preserve the current behaviour and just have a setting in the opener service to not execute command links.

[jrieken]

setting in the opener service to not execute command links.

Just to clarify that you mean an argument, not a property because it is per invocation/call. E.g trusted marked down can run commands, untrusted not

[bpasero]

@jrieken yeah I would make this exclusive to the vscode.open command as an argument of the open method to preserve the exact behaviour we have today.