URI encoding problems with vscode.env.openExternal

[RMacfarlane]

Issue Type: Bug

Steps:

1. Download the GitHub Pull Request VSIX, or create an extension with the following and package it:

export async function activate(context: vscode.ExtensionContext) {
	const callbackUri = await vscode.env.createAppUri({ payload: { path: '/did-authenticate' } });
	const uri = vscode.Uri.parse(`https://vscode-auth.github.com/authorize/?callbackUri=${encodeURIComponent(callbackUri.toString())}&responseType=code`);
	vscode.env.openExternal(uri);
}

2. Start web selfhost using the ./resources/server/web.sh script
3. Install either extension and reload
4. Use sign in command if using GHPR extension, or trigger activation of own extension

A dialog appears asking if you would like to open the external url:

Note here that the callbackUri parameter is only partially uri encoded - the only unencoded & should be before responseType=code. When opened, the link becomes something like https://vscode-auth.github.com/authorize/?callbackUri=http://localhost:9888/callback?vscode-requestId=ddb9fdd5-5cda-48e9-bbdd-62e23f94af2c&vscode-authority=rmacfarlane.test-extension&vscode-path=%2Fdid-authenticate&responseType=code, causing the query params of the callbackUri to be treated as top level query parameters.

VS Code version: Code - Insiders 1.40.0-insider (b7b2184, 2019-10-29T06:46:37.742Z)
OS version: Darwin x64 18.7.0

[jrieken]

Yeah, the idea of the work that went into the uri this month was to make it match the the behaviour of the whatwg-url, e.g the URL global found in browsers et al. So, the behaviour you are seeing is correct but I understand that it's breaking and unwanted - extension are built and tested against our bogus implementation and that's it. I will revert my changes and find a different path forward for fixing unwanted uri behaviour, e.g when opening links et al.

[jrieken]

fixed via 58479e8

[jrieken]

trying to go forward with this: #83645

[chakrihacker]

Facing this issue with vs live share extension, insiders