Issue Opening Folder Using vscode.openFolder

[allileong]

• VSCode Version: 1.26.0-Insider (This issue is happening in Insiders only)
• OS Version: macOS 10.13.6

While running a custom extension, I execute:

vscode.commands.executeCommand(
     'vscode.openFolder',
     vscode.Uri.parse(
        <some-local-path>
     )
);

I get a 'Path does not exist error', even though the path exists.

Steps to Reproduce:

1. Run a custom extension
2. Execute the code snippet above

[ramya-rao-a]

cc @bpasero

[ramya-rao-a]

@allileong It works if you prefix the local path with file:/ for me. For example: file://Users/me/hello. Can you try that?

@jrieken In the stable bits of 1.25.1, this would work even without the prefix of the scheme. I am not sure if the api for Uri changed or the one for vscode.openFolder command. Regardless, this would be a breaking changes for extension authors.

[bpasero]

@aeschli maybe due to the changes for supporting URIs on the main side?

/cc @sandy081

[aeschli]

The vscode.openFolder command API hasn't changed. The second argument always was a URI.
The difference is that now we use that URI to open the folder, while before we used only uri.fsPath.

That surfaces the bug in the user code:
vscode.Uri.parse(<some-local-path>) is wrong.
It needs to be vscode.Uri.file(<some-local-path>).

The error message is confusing. The error message is shown when trying to open a worbench window on an invalid URI (in this case, a URI without scheme).
I suggest we improve that.

[allileong]

Hi @ramya-rao-a , prefixing the local path with file:/ gets me past the issue.

[aeschli]

@allileong Please use vscode.Uri.file. Thats the proper way to create a URI from a file path that works on all platforms.

[kieferrm]

@aeschli what you're saying is that our implementation of vscode.URI.parse behaves incorrectly. It's documented as:

		/**
		 * Create an URI from a string. Will throw if the given value is not
		 * valid.
		 *
		 * @param value The string value of an Uri.
		 * @return A new Uri instance.
		 */
		static parse(value: string): Uri;

but for local file path inputs it creates URIs without a mandatory scheme component, i.e. invalid URIs.

[jrieken]

you're saying is that our implementation of vscode.URI.parse behaves incorrectly

I don't think he is saying that. The issue is this: Uri.parse('c:\foo\bar') is different from Uri.file('c:\foo\bar'). The sample code is vscode.Uri.parse(<some-local-path>) which is incorrect, when you have path you must use Uri.file

[jrieken]

but for local file path inputs it creates URIs without a mandatory scheme component, i.e. invalid URIs.

We don't throw when uri components are missing, we only do little validation e.g. checking authority and path constraints etc

[jrieken]

I have experimented with enforcing that URIs must have a scheme... Un-commenting this code yields in many, many test failures and while the product starts we will likely see failure here and there. So, iff we want to support scheme-enforcement a coordinated effort is needed.

[aeschli]

We now throw an exception when invoking vscode.openFolder with an invalid (schema-less) URI.

[aeschli]

I change the fix to treat the missing schema gracefully. The URI without scheme is converted to a file:// URI. That change only applies to vscode.openFolder.

Extensions are advised to not rely on the workaround but change vscode.Uri.parse to vscode.Uri.file. Note that vscode.Uri.parse(<filename>) doesn't (and hasn't) work on Windows as drive letters (c:/) are treated as URI schemes and will not be part anymore of uri.fsPath.

[chrmarti]

@aeschli The warning message doesn't expand ${uri} because it is not in a template string. Verified otherwise.

[aeschli]

@chrmarti Good catch, I added a fix. I also improved the fix to use URI.file(uri.toString()) as alternative URL (then it also works on windows).

[aeschli]

@chrmarti If you can verify again that would be great

[sandy081]

Thanks @aeschli for the fix