Further support for custom browser specification

[stohn777]

Is your feature request related to a problem? Please describe.
No, and thank you for the -b flag on force:org:open that enables a more customizable experience with sfdx.

What are you trying to do
Having both Firefox and Firefox Developer installed, the new force:org:open -b flag for "firefox" opens the standard version, whereas for development work I prefer Firefox Developer.

Also I've seen comments asking about incognito or private browser instances.

Describe the solution you'd like
Explicitly supporting all permutations of browsers and options would quickly get out of hand. Therefore a more flexible solution is needed.

Enable the user to specify, perhaps in the config hierarchy, the browser program and options to be executed. In a Windows, private-window Firefox Developer situation, the config setting could be similar to "browser": "c:/Program Files/Firefox Developer Edition/firefox.exe -private-window". The syntax for supporting folders containing spaces is TBD. Perhaps the most canonical styles could be supported.

When an sfdx command offers the -b flag, provide a -B flag that takes the "path/program -flags" syntax. sfdx force:org:open -B "c:/Program Files/Firefox Developer Edition/firefox.exe -private-window". Again that path, file name, flags syntax is TBD.

The precedence would be:

1. Command specified browser
2. Config-sourced browser
3. OS default browser

Describe alternatives you've considered
None. But I'm happy to evolve the feature with others.

Additional context
None.

[git2gus[bot]]

This issue has been linked to a new work item: W-12264011

[github-actions[bot]]

Thank you for filing this feature request. We appreciate your feedback and will review the feature at our next grooming or sprint planning session. We prioritize feature requests with more upvotes and comments.

[WillieRuemmele]

We use the open library to open the browser here

adding those flags would be pretty easy to pass to the library as arguments

[stohn777]

Here's a Slack, Good Day, Sir conversation that could leverage this feature.
https://gooddaysir.slack.com/archives/C3BJMEH3J/p1694441454932179

This gist of the discussion is being able to open the browser with an explicit profile versus the default, which in Chrome's case could be achieved using the --profile-directory flag along with the support of this Discussion's feature.

This Slack group does not have long-term history enabled, so this link my become broken eventually.

[cristiand391]

thanks for link, just joined that workspace!

As others mentioned, the open library allows this use case:
https://github.com/sindresorhus/open#openappname-options

We don't have a bunch of commands that open a browser, but something we could do is to move all the open wrapper to sf-plugins-core and expose it as a method so any plugin that wants to open a browser follows the same preferences.

Like the GitHub CLI does, we could add support for SF_BROWSER env var to pass the path to the browser binary, and maybe SF_BROWSER_ARGS for all browser-specific flag/args.

In the meantime, you can use --url-only and pass that to the browser, example opening cd org in a new tab in firefox:

sf org open --url-only --target-org cd | xargs /Applications/Firefox.app/Contents/MacOS/firefox --new-tab

[bobalicious]

Since the output of sf org open --url-only contains more than just the URL, you need to get the URL out first, before piping. IMO, this is easiest done with jq. E.g.

sf org open --url-only --target-org yourOrg --json | jq '.result.url' | xargs "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --profile-directory="Profile 1"

[cristiand391]

ah right, there's a warning in the output, thanks!

After reading chrome/firefox CLI options, I think it might be tricky to make SF_BROWSER_ARGS work correctly (firefox expects the url right after --new-tab, so you would need to be very careful getting args in the right order).

SF_BROWSER would still be a good way to support most use-cases where users want to use a specific browser (and may even help WSL users).

Make sure to upvote discussions you are interested in, that'll help us prioritize feature requests 😄

[bobalicious]

I think that's a real shame - so SF_BROWSER_ARGS would be pretty advanced and you need them in the right order - well, so be it - feels like wanting to set up the browser args is itself pretty advanced.

In VSCode, at the moment, I've had to add a new extension just to add this different execution myself, and that feels like a big shame - if sf cli supported the flags, then the VSCode SF extension would probably catch up and it would all be coherent.

[cristiand391]

thanks for the feedback.

yeah, seems other tools also accept BROWSER_ARGS as an advanced feature: https://github.com/search?utf8=%E2%9C%93&q=BROWSER_ARGS&type=issues

with some examples and warnings should be fine I think, whenver SF_BROWSER and SF_BROWSER_ARGS is present sf will always put the url as the last arg before spawning the browser process.

[sjurgis]

Would love to see this too.
The problem with sf org open is that only works for opening authorized orgs.

If you are trying to authorize devhub or existing sandbox you are still forced to use your default browser, copy url into your preferred browser and then do the oauth dance.

And to throw a spanner into all of this - Illuminated Cloud in Jetbrains suite mostly respects my preferred browser that I've setup in Jetbrains itself. So the browser should be inherited from there instead of global/project based setting.

[stohn777]

If fact, this feature request surfaced from a browser conversation in the Illuminated Cloud 2 sphere, but at this time, I'd be hard-pressed to find a reference to it.

[SCWells72]

Here's the original discussion:

https://bitbucket.org/RoseSilverSoftware/illuminatedcloud/issues/1419

Just under a year ago I delivered a fix that allows things opened with force:org:open to use any browser supported by the host JetBrains IDE (which is to say any browser since it's just a command-line execution) by executing the CLI command using the -r flag to get the URL, then passing that URL to the IDE's configured browser.

As @sjurgis mentioned, unfortunately that doesn't work for force:auth:web:login as that CLI command must drive the browser itself, though, and it doesn't change the set of supported browsers for the CLI's own force:org:open command (continuing to use the "old" command syntax since that's how IC2 invokes the CLI).

I don't know if that helps or not -- my guess is that it probably doesn't -- but that's the historical context that was referenced.