Login Popup doesn't have any event on pop up close by user ends up into timeout error

[amolkurhe87]

Core Library

MSAL.js (@azure/msal-browser)

Core Library Version

5.6.1

Wrapper Library

MSAL Angular (@azure/msal-angular)

Wrapper Library Version

None

Public or Confidential Client?

Confidential

Description

Recently, we have migrated to 5.x and using msal-browser (5.6.1) version. We have implemented redirect bridge to handle popup communication as per COOP requirements.

When user clicks on sign in and on popup is opened, if user cancel it there is no updates post through event callback and sign in flow is blocked as interaction status is still in progress.
It takes more than 60s and ends up in the timeout error.

Is there alternate option to handle this scenario with v5.x while following COOP requirements? Am I missing anything her

Error Message

Error Message: Uncaught (in promise) BrowserAuthError: timed_out: See https://aka.ms/msal.js.errors#timed_out for details

Stack trace Details:
BrowserAuthError: timed_out
at BrowserAuthError.createMonitorWindowTimeoutError
at PopupHandler.monitorPopupForHash
(PopupHandler.ts)
at PopupClient.acquireTokenPopupAsync
(PopupClient.ts)
at StandardInteractionClient.acquireToken
(StandardInteractionClient.ts)
at PublicClientApplication.acquireTokenPopup
(PublicClientApplication.ts)
at PublicClientApplication.loginPopup
(PublicClientApplication.ts)

MSAL Logs

No response

Network Trace (Preferrably Fiddler)

• Sent
• Pending

MSAL Configuration

{
    auth: {
        clientId: '',
        authority: 'https://login.microsoftonline.com/common/',
        redirectUri: '<domain>/redirect',
    },
    cache: {
        cacheLocation: BrowserCacheLocation.LocalStorage
    }

Relevant Code Snippets

private async runAuthExclusive<T>(fn: () => Promise<T>): Promise<T> {
        if (this.pendingAuth) {
            try { await this.pendingAuth; } catch { }
        }
        const p = fn();
        this.pendingAuth = p;
        try {
            return await p;
        } finally {
            if (this.pendingAuth === p) this.pendingAuth = null;
        }
    }

public async signIn(authParams: any) {
        return this.runAuthExclusive(async () => {
            try {
                const response = await this.msalInstance.loginPopup({
                    ...authParams,
                    prompt: authParams.prompt ?? "select_account",
                    redirectUri: this.getPopupRedirectUri()
                });

                if (response?.account) {
                    this.setCurrentAccount(response.account);
                }
            } catch (e: any) {
                
                if (e instanceof BrowserAuthError && e.errorCode === "popup_window_error") {
                    await this.msalInstance.loginRedirect({
                        ...authParams,
                        prompt: authParams.prompt ?? "select_account",
                        redirectUri: this.getRedirectUri(),
                        redirectStartPage: window.location.href
                    });
                    return;
                }

                throw e;
            }
        });
    }

Reproduction Steps

1. Load UHF Me control on the page.
2. Set Me Control Configuration and pass signIn.bind(authModule) instance to me control config.
3. Set other configuration settings for MeControl as needed.
4. Run the application.

Expected Behavior

On Pop up close by user, there should an immediate updates to the caller/parent window or an event update to perform other operations like clear popup settings and unblock sign in flow UI interaction.

Identity Provider

Entra ID (formerly Azure AD) / MSA

Browsers Affected (Select all that apply)

Chrome, Edge, Firefox

Regression

@azure/msal-browser(3.x)

[DominikDoom]

I had the same issue after migrating, but was able to find a workaround. It feels a bit hacky, so I'm also open to a better solution or preferably if MSAL would handle this internally like before the redirect bridge was introduced, but this was the best I could find after a day of trying:

While the popup itself is no longer able to return the userCancelled error code, it's possible to check from the parent side by getting the popup window reference and then polling if it was closed. So for the app I'm working on, I created a small wrapper around the popup function calls that usually will just forward the result/error, but also checks if the window is still open every 500ms to manually reject the promise without having to wait for the timeout.

Edit: actually, I found my workaround is too unreliable for practical use, it often detects the popup window as closed even while it's still open (I think that's also due to COOP restricting access and treating the check as insecure). So I'm also back at the start.

[eliot-cole]

Could there be a wider (MS) issue, here? As I simply cannot login on Firefox ... (not hijacking, just pontificating)

[konstantin-msft]

Cross-Origin-Opener-Policy response header severes parent-child frame connection so capturing popup user cancellation event is no longer feasible. To mitigate this we introduced overrideInteractionInProgress flag for the popup flow. Please read here for more details.

[amolkurhe87]

I did try with overrideInteractionInProgress but it didn't work for me. I have observed MeControl is also having some updates hence confirming with their support. I can update back here as I get updates.

[konstantin-msft]

Closing due to no updates.