Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configuring a non-existing browser alias fails silently #223349

Closed
TylerLeonhardt opened this issue Jul 23, 2024 · 3 comments
Closed

Configuring a non-existing browser alias fails silently #223349

TylerLeonhardt opened this issue Jul 23, 2024 · 3 comments
Assignees
Labels
author-verification-requested Issues potentially verifiable by issue author bug Issue identified by VS Code Team member as probable bug help wanted Issues identified as good community contribution opportunities insiders-released Patch has been released in VS Code Insiders upstream Issue identified as 'upstream' component related (exists outside of VS Code) verified Verification succeeded workbench-browser
Milestone

Comments

@TylerLeonhardt
Copy link
Member

Testing #220989

Not sure if this is possible, but I set the workbench.externalBrowser to firefox even though I don't have Firefox... then I tried to open something and nothing happened. I was confused because I thought I had Firefox installed, but I guess I remembered incorrectly!

I think something like this is increasingly important in the workspace-setting level. Sure, the protection of this is behind Workspace Trust... but I don't seem to get any notification or indication that there's a setting applied that influences how VS Code opens the browser or if it's going to no-op.

Considering this setting influences things like user auth flows, I think we should try to do something here. I was surprised that no browser was opened when I attempted to log in to a GitHub extension... which makes sense if this setting is set to something invalid.

@bpasero bpasero changed the title Handle when browser isn't available? Configuring a non-existing browser alias fails silently Jul 26, 2024
@bpasero bpasero added bug Issue identified by VS Code Team member as probable bug help wanted Issues identified as good community contribution opportunities upstream Issue identified as 'upstream' component related (exists outside of VS Code) labels Jul 26, 2024
@bpasero
Copy link
Member

bpasero commented Jul 26, 2024

I think this might be reported as sindresorhus/open#272 and misses a fix or workaround.

If someone has an idea, either by contributing to https://github.com/sindresorhus/open or seeing what we can do here:

private async openExternalBrowser(url: string, defaultApplication?: string) {
const configuredBrowser = defaultApplication ?? this.configurationService.getValue<string>('workbench.externalBrowser');
if (!configuredBrowser) {
return shell.openExternal(url);
}
if (configuredBrowser.includes(posix.sep) || configuredBrowser.includes(win32.sep)) {
const browserPathExists = await Promises.exists(configuredBrowser);
if (!browserPathExists) {
this.logService.error(`Configured external browser path does not exist: ${configuredBrowser}`);
return shell.openExternal(url);
}
}
try {
const { default: open } = await import('open');
await open(url, {
app: {
// Use `open.apps` helper to allow cross-platform browser
// aliases to be looked up properly. Fallback to the
// configured value if not found.
name: Object.hasOwn(open.apps, configuredBrowser) ? open.apps[(configuredBrowser as keyof typeof open['apps'])] : configuredBrowser
}
});
} catch (error) {
this.logService.error(`Unable to open external URL '${url}' using browser '${configuredBrowser}' due to ${error}.`);
return shell.openExternal(url);
}
}

@bpasero bpasero added this to the August 2024 milestone Aug 19, 2024
@bpasero bpasero added the author-verification-requested Issues potentially verifiable by issue author label Aug 22, 2024
@vs-code-engineering vs-code-engineering bot added unreleased Patch has not yet been released in VS Code Insiders insiders-released Patch has been released in VS Code Insiders and removed unreleased Patch has not yet been released in VS Code Insiders labels Aug 24, 2024
Copy link

This bug has been fixed in the latest release of VS Code Insiders!

@TylerLeonhardt, you can help us out by commenting /verified if things are now working as expected.

If things still don't seem right, please ensure you're on version 36e4ddb of Insiders (today's or later - you can use Help: About in the command palette to check), and leave a comment letting us know what isn't working as expected.

Happy Coding!

@TylerLeonhardt
Copy link
Member Author

It appears that this is fixed by opening the default instead of what is configured. That makes sense to me.

@TylerLeonhardt TylerLeonhardt added the verified Verification succeeded label Aug 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author-verification-requested Issues potentially verifiable by issue author bug Issue identified by VS Code Team member as probable bug help wanted Issues identified as good community contribution opportunities insiders-released Patch has been released in VS Code Insiders upstream Issue identified as 'upstream' component related (exists outside of VS Code) verified Verification succeeded workbench-browser
Projects
None yet
Development

No branches or pull requests

2 participants