microsoft-authentication-library-for-dotnet icon indicating copy to clipboard operation
microsoft-authentication-library-for-dotnet copied to clipboard

[Bug] The WAM Popup Windows Are Sometimes Not on the Top When Launch from VSCode

Open msJinLei opened this issue 1 year ago • 5 comments

Library version used

N/A

.NET version

.net standard 2.0

Scenario

PublicClient - desktop app

Is this a new or an existing app?

The app is in production, and I have upgraded to a new version of MSAL

Issue description and reproduction steps

The customer reports that WAM window sometimes popup behind and they cannot see it initially.

Originally posted by @JeremyTBradshaw in https://github.com/Azure/azure-powershell/issues/25120#issuecomment-2241080827

Originally posted by @peter-bertok in https://github.com/Azure/azure-powershell/issues/24989

PowerShell console in Visual Studio Code is a case to reproduce the issue.

Relevant code snippets

enum GetAncestorFlags
{   
    GetParent = 1,
    GetRoot = 2,
    /// <summary>
    /// Retrieves the owned root window by walking the chain of parent and owner windows returned by GetParent.
    /// </summary>
    GetRootOwner = 3
}

/// <summary>
/// Retrieves the handle to the ancestor of the specified window.
/// </summary>
/// <param name="hwnd">A handle to the window whose ancestor is to be retrieved.
/// If this parameter is the desktop window, the function returns NULL. </param>
/// <param name="flags">The ancestor to be retrieved.</param>
/// <returns>The return value is the handle to the ancestor window.</returns>
[DllImport("user32.dll", ExactSpelling = true)]
static extern IntPtr GetAncestor(IntPtr hwnd, GetAncestorFlags flags);

[DllImport("kernel32.dll")]
static extern IntPtr GetConsoleWindow();

// This is your window handle!
public IntPtr GetConsoleOrTerminalWindow()
{
    IntPtr consoleHandle = GetConsoleWindow();
    IntPtr handle = GetAncestor(consoleHandle, GetAncestorFlags.GetRootOwner );
    
    return handle;
}

Expected behavior

WAM windows always popup on the front

Identity provider

Microsoft Entra ID (Work and School accounts and Personal Microsoft accounts)

Regression

No response

Solution and workarounds

The customers should look for the WAM popup very hard

msJinLei avatar Aug 12 '24 03:08 msJinLei

The key point here is that the terminal window is hosted in VS Code.

bgavrilMS avatar Aug 12 '24 07:08 bgavrilMS

Solution and workarounds
The customers should look for the WAM popup very hard

Is this for real? Your response to a fundamental break in the PowerShell login experience is a shrug?

ChristopherGLewis avatar Dec 11 '24 18:12 ChristopherGLewis

Solution and workarounds
The customers should look for the WAM popup very hard

Is this for real? Your response to a fundamental break in the PowerShell login experience is a shrug?

:-) I think you misunderstood. That "solution and workarounds" was just part of our bug filing template which is used to help us triage. The filer put that in as his/her honest answer, but it is not this repo's maintainer's response. Internally, we are still trying hard to find a solution.

rayluo avatar Dec 11 '24 18:12 rayluo

Any update on this? It continues to be a problem.

Providing some details in the hope it helps:

I'm always able to reproduce this from the latest VS Code and VS Code Insiders (1.101.0), Window PowerShell 5.1 or PowerShell 7.5.1, and Az.Accounts 5.5, running on Win11 fully patched.

Connect-AzAccount always seems to spawn behind the VS Code window furthest back/down the window stack.

So, if I have: VS Code #1 (top / front) Browser window VS Code #2 Outlook Browser window VS Code #3 Teams (bottom / back)

The sign in window will pop up behind VS Code #3 and in front of Teams. The order I open the VS Code window in does not matter. Whether I launch new VS Code windows from the app's File menu or Windows Task Bar / Start Menu does not matter.

The Azure CLI doesn't seem to do this with az login.

If you run pwsh -noprofile -command Connect-AzAccount from the VS Code terminal, it will launch in front.

Thanks!

dbaileyut avatar May 27 '25 23:05 dbaileyut

My theory is this: I think WAM and DWM on Windows 10 and 11 both stink. That's the problem here. Windows has no control over what windows should be on top of what other windows. It's been an issue ever since either thing existed and only some of the people inside Microsoft who develop things that use either WAM or DWM, know how to properly interact with it (feel free to replace "know" with "remember"). I would say even a smaller subset actually give a crap, and so these little annoying issues are just a way of life.

JeremyTBradshaw avatar Jun 06 '25 11:06 JeremyTBradshaw