Merged
Conversation
Let's not crash the process if we are unable to launch PowerShell to determine the Windows session ID. Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
Given that the ISessionManager has the ability to determine if a web browser is available (via `IsWebBrowserAvailable`), it's only natural that this is the component that should also be responsible for actually launching the browser. We remove the `BrowserUtils` class and transpose its only method (`OpenDefaultBrowser`) to the session manager component. This means we can keep the Linux-specific behaviour in a scoped component. Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
…2261) Given that the ISessionManager has the ability to determine if a web browser is available (via `IsWebBrowserAvailable`), it's only natural that this is the component that should also be responsible for actually launching the browser. We remove the `BrowserUtils` class and transpose its only method (`OpenDefaultBrowser`) to the session manager component. This means we can keep the Linux-specific behaviour in a scoped component.
Let's not crash the process if we are unable to launch PowerShell to determine the Windows session ID.
Since we have special handling on Linux (eg WSL support), we try to use our own logic for launching the user's default web browser for interactive authentication. In the event we fail to start the browser, we fall back to using MSAL's logic, with a preference of Edge (Chromium-based) - largely because this is the only way to hook ourselves back into MSAL's default handling. Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
In non-WSL environments we make our checks for a browser more robust by checking for a 'shell execute' handler (like xdg-open). Previously we just relied on a desktop session ($DISPLAY or $WAYLAND_DISPLAY), which isn't accurate since in `OpenBrowser` we require a shell execute handler. The check and implementation are now aligned! We refactor the method to avoid nesting `if`s and use early returns to make things a little clearer. Helped-by: Marc Becker <becm@gmx.de> Co-authored-by: Kyle Rader <kyrader@microsoft.com> Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
In a Visual Studio Code remote session, we may be able to launch a browser without the `DISPLAY` environment variable set. This is because VSCode sets the `BROWSER` environment variable in remote sessions, such that it can forward requests to start a browser to the client machine. However! There are several types of remote session in VSCode, and the way they handle automatic port forwarding differs slightly. Since a very common case in GCM for launching the user browser is the ability to connect back to GCM via localhost:<port>, we only consider a subset of remote sessions to be able to launch a browser: * Remote SSH [YES] * Dev Containers [YES] * Remote Tunnel [NO] Sadly, for whatever reason, the remote connection over Microsoft Dev Tunnels does NOT automatically surface a forwarded port to localhost on the client. The forwarded port is only available via the devtunnels.ms URLs. Detecting the different types of remote session is tricky as it's not always as explicit as we'd like. All types: VSCODE_IPC_HOOK_CLI is set. Dev Containers : REMOTE_CONTAINERS is set. Remote SSH : SSH_CONNECTION is set. Remote Tunnel : absense of REMOTE_CONTAINERS and SSH_CONNECTION. Note, when starting a tunnel server from a regular SSH connection the SSH_CONNECTION variable gets inherited by the tunnel connections themselves! This means we need to also check for the absence of SSH_TTY because the tunnel server unsets this. SSH_TTY is set only in regular SSH sessions. Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
Since we have special handling on Linux (eg WSL support), we try to use our own logic for launching the user's default web browser for interactive authentication. In the event we fail to start the browser, we fall back to using MSAL's logic, with a preference of Edge (Chromium-based) - largely because this is the only way to hook ourselves back into MSAL's default handling.
In non-WSL environments we make our checks for a browser more robust by checking for a 'shell execute' handler (like xdg-open). Previously we just relied on a desktop session (`DISPLAY` or `WAYLAND_DISPLAY`), which isn't accurate since in `OpenBrowser` we require a shell execute handler. The check and implementation are now aligned! In a Visual Studio Code remote session, we may be able to launch a browser without the `DISPLAY` environment variable set. This is because VSCode sets the `BROWSER` environment variable in remote sessions, such that it can forward requests to start a browser to the client machine. However! There are several types of remote session in VSCode, and the way they handle automatic port forwarding differs slightly. Since a very common case in GCM for launching the user browser is the ability to connect back to GCM via `localhost:<port>`, we only consider a subset of remote sessions to be able to launch a browser: * Remote SSH ✅ <img width="186" height="48" alt="image" src="https://github.com/user-attachments/assets/49778759-52a8-42b0-87f1-f08d6ed54677" /> * Dev Containers ✅ <img width="140" height="54" alt="image" src="https://github.com/user-attachments/assets/36fb5c43-23a9-473e-83db-f4841335253a" /> * Remote Tunnel ❌ <img width="148" height="51" alt="image" src="https://github.com/user-attachments/assets/a682b49a-1056-4f2b-95e2-a759c70046c5" /> Sadly, for whatever reason, the remote connection over Microsoft Dev Tunnels does NOT automatically surface a forwarded port to localhost on the client. The forwarded port is only available via the devtunnels.ms URLs. Dev Tunnels|SSH -|- <img width="731" height="130" alt="image" src="https://github.com/user-attachments/assets/d8c33c92-6fa7-4bb0-a914-7bd57cea9a10" />|<img width="647" height="92" alt="image" src="https://github.com/user-attachments/assets/92dc6ac7-c94b-4c30-a640-d38b1e3e1dd6" /> Detecting the different types of remote session is tricky as it's not always as explicit as we'd like. All types: `VSCODE_IPC_HOOK_CLI` is set. Dev Containers : `REMOTE_CONTAINERS` is set. Remote SSH : `SSH_CONNECTION` is set. Remote Tunnel : absense of `REMOTE_CONTAINERS` and `SSH_CONNECTION`. Note, when starting a tunnel server from a regular SSH connection the `SSH_CONNECTION` variable gets inherited by the tunnel connections themselves! This means we need to also check for the absence of `SSH_TTY` because the tunnel server unsets this. `SSH_TTY` is set only in regular SSH sessions.
Contributor
Author
|
Install from source (Ubuntu) failure is a known issue. That version of Ubuntu is using a broken |
dscho
approved these changes
Feb 11, 2026
This comment was marked as spam.
This comment was marked as spam.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changes: