Reworking external opener implementation to allow configured openers to be called directly without a canOpen check

If the user has configured a specific external uri opener, we should always try to use that without first calling `canOpen` to filter down the list of openers.

This change also adds `ExternalUriOpenerEnablement` which allows an opener to mark itself as the preferred opener for a given uri. If only a single preferred opener is returned, it will be used automatically for that uri (although user configuration can override this)

extensions/simple-browser/src/extension.ts

@@ -49,15 +49,17 @@ export function activate(context: vscode.ExtensionContext) {
 		canOpenExternalUri(uri: vscode.Uri) {
 			const configuration = vscode.workspace.getConfiguration('simpleBrowser');
 			if (!configuration.get('opener.enabled', false)) {
-				return false;
+				return vscode.ExternalUriOpenerEnablement.Disabled;
 			}
 
 			const originalUri = new URL(uri.toString());
 			if (enabledHosts.has(originalUri.hostname)) {
-				return true;
+				return isWeb()
+					? vscode.ExternalUriOpenerEnablement.Preferred
+					: vscode.ExternalUriOpenerEnablement.Enabled;
 			}
 
-			return false;
+			return vscode.ExternalUriOpenerEnablement.Disabled;
 		},
 		openExternalUri(resolveUri: vscode.Uri) {
 			return manager.show(resolveUri.toString());
@@ -67,3 +69,8 @@ export function activate(context: vscode.ExtensionContext) {
 		label: localize('openTitle', "Open in simple browser"),
 	}));
 }
+
+function isWeb(): boolean {
+	// @ts-expect-error
+	return typeof navigator !== 'undefined' && vscode.env.uiKind === vscode.UIKind.Web;
+}