[Bug]: window.open("about:blank") replaces the preview page, which breaks MSAL login and its redirect fallback

[Reston]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. Open any page in a preview tab, for example http://localhost:3000/.

2. Run this in the page, for example from a click handler:

   const w = window.open('about:blank', 'popup', 'width=483,height=600')
   console.log(w) // null

3. The call returns null, and then the preview tab navigates to about:blank. The original page is gone.

This is how @azure/msal-browser opens its popup. With the default asyncPopups: false, loginPopup() and acquireTokenPopup() call window.open("about:blank", …) synchronously in the click handler, then set the popup's URL (PopupClient.openSizedPopup). Other SDKs pre-open a blank popup this way to keep the user gesture.

Expected behavior

If the preview won't open a real window for about:blank, it should deny the call without navigating the preview tab. window.open then returns null and the page stays as it was, which is what a normal popup blocker does. SDKs detect this case and fall back: MSAL throws popup_window_error, and apps typically call loginRedirect() next.

Actual behavior

The call is denied and the preview tab loads about:blank. MSAL throws popup_window_error, and the app's loginRedirect() fallback runs from a page that is already being replaced. The tab stays blank, with no Microsoft sign-in. Reading sessionStorage on that page then throws SecurityError: Access is denied for this document.

Cause, in apps/desktop/src/preview/Manager.ts on main (c2fa9fc911):

• isPopupUrl deliberately excludes about:blank, for the contextIsolation reason in its comment. So previewWindowOpenAction returns "navigate" for this new-window request.
• The setWindowOpenHandler in the preview attach path handles "navigate" with wc.loadURL(details.url) and returns { action: "deny" }. For about:blank, this loads a blank page over the opener.

Loading about:blank into the opener never helps. A possible fix: when the URL isn't a popup URL, for example about:blank or "", return { action: "deny" } without calling loadURL. The page then gets a plain blocked popup and can use its own fallback.

Related: #6561 / #8435 (OAuth popups for http(s) URLs) and #13953 (target="_blank" loads in place). The new-tab fix planned for #13953 covers http(s) tab dispositions, not this about:blank new-window case.

Impact

Blocks work completely

Version or commit

T3Code(Nightly)/0.0.44-nightly.20260929.2456 (Electron 44.4.2, Chrome 152.0.7977.130)

Environment

Ubuntu 26.04.1 LTS, Linux 7.0.0-34-generic

Logs or stack traces

[auth] loginPopup failed, trying loginRedirect BrowserAuthError: popup_window_error: Error opening popup window. This can happen if you are using IE or if popups are blocked in the browser.
    at createBrowserAuthError (...)
    at PopupClient.openPopup (...)
    at PopupClient.initiateAuthRequest (...)

Workaround

Two app-side options:

• In the page, replace window.open with a stub that returns null without calling the native handler. The redirect fallback then works: we confirmed a full sign-in through Microsoft this way.
• Detect Electron/ in the user agent and call loginRedirect() directly, without trying the popup.

[juliusmarminge]

Triage

Confirmed on main at c2fa9fc911, which ships the same Electron 44.4.2 as your nightly. This is a real desktop-preview bug. It isn't a duplicate of #13953 (open issue) or of the OAuth popup work in #6561 (closed issue) and #8435 (merged PR).

What happens. window.open("about:blank", …) with popup features arrives as a new-window request, and its URL fails isPopupUrl, which only allows http: and https:. about:blank is left out on purpose: Chromium copies the guest's contextIsolation: false preferences to it, and Electron won't let us override them (see isPopupUrl / previewWindowOpenAction in apps/desktop/src/preview/Manager.ts). So previewWindowOpenAction returns "navigate", and the preview's setWindowOpenHandler does two things:

• calls wc.loadURL(details.url), which replaces the preview page with about:blank
• returns { action: "deny" }, so window.open returns null

MSAL's default asyncPopups: false path relies on that synchronous blank popup. It throws popup_window_error, and loginRedirect() then runs on a page that's already being replaced. Reading sessionStorage on that about:blank page throws the SecurityError you saw. The same handler also runs for an empty URL, which Electron sometimes reports instead of about:blank. A foreground-tab disposition would hit "navigate" too, so the features string isn't what matters here.

Why the existing fixes don't cover it. #8435 fixed real http(s) popups and intentionally left blank URLs on the in-tab path, but loading about:blank into the opener never helps and destroys the page that would have handled a blocked popup. #13953 is about turning target="_blank" / window.open of http(s) URLs into new preview tabs, so its planned "new-tab" result doesn't touch this about:blank new-window case either.

Fix direction. Allowing a real about:blank window isn't an option, because the context-isolation constraint still applies. Instead, blank URLs ("" and about:blank) should get a plain deny with no loadURL. Other non-popup schemes (javascript:, file:, vscode:) can keep their current in-tab behavior. The test does not hand a window to schemes that cannot be hardened currently expects "navigate" for all of these and would need updating for the blank case.

After that change, window.open("about:blank") returns null and the preview page stays put, the same as with a normal popup blocker. loginPopup() will still fail, but your app's loginRedirect() fallback can then run. Both of your workarounds (stubbing window.open to return null, or skipping the popup when the user agent contains Electron/) end up in that same place. Thanks for the precise root-cause write-up.