fix(desktop): oauth popups open from the browser preview

[walid-baharwal]

What Changed

Two changes, both needed for an OAuth popup to work in the integrated browser preview.

apps/web/src/browser/HostedBrowserWebview.tsx sets allowpopups as an attribute on the <webview> element instead of from the ref callback. Electron reads that flag when the guest attaches, and the ref callback runs after the element is already in the DOM, so every preview guest attached with popups disabled.

apps/desktop/src/preview/Manager.ts reads the disposition the window-open handler already received. A new-window disposition with an http or https URL now opens a real window; everything else, target="_blank" links included, keeps loading in the preview tab as before. The popup is created with contextIsolation, sandbox, and nodeIntegration: false set explicitly, since a popup is not a webview attach and never passes the will-attach-webview hardening in DesktopWindow. It also gets a deny-only window-open handler of its own, so a page inside it cannot spawn native windows without limit. about:blank popups keep loading in the preview tab: Chromium copies the guest preferences for them and gives no way to override.

Why

A local app opened in the preview cannot finish an OAuth popup flow. Firebase signInWithPopup(auth, new GoogleAuthProvider()) reports auth/popup-blocked and no window appears, while the same app works in a normal Chrome or Firefox window.

Two separate causes stack up. window.open was denied and the URL was force-loaded into the same webContents, so window.open() returned null (the SDK reads that as a blocked popup) and the in-tab load destroyed the opener the popup needs to postMessage its credential back to. Underneath that, the guest attached with allowpopups false, so Electron blocked the call before the handler ran at all.

Instrumenting will-attach-webview in a running desktop build showed it directly:

[popup-debug attach-webview] {"partition":"persist:t3code-preview-…","allowpopups":false} before
[popup-debug attach-webview] {"partition":"persist:t3code-preview-…","allowpopups":true} after

Surfaces

Desktop only in behavior. The <webview> element lives in apps/web because the desktop app wraps the web client, but the tag only exists inside Electron and remote web previews never reach setWindowOpenHandler. No contract, provider, or docs change.

UI Changes

No layout, styling, or motion changed. The observable difference is whether a popup window exists, captured below in a dev build against a local page that calls window.open(url, name, "width=520,height=640"), the same shape signInWithPopup uses.

Before

window.open() returns null and no window opens.

After

window.open() returns a window handle.

The popup window itself, sized from the requested window features:

Verification

Run in a dev desktop build (dev:desktop) with the preview open on a local page:

• Scripted popup: window.open(...) returns a handle. Handler logged disposition: "new-window" and decided popup.
• The popup reports window.opener present and typeof require === "undefined", so the opener survives and the hardening applied.
• A nested window.open from inside the popup returns null.
• A target="_blank" link logs disposition: "foreground-tab", decides navigate, and loads in the preview tab.
• previewWindowOpenAction has focused unit tests next to isPreviewRefreshShortcut, the existing pure helper in the same file.

Checks run locally:

• vp test run apps/desktop/src/preview/Manager.test.ts — 66 passed
• tsgo --noEmit in apps/web and apps/desktop — clean
• vp lint and vp fmt --check on the changed files — clean

The attach-timing half is not unit-testable in a meaningful way. A rendered-DOM assertion passes either way, because the ref callback does set the attribute, just too late for Electron to read it.

Checklist

• This PR is small and focused
• I explained what changed and why
• Before/after evidence included

Fixes#6561

Written with Claude Opus 5 in Claude Code.

---

Note

Medium Risk
Changes preview navigation and spawns hardened native windows from third-party pages; security-sensitive but scoped to http/https scripted popups with explicit hardening and nested popup denial.

Overview
Fixes OAuth and other scripted window.open flows in the integrated browser preview by enabling popups at attach time and opening real windows when appropriate instead of navigating the preview tab.

HostedBrowserWebview sets allowpopups="true" on the <webview> element at render time (not in a ref callback), so Electron sees it before the guest attaches.

PreviewManager adds previewWindowOpenAction: scripted popups (new-window + http:/https:) are allowed as separate BrowserWindows with contextIsolation, sandbox, and no Node integration; target="_blank" and non-hardenable URLs (about:blank, file:, javascript:, etc.) still load in the preview tab. Child OAuth windows get a deny-all setWindowOpenHandler via did-create-window.

Unit tests cover the new helper’s popup vs navigate decisions.

^{Reviewed by Cursor Bugbot for commit 3f60be1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix OAuth popups in desktop browser preview with hardened window.open handling

• Adds previewWindowOpenAction in Manager.ts to classify window.open requests: http/https scripted popups return 'popup' and open as real BrowserWindows; target=_blank tabs and disallowed/invalid schemes (about, javascript, file, vscode) return 'navigate' and load in the existing preview tab.
• New popup windows use hardened webPreferences (contextIsolation: true, nodeIntegration: false, sandbox: true) and deny further window.open calls from within them.
• Fixes HostedBrowserWebview.tsx so the <webview> element reliably gets the allowpopups attribute at attach time.
• Behavioral Change: setWindowOpenHandler now receives full details and uses details.url instead of bare url; non-http(s) URLs that previously may have opened as popups now navigate the current tab instead.

^{Macroscope summarized 3f60be1.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: e56baf0c-bdec-4082-8fa9-d71789606066

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

One finding in the web scope: the new allowpopups JSX attribute is the right ownership fix, but its string value conflicts with React's element typing, so apps/web typecheck (tsgo --noEmit) breaks. Details inline.

^{Posted via Macroscope — UI Consistency}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 0604de5. Configure here.}

[cursor]

Popup may inherit picker preload

High Severity

POPUP_WINDOW_OPTIONS overrides isolation flags but never clears preload. Electron merges overrideBrowserWindowOptions with the guest's preferences, so the picker preload can still run in the OAuth window and observe keystrokes and clicks on a third-party login page.

Additional Locations (1)

• apps/desktop/src/preview/Manager.ts#L1769-L1771

^{Reviewed by Cursor Bugbot for commit 0604de5. Configure here.}

[walid-baharwal]

I could not reproduce this one, so I am leaving the code as is. Details, in case I tested the wrong thing.

A popup opened from a webview guest does not inherit the guest's preload, with or without overrideBrowserWindowOptions. I checked with a standalone Electron 41.5.0 app that mirrors the preview setup: a <webview allowpopups> with a preload and contextIsolation=false, whose preload announces itself over IPC on load, then window.open(...) from inside the guest.

The preload reports from the guest and never from the popup:

RESULT preload-ran in: http://127.0.0.1:8899/popup-repro.html
RESULT popup created:

Same result with the override removed, and same with data: and http: popup URLs, so the override is not what is clearing it — the inheritance does not happen in the first place.

One thing worth flagging for anyone reading this later: webContents.getLastWebPreferences() does not report preload at all. It omits the key even for the guest, which definitely has one, so it cannot be used to check this.

If you have a case where the preload does reach the popup, I would like to see it — the exposure you describe would be real, since that preload listens for keydown and pointerdown.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR changes production preview behavior by enabling OAuth popup windows and altering Electron renderer security boundaries across the desktop and webview layers. An unresolved security concern about the preview preload potentially reaching third-party OAuth pages still requires validation.

Notes:

• No code objects were reviewed. Approvability was decided on eligibility alone.

^{You can add or adjust custom eligibility rules. Learn more.}

[MatthewFeroz]

hoping this gets merged!

[MatthewFeroz]

I double-checked the preload concern in Electron 41.5.0 and tested it myself. The preview’s preload script ran only inside the preview, not inside the popup. Electron’s code also confirms that preload scripts are not copied into new windows. This matches the author’s test, so I don’t think the Cursor warning is a real issue.

[walid-baharwal]

Status summary, since the Approvability verdict above predates the current head and reads as the most visible signal on this PR.

That verdict was posted at 8fa05ae and gives one reason: the preview picker preload may still execute in the popup and observe input. Two independent checks say it does not.

I tested it with a standalone Electron 41.5.0 app mirroring the preview setup — a <webview allowpopups> with a preload and contextIsolation=false, the preload announcing itself over IPC. It reports from the guest and never from the popup, with and without overrideBrowserWindowOptions, for both data: and http: popup URLs. @MatthewFeroz reproduced this independently and additionally checked Electron's source, which does not copy preload scripts into new windows.

Worth flagging for anyone testing this themselves: webContents.getLastWebPreferences() omits preload entirely, even for a webContents that has one, so it cannot be used to check this.

The popup is also created with contextIsolation: true, sandbox: true, nodeIntegration: false — verified at runtime as typeof require === "undefined" inside it — and denies its own window.open, so it cannot spawn further windows.

Current head is 8db8d83. All checks green, including Macroscope UI Consistency after the typing fix. Locally: 66 tests in Manager.test.ts pass, tsgo --noEmit clean for apps/web and apps/desktop, lint and format clean on the changed files.

No action needed from me unless something new turns up.

[MatthewFeroz]

Just sent a video to the maintainers of this working. Small limitation in this is that passkeys don't function but I think that's out of scope for this PR. Great work!

[walid-baharwal]

Thanks for running it and recording the video — I could not produce one myself, so that fills the gap CONTRIBUTING asks for on interaction changes.

On passkeys: that is pre-existing and tracked separately in #5665 ("In app browser not triggering passkey fingerprint to sign in on mac", open since 2026-08-07), so it predates this branch. Nothing here touches WebAuthn — the change only decides whether window.open gets a real window and what preferences that window is created with. A passkey prompt failing inside the preview fails the same way on main today, with or without a popup involved.

So I agree it is out of scope, and I would rather not widen this PR to chase it.

[walid-baharwal]

What Changed

Two changes, both needed for an OAuth popup to work in the integrated browser preview.

apps/web/src/browser/HostedBrowserWebview.tsx sets allowpopups as an attribute on the <webview> element instead of from the ref callback. Electron reads that flag when the guest attaches, and the ref callback runs after the element is already in the DOM, so every preview guest attached with popups disabled.

apps/desktop/src/preview/Manager.ts reads the disposition the window-open handler already received. A new-window disposition with an http or https URL now opens a real window; everything else, target="_blank" links included, keeps loading in the preview tab as before. The popup is created with contextIsolation, sandbox, and nodeIntegration: false set explicitly, since a popup is not a webview attach and never passes the will-attach-webview hardening in DesktopWindow. It also gets a deny-only window-open handler of its own, so a page inside it cannot spawn native windows without limit. about:blank popups keep loading in the preview tab: Chromium copies the guest preferences for them and gives no way to override.

Why

A local app opened in the preview cannot finish an OAuth popup flow. Firebase signInWithPopup(auth, new GoogleAuthProvider()) reports auth/popup-blocked and no window appears, while the same app works in a normal Chrome or Firefox window.

Two separate causes stack up. window.open was denied and the URL was force-loaded into the same webContents, so window.open() returned null (the SDK reads that as a blocked popup) and the in-tab load destroyed the opener the popup needs to postMessage its credential back to. Underneath that, the guest attached with allowpopups false, so Electron blocked the call before the handler ran at all.

Instrumenting will-attach-webview in a running desktop build showed it directly:

[popup-debug attach-webview] {"partition":"persist:t3code-preview-…","allowpopups":false} before
[popup-debug attach-webview] {"partition":"persist:t3code-preview-…","allowpopups":true} after

Surfaces

Desktop only in behavior. The <webview> element lives in apps/web because the desktop app wraps the web client, but the tag only exists inside Electron and remote web previews never reach setWindowOpenHandler. No contract, provider, or docs change.

UI Changes

No layout, styling, or motion changed. The observable difference is whether a popup window exists, captured below in a dev build against a local page that calls window.open(url, name, "width=520,height=640"), the same shape signInWithPopup uses.

Before

window.open() returns null and no window opens.

After

window.open() returns a window handle.

The popup window itself, sized from the requested window features:

Verification

Run in a dev desktop build (dev:desktop) with the preview open on a local page:

• Scripted popup: window.open(...) returns a handle. Handler logged disposition: "new-window" and decided popup.
• The popup reports window.opener present and typeof require === "undefined", so the opener survives and the hardening applied.
• A nested window.open from inside the popup returns null.
• A target="_blank" link logs disposition: "foreground-tab", decides navigate, and loads in the preview tab.
• previewWindowOpenAction has focused unit tests next to isPreviewRefreshShortcut, the existing pure helper in the same file.

Checks run locally:

• vp test run apps/desktop/src/preview/Manager.test.ts — 66 passed
• tsgo --noEmit in apps/web and apps/desktop — clean
• vp lint and vp fmt --check on the changed files — clean

The attach-timing half is not unit-testable in a meaningful way. A rendered-DOM assertion passes either way, because the ref callback does set the attribute, just too late for Electron to read it.

Checklist

• This PR is small and focused
• I explained what changed and why
• Before/after evidence included

Fixes#6561

Written with Claude Opus 5 in Claude Code.

---

Note

Medium Risk
Changes preview navigation and spawns hardened native windows from third-party pages; security-sensitive but scoped to http/https scripted popups with explicit hardening and nested popup denial.

Overview
Fixes OAuth and other scripted window.open flows in the integrated browser preview by enabling popups at attach time and opening real windows when appropriate instead of navigating the preview tab.

HostedBrowserWebview sets allowpopups="true" on the <webview> element at render time (not in a ref callback), so Electron sees it before the guest attaches.

PreviewManager adds previewWindowOpenAction: scripted popups (new-window + http:/https:) are allowed as separate BrowserWindows with contextIsolation, sandbox, and no Node integration; target="_blank" and non-hardenable URLs (about:blank, file:, javascript:, etc.) still load in the preview tab. Child OAuth windows get a deny-all setWindowOpenHandler via did-create-window.

Unit tests cover the new helper’s popup vs navigate decisions.

^{Reviewed by Cursor Bugbot for commit 3f60be1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix OAuth popups in desktop browser preview with hardened window.open handling

• Adds previewWindowOpenAction in Manager.ts to classify window.open requests: http/https scripted popups return 'popup' and open as real BrowserWindows; target=_blank tabs and disallowed/invalid schemes (about, javascript, file, vscode) return 'navigate' and load in the existing preview tab.
• New popup windows use hardened webPreferences (contextIsolation: true, nodeIntegration: false, sandbox: true) and deny further window.open calls from within them.
• Fixes HostedBrowserWebview.tsx so the <webview> element reliably gets the allowpopups attribute at attach time.
• Behavioral Change: setWindowOpenHandler now receives full details and uses details.url instead of bare url; non-http(s) URLs that previously may have opened as popups now navigate the current tab instead.

^{Macroscope summarized 3f60be1.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: e56baf0c-bdec-4082-8fa9-d71789606066

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

One finding in the web scope: the new allowpopups JSX attribute is the right ownership fix, but its string value conflicts with React's element typing, so apps/web typecheck (tsgo --noEmit) breaks. Details inline.

^{Posted via Macroscope — UI Consistency}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 0604de5. Configure here.}

[cursor]

Popup may inherit picker preload

High Severity

POPUP_WINDOW_OPTIONS overrides isolation flags but never clears preload. Electron merges overrideBrowserWindowOptions with the guest's preferences, so the picker preload can still run in the OAuth window and observe keystrokes and clicks on a third-party login page.

Additional Locations (1)

• apps/desktop/src/preview/Manager.ts#L1769-L1771

^{Reviewed by Cursor Bugbot for commit 0604de5. Configure here.}

[walid-baharwal]

I could not reproduce this one, so I am leaving the code as is. Details, in case I tested the wrong thing.

A popup opened from a webview guest does not inherit the guest's preload, with or without overrideBrowserWindowOptions. I checked with a standalone Electron 41.5.0 app that mirrors the preview setup: a <webview allowpopups> with a preload and contextIsolation=false, whose preload announces itself over IPC on load, then window.open(...) from inside the guest.

The preload reports from the guest and never from the popup:

RESULT preload-ran in: http://127.0.0.1:8899/popup-repro.html
RESULT popup created:

Same result with the override removed, and same with data: and http: popup URLs, so the override is not what is clearing it — the inheritance does not happen in the first place.

One thing worth flagging for anyone reading this later: webContents.getLastWebPreferences() does not report preload at all. It omits the key even for the guest, which definitely has one, so it cannot be used to check this.

If you have a case where the preload does reach the popup, I would like to see it — the exposure you describe would be real, since that preload listens for keydown and pointerdown.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR changes production preview behavior by enabling OAuth popup windows and altering Electron renderer security boundaries across the desktop and webview layers. An unresolved security concern about the preview preload potentially reaching third-party OAuth pages still requires validation.

Notes:

• No code objects were reviewed. Approvability was decided on eligibility alone.

^{You can add or adjust custom eligibility rules. Learn more.}

[MatthewFeroz]

hoping this gets merged!

[MatthewFeroz]

I double-checked the preload concern in Electron 41.5.0 and tested it myself. The preview’s preload script ran only inside the preview, not inside the popup. Electron’s code also confirms that preload scripts are not copied into new windows. This matches the author’s test, so I don’t think the Cursor warning is a real issue.

[walid-baharwal]

Status summary, since the Approvability verdict above predates the current head and reads as the most visible signal on this PR.

That verdict was posted at 8fa05ae and gives one reason: the preview picker preload may still execute in the popup and observe input. Two independent checks say it does not.

I tested it with a standalone Electron 41.5.0 app mirroring the preview setup — a <webview allowpopups> with a preload and contextIsolation=false, the preload announcing itself over IPC. It reports from the guest and never from the popup, with and without overrideBrowserWindowOptions, for both data: and http: popup URLs. @MatthewFeroz reproduced this independently and additionally checked Electron's source, which does not copy preload scripts into new windows.

Worth flagging for anyone testing this themselves: webContents.getLastWebPreferences() omits preload entirely, even for a webContents that has one, so it cannot be used to check this.

The popup is also created with contextIsolation: true, sandbox: true, nodeIntegration: false — verified at runtime as typeof require === "undefined" inside it — and denies its own window.open, so it cannot spawn further windows.

Current head is 8db8d83. All checks green, including Macroscope UI Consistency after the typing fix. Locally: 66 tests in Manager.test.ts pass, tsgo --noEmit clean for apps/web and apps/desktop, lint and format clean on the changed files.

No action needed from me unless something new turns up.

[MatthewFeroz]

Just sent a video to the maintainers of this working. Small limitation in this is that passkeys don't function but I think that's out of scope for this PR. Great work!

[walid-baharwal]

Thanks for running it and recording the video — I could not produce one myself, so that fills the gap CONTRIBUTING asks for on interaction changes.

On passkeys: that is pre-existing and tracked separately in #5665 ("In app browser not triggering passkey fingerprint to sign in on mac", open since 2026-08-07), so it predates this branch. Nothing here touches WebAuthn — the change only decides whether window.open gets a real window and what preferences that window is created with. A passkey prompt failing inside the preview fails the same way on main today, with or without a popup involved.

So I agree it is out of scope, and I would rather not widen this PR to chase it.

[walid-baharwal]

What Changed

Two changes, both needed for an OAuth popup to work in the integrated browser preview.

apps/web/src/browser/HostedBrowserWebview.tsx sets allowpopups as an attribute on the <webview> element instead of from the ref callback. Electron reads that flag when the guest attaches, and the ref callback runs after the element is already in the DOM, so every preview guest attached with popups disabled.

apps/desktop/src/preview/Manager.ts reads the disposition the window-open handler already received. A new-window disposition with an http or https URL now opens a real window; everything else, target="_blank" links included, keeps loading in the preview tab as before. The popup is created with contextIsolation, sandbox, and nodeIntegration: false set explicitly, since a popup is not a webview attach and never passes the will-attach-webview hardening in DesktopWindow. It also gets a deny-only window-open handler of its own, so a page inside it cannot spawn native windows without limit. about:blank popups keep loading in the preview tab: Chromium copies the guest preferences for them and gives no way to override.

Why

A local app opened in the preview cannot finish an OAuth popup flow. Firebase signInWithPopup(auth, new GoogleAuthProvider()) reports auth/popup-blocked and no window appears, while the same app works in a normal Chrome or Firefox window.

Two separate causes stack up. window.open was denied and the URL was force-loaded into the same webContents, so window.open() returned null (the SDK reads that as a blocked popup) and the in-tab load destroyed the opener the popup needs to postMessage its credential back to. Underneath that, the guest attached with allowpopups false, so Electron blocked the call before the handler ran at all.

Instrumenting will-attach-webview in a running desktop build showed it directly:

[popup-debug attach-webview] {"partition":"persist:t3code-preview-…","allowpopups":false} before
[popup-debug attach-webview] {"partition":"persist:t3code-preview-…","allowpopups":true} after

Surfaces

Desktop only in behavior. The <webview> element lives in apps/web because the desktop app wraps the web client, but the tag only exists inside Electron and remote web previews never reach setWindowOpenHandler. No contract, provider, or docs change.

UI Changes

No layout, styling, or motion changed. The observable difference is whether a popup window exists, captured below in a dev build against a local page that calls window.open(url, name, "width=520,height=640"), the same shape signInWithPopup uses.

Before

window.open() returns null and no window opens.

After

window.open() returns a window handle.

The popup window itself, sized from the requested window features:

Verification

Run in a dev desktop build (dev:desktop) with the preview open on a local page:

• Scripted popup: window.open(...) returns a handle. Handler logged disposition: "new-window" and decided popup.
• The popup reports window.opener present and typeof require === "undefined", so the opener survives and the hardening applied.
• A nested window.open from inside the popup returns null.
• A target="_blank" link logs disposition: "foreground-tab", decides navigate, and loads in the preview tab.
• previewWindowOpenAction has focused unit tests next to isPreviewRefreshShortcut, the existing pure helper in the same file.

Checks run locally:

• vp test run apps/desktop/src/preview/Manager.test.ts — 66 passed
• tsgo --noEmit in apps/web and apps/desktop — clean
• vp lint and vp fmt --check on the changed files — clean

The attach-timing half is not unit-testable in a meaningful way. A rendered-DOM assertion passes either way, because the ref callback does set the attribute, just too late for Electron to read it.

Checklist

• This PR is small and focused
• I explained what changed and why
• Before/after evidence included

Fixes#6561

Written with Claude Opus 5 in Claude Code.

---

Note

Medium Risk
Changes preview navigation and spawns hardened native windows from third-party pages; security-sensitive but scoped to http/https scripted popups with explicit hardening and nested popup denial.

Overview
Fixes OAuth and other scripted window.open flows in the integrated browser preview by enabling popups at attach time and opening real windows when appropriate instead of navigating the preview tab.

HostedBrowserWebview sets allowpopups="true" on the <webview> element at render time (not in a ref callback), so Electron sees it before the guest attaches.

PreviewManager adds previewWindowOpenAction: scripted popups (new-window + http:/https:) are allowed as separate BrowserWindows with contextIsolation, sandbox, and no Node integration; target="_blank" and non-hardenable URLs (about:blank, file:, javascript:, etc.) still load in the preview tab. Child OAuth windows get a deny-all setWindowOpenHandler via did-create-window.

Unit tests cover the new helper’s popup vs navigate decisions.

^{Reviewed by Cursor Bugbot for commit 3f60be1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix OAuth popups in desktop browser preview with hardened window.open handling

• Adds previewWindowOpenAction in Manager.ts to classify window.open requests: http/https scripted popups return 'popup' and open as real BrowserWindows; target=_blank tabs and disallowed/invalid schemes (about, javascript, file, vscode) return 'navigate' and load in the existing preview tab.
• New popup windows use hardened webPreferences (contextIsolation: true, nodeIntegration: false, sandbox: true) and deny further window.open calls from within them.
• Fixes HostedBrowserWebview.tsx so the <webview> element reliably gets the allowpopups attribute at attach time.
• Behavioral Change: setWindowOpenHandler now receives full details and uses details.url instead of bare url; non-http(s) URLs that previously may have opened as popups now navigate the current tab instead.

^{Macroscope summarized 3f60be1.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: e56baf0c-bdec-4082-8fa9-d71789606066

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

One finding in the web scope: the new allowpopups JSX attribute is the right ownership fix, but its string value conflicts with React's element typing, so apps/web typecheck (tsgo --noEmit) breaks. Details inline.

^{Posted via Macroscope — UI Consistency}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 0604de5. Configure here.}

[cursor]

Popup may inherit picker preload

High Severity

POPUP_WINDOW_OPTIONS overrides isolation flags but never clears preload. Electron merges overrideBrowserWindowOptions with the guest's preferences, so the picker preload can still run in the OAuth window and observe keystrokes and clicks on a third-party login page.

Additional Locations (1)

• apps/desktop/src/preview/Manager.ts#L1769-L1771

^{Reviewed by Cursor Bugbot for commit 0604de5. Configure here.}

[walid-baharwal]

I could not reproduce this one, so I am leaving the code as is. Details, in case I tested the wrong thing.

A popup opened from a webview guest does not inherit the guest's preload, with or without overrideBrowserWindowOptions. I checked with a standalone Electron 41.5.0 app that mirrors the preview setup: a <webview allowpopups> with a preload and contextIsolation=false, whose preload announces itself over IPC on load, then window.open(...) from inside the guest.

The preload reports from the guest and never from the popup:

RESULT preload-ran in: http://127.0.0.1:8899/popup-repro.html
RESULT popup created:

Same result with the override removed, and same with data: and http: popup URLs, so the override is not what is clearing it — the inheritance does not happen in the first place.

One thing worth flagging for anyone reading this later: webContents.getLastWebPreferences() does not report preload at all. It omits the key even for the guest, which definitely has one, so it cannot be used to check this.

If you have a case where the preload does reach the popup, I would like to see it — the exposure you describe would be real, since that preload listens for keydown and pointerdown.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR changes production preview behavior by enabling OAuth popup windows and altering Electron renderer security boundaries across the desktop and webview layers. An unresolved security concern about the preview preload potentially reaching third-party OAuth pages still requires validation.

Notes:

• No code objects were reviewed. Approvability was decided on eligibility alone.

^{You can add or adjust custom eligibility rules. Learn more.}

[MatthewFeroz]

hoping this gets merged!

[MatthewFeroz]

I double-checked the preload concern in Electron 41.5.0 and tested it myself. The preview’s preload script ran only inside the preview, not inside the popup. Electron’s code also confirms that preload scripts are not copied into new windows. This matches the author’s test, so I don’t think the Cursor warning is a real issue.

[walid-baharwal]

Status summary, since the Approvability verdict above predates the current head and reads as the most visible signal on this PR.

That verdict was posted at 8fa05ae and gives one reason: the preview picker preload may still execute in the popup and observe input. Two independent checks say it does not.

I tested it with a standalone Electron 41.5.0 app mirroring the preview setup — a <webview allowpopups> with a preload and contextIsolation=false, the preload announcing itself over IPC. It reports from the guest and never from the popup, with and without overrideBrowserWindowOptions, for both data: and http: popup URLs. @MatthewFeroz reproduced this independently and additionally checked Electron's source, which does not copy preload scripts into new windows.

Worth flagging for anyone testing this themselves: webContents.getLastWebPreferences() omits preload entirely, even for a webContents that has one, so it cannot be used to check this.

The popup is also created with contextIsolation: true, sandbox: true, nodeIntegration: false — verified at runtime as typeof require === "undefined" inside it — and denies its own window.open, so it cannot spawn further windows.

Current head is 8db8d83. All checks green, including Macroscope UI Consistency after the typing fix. Locally: 66 tests in Manager.test.ts pass, tsgo --noEmit clean for apps/web and apps/desktop, lint and format clean on the changed files.

No action needed from me unless something new turns up.

[MatthewFeroz]

Just sent a video to the maintainers of this working. Small limitation in this is that passkeys don't function but I think that's out of scope for this PR. Great work!

[walid-baharwal]

Thanks for running it and recording the video — I could not produce one myself, so that fills the gap CONTRIBUTING asks for on interaction changes.

On passkeys: that is pre-existing and tracked separately in #5665 ("In app browser not triggering passkey fingerprint to sign in on mac", open since 2026-08-07), so it predates this branch. Nothing here touches WebAuthn — the change only decides whether window.open gets a real window and what preferences that window is created with. A passkey prompt failing inside the preview fails the same way on main today, with or without a popup involved.

So I agree it is out of scope, and I would rather not widen this PR to chase it.

[walid-baharwal]

What Changed

Two changes, both needed for an OAuth popup to work in the integrated browser preview.

apps/web/src/browser/HostedBrowserWebview.tsx sets allowpopups as an attribute on the <webview> element instead of from the ref callback. Electron reads that flag when the guest attaches, and the ref callback runs after the element is already in the DOM, so every preview guest attached with popups disabled.

apps/desktop/src/preview/Manager.ts reads the disposition the window-open handler already received. A new-window disposition with an http or https URL now opens a real window; everything else, target="_blank" links included, keeps loading in the preview tab as before. The popup is created with contextIsolation, sandbox, and nodeIntegration: false set explicitly, since a popup is not a webview attach and never passes the will-attach-webview hardening in DesktopWindow. It also gets a deny-only window-open handler of its own, so a page inside it cannot spawn native windows without limit. about:blank popups keep loading in the preview tab: Chromium copies the guest preferences for them and gives no way to override.

Why

A local app opened in the preview cannot finish an OAuth popup flow. Firebase signInWithPopup(auth, new GoogleAuthProvider()) reports auth/popup-blocked and no window appears, while the same app works in a normal Chrome or Firefox window.

Two separate causes stack up. window.open was denied and the URL was force-loaded into the same webContents, so window.open() returned null (the SDK reads that as a blocked popup) and the in-tab load destroyed the opener the popup needs to postMessage its credential back to. Underneath that, the guest attached with allowpopups false, so Electron blocked the call before the handler ran at all.

Instrumenting will-attach-webview in a running desktop build showed it directly:

[popup-debug attach-webview] {"partition":"persist:t3code-preview-…","allowpopups":false} before
[popup-debug attach-webview] {"partition":"persist:t3code-preview-…","allowpopups":true} after

Surfaces

Desktop only in behavior. The <webview> element lives in apps/web because the desktop app wraps the web client, but the tag only exists inside Electron and remote web previews never reach setWindowOpenHandler. No contract, provider, or docs change.

UI Changes

No layout, styling, or motion changed. The observable difference is whether a popup window exists, captured below in a dev build against a local page that calls window.open(url, name, "width=520,height=640"), the same shape signInWithPopup uses.

Before

window.open() returns null and no window opens.

After

window.open() returns a window handle.

The popup window itself, sized from the requested window features:

Verification

Run in a dev desktop build (dev:desktop) with the preview open on a local page:

• Scripted popup: window.open(...) returns a handle. Handler logged disposition: "new-window" and decided popup.
• The popup reports window.opener present and typeof require === "undefined", so the opener survives and the hardening applied.
• A nested window.open from inside the popup returns null.
• A target="_blank" link logs disposition: "foreground-tab", decides navigate, and loads in the preview tab.
• previewWindowOpenAction has focused unit tests next to isPreviewRefreshShortcut, the existing pure helper in the same file.

Checks run locally:

• vp test run apps/desktop/src/preview/Manager.test.ts — 66 passed
• tsgo --noEmit in apps/web and apps/desktop — clean
• vp lint and vp fmt --check on the changed files — clean

The attach-timing half is not unit-testable in a meaningful way. A rendered-DOM assertion passes either way, because the ref callback does set the attribute, just too late for Electron to read it.

Checklist

• This PR is small and focused
• I explained what changed and why
• Before/after evidence included

Fixes#6561

Written with Claude Opus 5 in Claude Code.

---

Note

Medium Risk
Changes preview navigation and spawns hardened native windows from third-party pages; security-sensitive but scoped to http/https scripted popups with explicit hardening and nested popup denial.

Overview
Fixes OAuth and other scripted window.open flows in the integrated browser preview by enabling popups at attach time and opening real windows when appropriate instead of navigating the preview tab.

HostedBrowserWebview sets allowpopups="true" on the <webview> element at render time (not in a ref callback), so Electron sees it before the guest attaches.

PreviewManager adds previewWindowOpenAction: scripted popups (new-window + http:/https:) are allowed as separate BrowserWindows with contextIsolation, sandbox, and no Node integration; target="_blank" and non-hardenable URLs (about:blank, file:, javascript:, etc.) still load in the preview tab. Child OAuth windows get a deny-all setWindowOpenHandler via did-create-window.

Unit tests cover the new helper’s popup vs navigate decisions.

^{Reviewed by Cursor Bugbot for commit 3f60be1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix OAuth popups in desktop browser preview with hardened window.open handling

• Adds previewWindowOpenAction in Manager.ts to classify window.open requests: http/https scripted popups return 'popup' and open as real BrowserWindows; target=_blank tabs and disallowed/invalid schemes (about, javascript, file, vscode) return 'navigate' and load in the existing preview tab.
• New popup windows use hardened webPreferences (contextIsolation: true, nodeIntegration: false, sandbox: true) and deny further window.open calls from within them.
• Fixes HostedBrowserWebview.tsx so the <webview> element reliably gets the allowpopups attribute at attach time.
• Behavioral Change: setWindowOpenHandler now receives full details and uses details.url instead of bare url; non-http(s) URLs that previously may have opened as popups now navigate the current tab instead.

^{Macroscope summarized 3f60be1.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: e56baf0c-bdec-4082-8fa9-d71789606066

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

One finding in the web scope: the new allowpopups JSX attribute is the right ownership fix, but its string value conflicts with React's element typing, so apps/web typecheck (tsgo --noEmit) breaks. Details inline.

^{Posted via Macroscope — UI Consistency}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 0604de5. Configure here.}

[cursor]

Popup may inherit picker preload

High Severity

POPUP_WINDOW_OPTIONS overrides isolation flags but never clears preload. Electron merges overrideBrowserWindowOptions with the guest's preferences, so the picker preload can still run in the OAuth window and observe keystrokes and clicks on a third-party login page.

Additional Locations (1)

• apps/desktop/src/preview/Manager.ts#L1769-L1771

^{Reviewed by Cursor Bugbot for commit 0604de5. Configure here.}

[walid-baharwal]

I could not reproduce this one, so I am leaving the code as is. Details, in case I tested the wrong thing.

A popup opened from a webview guest does not inherit the guest's preload, with or without overrideBrowserWindowOptions. I checked with a standalone Electron 41.5.0 app that mirrors the preview setup: a <webview allowpopups> with a preload and contextIsolation=false, whose preload announces itself over IPC on load, then window.open(...) from inside the guest.

The preload reports from the guest and never from the popup:

RESULT preload-ran in: http://127.0.0.1:8899/popup-repro.html
RESULT popup created:

Same result with the override removed, and same with data: and http: popup URLs, so the override is not what is clearing it — the inheritance does not happen in the first place.

One thing worth flagging for anyone reading this later: webContents.getLastWebPreferences() does not report preload at all. It omits the key even for the guest, which definitely has one, so it cannot be used to check this.

If you have a case where the preload does reach the popup, I would like to see it — the exposure you describe would be real, since that preload listens for keydown and pointerdown.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR changes production preview behavior by enabling OAuth popup windows and altering Electron renderer security boundaries across the desktop and webview layers. An unresolved security concern about the preview preload potentially reaching third-party OAuth pages still requires validation.

Notes:

• No code objects were reviewed. Approvability was decided on eligibility alone.

^{You can add or adjust custom eligibility rules. Learn more.}

[MatthewFeroz]

hoping this gets merged!

[MatthewFeroz]

I double-checked the preload concern in Electron 41.5.0 and tested it myself. The preview’s preload script ran only inside the preview, not inside the popup. Electron’s code also confirms that preload scripts are not copied into new windows. This matches the author’s test, so I don’t think the Cursor warning is a real issue.

[walid-baharwal]

Status summary, since the Approvability verdict above predates the current head and reads as the most visible signal on this PR.

That verdict was posted at 8fa05ae and gives one reason: the preview picker preload may still execute in the popup and observe input. Two independent checks say it does not.

I tested it with a standalone Electron 41.5.0 app mirroring the preview setup — a <webview allowpopups> with a preload and contextIsolation=false, the preload announcing itself over IPC. It reports from the guest and never from the popup, with and without overrideBrowserWindowOptions, for both data: and http: popup URLs. @MatthewFeroz reproduced this independently and additionally checked Electron's source, which does not copy preload scripts into new windows.

Worth flagging for anyone testing this themselves: webContents.getLastWebPreferences() omits preload entirely, even for a webContents that has one, so it cannot be used to check this.

The popup is also created with contextIsolation: true, sandbox: true, nodeIntegration: false — verified at runtime as typeof require === "undefined" inside it — and denies its own window.open, so it cannot spawn further windows.

Current head is 8db8d83. All checks green, including Macroscope UI Consistency after the typing fix. Locally: 66 tests in Manager.test.ts pass, tsgo --noEmit clean for apps/web and apps/desktop, lint and format clean on the changed files.

No action needed from me unless something new turns up.

[MatthewFeroz]

Just sent a video to the maintainers of this working. Small limitation in this is that passkeys don't function but I think that's out of scope for this PR. Great work!

[walid-baharwal]

Thanks for running it and recording the video — I could not produce one myself, so that fills the gap CONTRIBUTING asks for on interaction changes.

On passkeys: that is pre-existing and tracked separately in #5665 ("In app browser not triggering passkey fingerprint to sign in on mac", open since 2026-08-07), so it predates this branch. Nothing here touches WebAuthn — the change only decides whether window.open gets a real window and what preferences that window is created with. A passkey prompt failing inside the preview fails the same way on main today, with or without a popup involved.

So I agree it is out of scope, and I would rather not widen this PR to chase it.

[walid-baharwal]

What Changed

Two changes, both needed for an OAuth popup to work in the integrated browser preview.

apps/web/src/browser/HostedBrowserWebview.tsx sets allowpopups as an attribute on the <webview> element instead of from the ref callback. Electron reads that flag when the guest attaches, and the ref callback runs after the element is already in the DOM, so every preview guest attached with popups disabled.

apps/desktop/src/preview/Manager.ts reads the disposition the window-open handler already received. A new-window disposition with an http or https URL now opens a real window; everything else, target="_blank" links included, keeps loading in the preview tab as before. The popup is created with contextIsolation, sandbox, and nodeIntegration: false set explicitly, since a popup is not a webview attach and never passes the will-attach-webview hardening in DesktopWindow. It also gets a deny-only window-open handler of its own, so a page inside it cannot spawn native windows without limit. about:blank popups keep loading in the preview tab: Chromium copies the guest preferences for them and gives no way to override.

Why

A local app opened in the preview cannot finish an OAuth popup flow. Firebase signInWithPopup(auth, new GoogleAuthProvider()) reports auth/popup-blocked and no window appears, while the same app works in a normal Chrome or Firefox window.

Two separate causes stack up. window.open was denied and the URL was force-loaded into the same webContents, so window.open() returned null (the SDK reads that as a blocked popup) and the in-tab load destroyed the opener the popup needs to postMessage its credential back to. Underneath that, the guest attached with allowpopups false, so Electron blocked the call before the handler ran at all.

Instrumenting will-attach-webview in a running desktop build showed it directly:

[popup-debug attach-webview] {"partition":"persist:t3code-preview-…","allowpopups":false} before
[popup-debug attach-webview] {"partition":"persist:t3code-preview-…","allowpopups":true} after

Surfaces

Desktop only in behavior. The <webview> element lives in apps/web because the desktop app wraps the web client, but the tag only exists inside Electron and remote web previews never reach setWindowOpenHandler. No contract, provider, or docs change.

UI Changes

No layout, styling, or motion changed. The observable difference is whether a popup window exists, captured below in a dev build against a local page that calls window.open(url, name, "width=520,height=640"), the same shape signInWithPopup uses.

Before

window.open() returns null and no window opens.

After

window.open() returns a window handle.

The popup window itself, sized from the requested window features:

Verification

Run in a dev desktop build (dev:desktop) with the preview open on a local page:

• Scripted popup: window.open(...) returns a handle. Handler logged disposition: "new-window" and decided popup.
• The popup reports window.opener present and typeof require === "undefined", so the opener survives and the hardening applied.
• A nested window.open from inside the popup returns null.
• A target="_blank" link logs disposition: "foreground-tab", decides navigate, and loads in the preview tab.
• previewWindowOpenAction has focused unit tests next to isPreviewRefreshShortcut, the existing pure helper in the same file.

Checks run locally:

• vp test run apps/desktop/src/preview/Manager.test.ts — 66 passed
• tsgo --noEmit in apps/web and apps/desktop — clean
• vp lint and vp fmt --check on the changed files — clean

The attach-timing half is not unit-testable in a meaningful way. A rendered-DOM assertion passes either way, because the ref callback does set the attribute, just too late for Electron to read it.

Checklist

• This PR is small and focused
• I explained what changed and why
• Before/after evidence included

Fixes#6561

Written with Claude Opus 5 in Claude Code.

---

Note

Medium Risk
Changes preview navigation and spawns hardened native windows from third-party pages; security-sensitive but scoped to http/https scripted popups with explicit hardening and nested popup denial.

Overview
Fixes OAuth and other scripted window.open flows in the integrated browser preview by enabling popups at attach time and opening real windows when appropriate instead of navigating the preview tab.

HostedBrowserWebview sets allowpopups="true" on the <webview> element at render time (not in a ref callback), so Electron sees it before the guest attaches.

PreviewManager adds previewWindowOpenAction: scripted popups (new-window + http:/https:) are allowed as separate BrowserWindows with contextIsolation, sandbox, and no Node integration; target="_blank" and non-hardenable URLs (about:blank, file:, javascript:, etc.) still load in the preview tab. Child OAuth windows get a deny-all setWindowOpenHandler via did-create-window.

Unit tests cover the new helper’s popup vs navigate decisions.

^{Reviewed by Cursor Bugbot for commit 3f60be1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix OAuth popups in desktop browser preview with hardened window.open handling

• Adds previewWindowOpenAction in Manager.ts to classify window.open requests: http/https scripted popups return 'popup' and open as real BrowserWindows; target=_blank tabs and disallowed/invalid schemes (about, javascript, file, vscode) return 'navigate' and load in the existing preview tab.
• New popup windows use hardened webPreferences (contextIsolation: true, nodeIntegration: false, sandbox: true) and deny further window.open calls from within them.
• Fixes HostedBrowserWebview.tsx so the <webview> element reliably gets the allowpopups attribute at attach time.
• Behavioral Change: setWindowOpenHandler now receives full details and uses details.url instead of bare url; non-http(s) URLs that previously may have opened as popups now navigate the current tab instead.

^{Macroscope summarized 3f60be1.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: e56baf0c-bdec-4082-8fa9-d71789606066

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

One finding in the web scope: the new allowpopups JSX attribute is the right ownership fix, but its string value conflicts with React's element typing, so apps/web typecheck (tsgo --noEmit) breaks. Details inline.

^{Posted via Macroscope — UI Consistency}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 0604de5. Configure here.}

[cursor]

Popup may inherit picker preload

High Severity

POPUP_WINDOW_OPTIONS overrides isolation flags but never clears preload. Electron merges overrideBrowserWindowOptions with the guest's preferences, so the picker preload can still run in the OAuth window and observe keystrokes and clicks on a third-party login page.

Additional Locations (1)

• apps/desktop/src/preview/Manager.ts#L1769-L1771

^{Reviewed by Cursor Bugbot for commit 0604de5. Configure here.}

[walid-baharwal]

I could not reproduce this one, so I am leaving the code as is. Details, in case I tested the wrong thing.

A popup opened from a webview guest does not inherit the guest's preload, with or without overrideBrowserWindowOptions. I checked with a standalone Electron 41.5.0 app that mirrors the preview setup: a <webview allowpopups> with a preload and contextIsolation=false, whose preload announces itself over IPC on load, then window.open(...) from inside the guest.

The preload reports from the guest and never from the popup:

RESULT preload-ran in: http://127.0.0.1:8899/popup-repro.html
RESULT popup created:

Same result with the override removed, and same with data: and http: popup URLs, so the override is not what is clearing it — the inheritance does not happen in the first place.

One thing worth flagging for anyone reading this later: webContents.getLastWebPreferences() does not report preload at all. It omits the key even for the guest, which definitely has one, so it cannot be used to check this.

If you have a case where the preload does reach the popup, I would like to see it — the exposure you describe would be real, since that preload listens for keydown and pointerdown.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR changes production preview behavior by enabling OAuth popup windows and altering Electron renderer security boundaries across the desktop and webview layers. An unresolved security concern about the preview preload potentially reaching third-party OAuth pages still requires validation.

Notes:

• No code objects were reviewed. Approvability was decided on eligibility alone.

^{You can add or adjust custom eligibility rules. Learn more.}

[MatthewFeroz]

hoping this gets merged!

[MatthewFeroz]

I double-checked the preload concern in Electron 41.5.0 and tested it myself. The preview’s preload script ran only inside the preview, not inside the popup. Electron’s code also confirms that preload scripts are not copied into new windows. This matches the author’s test, so I don’t think the Cursor warning is a real issue.

[walid-baharwal]

Status summary, since the Approvability verdict above predates the current head and reads as the most visible signal on this PR.

That verdict was posted at 8fa05ae and gives one reason: the preview picker preload may still execute in the popup and observe input. Two independent checks say it does not.

I tested it with a standalone Electron 41.5.0 app mirroring the preview setup — a <webview allowpopups> with a preload and contextIsolation=false, the preload announcing itself over IPC. It reports from the guest and never from the popup, with and without overrideBrowserWindowOptions, for both data: and http: popup URLs. @MatthewFeroz reproduced this independently and additionally checked Electron's source, which does not copy preload scripts into new windows.

Worth flagging for anyone testing this themselves: webContents.getLastWebPreferences() omits preload entirely, even for a webContents that has one, so it cannot be used to check this.

The popup is also created with contextIsolation: true, sandbox: true, nodeIntegration: false — verified at runtime as typeof require === "undefined" inside it — and denies its own window.open, so it cannot spawn further windows.

Current head is 8db8d83. All checks green, including Macroscope UI Consistency after the typing fix. Locally: 66 tests in Manager.test.ts pass, tsgo --noEmit clean for apps/web and apps/desktop, lint and format clean on the changed files.

No action needed from me unless something new turns up.

[MatthewFeroz]

Just sent a video to the maintainers of this working. Small limitation in this is that passkeys don't function but I think that's out of scope for this PR. Great work!

[walid-baharwal]

Thanks for running it and recording the video — I could not produce one myself, so that fills the gap CONTRIBUTING asks for on interaction changes.

On passkeys: that is pre-existing and tracked separately in #5665 ("In app browser not triggering passkey fingerprint to sign in on mac", open since 2026-08-07), so it predates this branch. Nothing here touches WebAuthn — the change only decides whether window.open gets a real window and what preferences that window is created with. A passkey prompt failing inside the preview fails the same way on main today, with or without a popup involved.

So I agree it is out of scope, and I would rather not widen this PR to chase it.

[walid-baharwal]

What Changed

Two changes, both needed for an OAuth popup to work in the integrated browser preview.

apps/web/src/browser/HostedBrowserWebview.tsx sets allowpopups as an attribute on the <webview> element instead of from the ref callback. Electron reads that flag when the guest attaches, and the ref callback runs after the element is already in the DOM, so every preview guest attached with popups disabled.

apps/desktop/src/preview/Manager.ts reads the disposition the window-open handler already received. A new-window disposition with an http or https URL now opens a real window; everything else, target="_blank" links included, keeps loading in the preview tab as before. The popup is created with contextIsolation, sandbox, and nodeIntegration: false set explicitly, since a popup is not a webview attach and never passes the will-attach-webview hardening in DesktopWindow. It also gets a deny-only window-open handler of its own, so a page inside it cannot spawn native windows without limit. about:blank popups keep loading in the preview tab: Chromium copies the guest preferences for them and gives no way to override.

Why

A local app opened in the preview cannot finish an OAuth popup flow. Firebase signInWithPopup(auth, new GoogleAuthProvider()) reports auth/popup-blocked and no window appears, while the same app works in a normal Chrome or Firefox window.

Two separate causes stack up. window.open was denied and the URL was force-loaded into the same webContents, so window.open() returned null (the SDK reads that as a blocked popup) and the in-tab load destroyed the opener the popup needs to postMessage its credential back to. Underneath that, the guest attached with allowpopups false, so Electron blocked the call before the handler ran at all.

Instrumenting will-attach-webview in a running desktop build showed it directly:

[popup-debug attach-webview] {"partition":"persist:t3code-preview-…","allowpopups":false} before
[popup-debug attach-webview] {"partition":"persist:t3code-preview-…","allowpopups":true} after

Surfaces

Desktop only in behavior. The <webview> element lives in apps/web because the desktop app wraps the web client, but the tag only exists inside Electron and remote web previews never reach setWindowOpenHandler. No contract, provider, or docs change.

UI Changes

No layout, styling, or motion changed. The observable difference is whether a popup window exists, captured below in a dev build against a local page that calls window.open(url, name, "width=520,height=640"), the same shape signInWithPopup uses.

Before

window.open() returns null and no window opens.

After

window.open() returns a window handle.

The popup window itself, sized from the requested window features:

Verification

Run in a dev desktop build (dev:desktop) with the preview open on a local page:

• Scripted popup: window.open(...) returns a handle. Handler logged disposition: "new-window" and decided popup.
• The popup reports window.opener present and typeof require === "undefined", so the opener survives and the hardening applied.
• A nested window.open from inside the popup returns null.
• A target="_blank" link logs disposition: "foreground-tab", decides navigate, and loads in the preview tab.
• previewWindowOpenAction has focused unit tests next to isPreviewRefreshShortcut, the existing pure helper in the same file.

Checks run locally:

• vp test run apps/desktop/src/preview/Manager.test.ts — 66 passed
• tsgo --noEmit in apps/web and apps/desktop — clean
• vp lint and vp fmt --check on the changed files — clean

The attach-timing half is not unit-testable in a meaningful way. A rendered-DOM assertion passes either way, because the ref callback does set the attribute, just too late for Electron to read it.

Checklist

• This PR is small and focused
• I explained what changed and why
• Before/after evidence included

Fixes#6561

Written with Claude Opus 5 in Claude Code.

---

Note

Medium Risk
Changes preview navigation and spawns hardened native windows from third-party pages; security-sensitive but scoped to http/https scripted popups with explicit hardening and nested popup denial.

Overview
Fixes OAuth and other scripted window.open flows in the integrated browser preview by enabling popups at attach time and opening real windows when appropriate instead of navigating the preview tab.

HostedBrowserWebview sets allowpopups="true" on the <webview> element at render time (not in a ref callback), so Electron sees it before the guest attaches.

PreviewManager adds previewWindowOpenAction: scripted popups (new-window + http:/https:) are allowed as separate BrowserWindows with contextIsolation, sandbox, and no Node integration; target="_blank" and non-hardenable URLs (about:blank, file:, javascript:, etc.) still load in the preview tab. Child OAuth windows get a deny-all setWindowOpenHandler via did-create-window.

Unit tests cover the new helper’s popup vs navigate decisions.

^{Reviewed by Cursor Bugbot for commit 3f60be1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix OAuth popups in desktop browser preview with hardened window.open handling

• Adds previewWindowOpenAction in Manager.ts to classify window.open requests: http/https scripted popups return 'popup' and open as real BrowserWindows; target=_blank tabs and disallowed/invalid schemes (about, javascript, file, vscode) return 'navigate' and load in the existing preview tab.
• New popup windows use hardened webPreferences (contextIsolation: true, nodeIntegration: false, sandbox: true) and deny further window.open calls from within them.
• Fixes HostedBrowserWebview.tsx so the <webview> element reliably gets the allowpopups attribute at attach time.
• Behavioral Change: setWindowOpenHandler now receives full details and uses details.url instead of bare url; non-http(s) URLs that previously may have opened as popups now navigate the current tab instead.

^{Macroscope summarized 3f60be1.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: e56baf0c-bdec-4082-8fa9-d71789606066

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

One finding in the web scope: the new allowpopups JSX attribute is the right ownership fix, but its string value conflicts with React's element typing, so apps/web typecheck (tsgo --noEmit) breaks. Details inline.

^{Posted via Macroscope — UI Consistency}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 0604de5. Configure here.}

[cursor]

Popup may inherit picker preload

High Severity

POPUP_WINDOW_OPTIONS overrides isolation flags but never clears preload. Electron merges overrideBrowserWindowOptions with the guest's preferences, so the picker preload can still run in the OAuth window and observe keystrokes and clicks on a third-party login page.

Additional Locations (1)

• apps/desktop/src/preview/Manager.ts#L1769-L1771

^{Reviewed by Cursor Bugbot for commit 0604de5. Configure here.}

[walid-baharwal]

I could not reproduce this one, so I am leaving the code as is. Details, in case I tested the wrong thing.

A popup opened from a webview guest does not inherit the guest's preload, with or without overrideBrowserWindowOptions. I checked with a standalone Electron 41.5.0 app that mirrors the preview setup: a <webview allowpopups> with a preload and contextIsolation=false, whose preload announces itself over IPC on load, then window.open(...) from inside the guest.

The preload reports from the guest and never from the popup:

RESULT preload-ran in: http://127.0.0.1:8899/popup-repro.html
RESULT popup created:

Same result with the override removed, and same with data: and http: popup URLs, so the override is not what is clearing it — the inheritance does not happen in the first place.

One thing worth flagging for anyone reading this later: webContents.getLastWebPreferences() does not report preload at all. It omits the key even for the guest, which definitely has one, so it cannot be used to check this.

If you have a case where the preload does reach the popup, I would like to see it — the exposure you describe would be real, since that preload listens for keydown and pointerdown.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR changes production preview behavior by enabling OAuth popup windows and altering Electron renderer security boundaries across the desktop and webview layers. An unresolved security concern about the preview preload potentially reaching third-party OAuth pages still requires validation.

Notes:

• No code objects were reviewed. Approvability was decided on eligibility alone.

^{You can add or adjust custom eligibility rules. Learn more.}

[MatthewFeroz]

hoping this gets merged!

[MatthewFeroz]

I double-checked the preload concern in Electron 41.5.0 and tested it myself. The preview’s preload script ran only inside the preview, not inside the popup. Electron’s code also confirms that preload scripts are not copied into new windows. This matches the author’s test, so I don’t think the Cursor warning is a real issue.

[walid-baharwal]

Status summary, since the Approvability verdict above predates the current head and reads as the most visible signal on this PR.

That verdict was posted at 8fa05ae and gives one reason: the preview picker preload may still execute in the popup and observe input. Two independent checks say it does not.

I tested it with a standalone Electron 41.5.0 app mirroring the preview setup — a <webview allowpopups> with a preload and contextIsolation=false, the preload announcing itself over IPC. It reports from the guest and never from the popup, with and without overrideBrowserWindowOptions, for both data: and http: popup URLs. @MatthewFeroz reproduced this independently and additionally checked Electron's source, which does not copy preload scripts into new windows.

Worth flagging for anyone testing this themselves: webContents.getLastWebPreferences() omits preload entirely, even for a webContents that has one, so it cannot be used to check this.

The popup is also created with contextIsolation: true, sandbox: true, nodeIntegration: false — verified at runtime as typeof require === "undefined" inside it — and denies its own window.open, so it cannot spawn further windows.

Current head is 8db8d83. All checks green, including Macroscope UI Consistency after the typing fix. Locally: 66 tests in Manager.test.ts pass, tsgo --noEmit clean for apps/web and apps/desktop, lint and format clean on the changed files.

No action needed from me unless something new turns up.

[MatthewFeroz]

Just sent a video to the maintainers of this working. Small limitation in this is that passkeys don't function but I think that's out of scope for this PR. Great work!

[walid-baharwal]

Thanks for running it and recording the video — I could not produce one myself, so that fills the gap CONTRIBUTING asks for on interaction changes.

On passkeys: that is pre-existing and tracked separately in #5665 ("In app browser not triggering passkey fingerprint to sign in on mac", open since 2026-08-07), so it predates this branch. Nothing here touches WebAuthn — the change only decides whether window.open gets a real window and what preferences that window is created with. A passkey prompt failing inside the preview fails the same way on main today, with or without a popup involved.

So I agree it is out of scope, and I would rather not widen this PR to chase it.

[walid-baharwal]

What Changed

Two changes, both needed for an OAuth popup to work in the integrated browser preview.

apps/web/src/browser/HostedBrowserWebview.tsx sets allowpopups as an attribute on the <webview> element instead of from the ref callback. Electron reads that flag when the guest attaches, and the ref callback runs after the element is already in the DOM, so every preview guest attached with popups disabled.

apps/desktop/src/preview/Manager.ts reads the disposition the window-open handler already received. A new-window disposition with an http or https URL now opens a real window; everything else, target="_blank" links included, keeps loading in the preview tab as before. The popup is created with contextIsolation, sandbox, and nodeIntegration: false set explicitly, since a popup is not a webview attach and never passes the will-attach-webview hardening in DesktopWindow. It also gets a deny-only window-open handler of its own, so a page inside it cannot spawn native windows without limit. about:blank popups keep loading in the preview tab: Chromium copies the guest preferences for them and gives no way to override.

Why

A local app opened in the preview cannot finish an OAuth popup flow. Firebase signInWithPopup(auth, new GoogleAuthProvider()) reports auth/popup-blocked and no window appears, while the same app works in a normal Chrome or Firefox window.

Two separate causes stack up. window.open was denied and the URL was force-loaded into the same webContents, so window.open() returned null (the SDK reads that as a blocked popup) and the in-tab load destroyed the opener the popup needs to postMessage its credential back to. Underneath that, the guest attached with allowpopups false, so Electron blocked the call before the handler ran at all.

Instrumenting will-attach-webview in a running desktop build showed it directly:

[popup-debug attach-webview] {"partition":"persist:t3code-preview-…","allowpopups":false} before
[popup-debug attach-webview] {"partition":"persist:t3code-preview-…","allowpopups":true} after

Surfaces

Desktop only in behavior. The <webview> element lives in apps/web because the desktop app wraps the web client, but the tag only exists inside Electron and remote web previews never reach setWindowOpenHandler. No contract, provider, or docs change.

UI Changes

No layout, styling, or motion changed. The observable difference is whether a popup window exists, captured below in a dev build against a local page that calls window.open(url, name, "width=520,height=640"), the same shape signInWithPopup uses.

Before

window.open() returns null and no window opens.

After

window.open() returns a window handle.

The popup window itself, sized from the requested window features:

Verification

Run in a dev desktop build (dev:desktop) with the preview open on a local page:

• Scripted popup: window.open(...) returns a handle. Handler logged disposition: "new-window" and decided popup.
• The popup reports window.opener present and typeof require === "undefined", so the opener survives and the hardening applied.
• A nested window.open from inside the popup returns null.
• A target="_blank" link logs disposition: "foreground-tab", decides navigate, and loads in the preview tab.
• previewWindowOpenAction has focused unit tests next to isPreviewRefreshShortcut, the existing pure helper in the same file.

Checks run locally:

• vp test run apps/desktop/src/preview/Manager.test.ts — 66 passed
• tsgo --noEmit in apps/web and apps/desktop — clean
• vp lint and vp fmt --check on the changed files — clean

The attach-timing half is not unit-testable in a meaningful way. A rendered-DOM assertion passes either way, because the ref callback does set the attribute, just too late for Electron to read it.

Checklist

• This PR is small and focused
• I explained what changed and why
• Before/after evidence included

Fixes#6561

Written with Claude Opus 5 in Claude Code.

---

Note

Medium Risk
Changes preview navigation and spawns hardened native windows from third-party pages; security-sensitive but scoped to http/https scripted popups with explicit hardening and nested popup denial.

Overview
Fixes OAuth and other scripted window.open flows in the integrated browser preview by enabling popups at attach time and opening real windows when appropriate instead of navigating the preview tab.

HostedBrowserWebview sets allowpopups="true" on the <webview> element at render time (not in a ref callback), so Electron sees it before the guest attaches.

PreviewManager adds previewWindowOpenAction: scripted popups (new-window + http:/https:) are allowed as separate BrowserWindows with contextIsolation, sandbox, and no Node integration; target="_blank" and non-hardenable URLs (about:blank, file:, javascript:, etc.) still load in the preview tab. Child OAuth windows get a deny-all setWindowOpenHandler via did-create-window.

Unit tests cover the new helper’s popup vs navigate decisions.

^{Reviewed by Cursor Bugbot for commit 3f60be1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix OAuth popups in desktop browser preview with hardened window.open handling

• Adds previewWindowOpenAction in Manager.ts to classify window.open requests: http/https scripted popups return 'popup' and open as real BrowserWindows; target=_blank tabs and disallowed/invalid schemes (about, javascript, file, vscode) return 'navigate' and load in the existing preview tab.
• New popup windows use hardened webPreferences (contextIsolation: true, nodeIntegration: false, sandbox: true) and deny further window.open calls from within them.
• Fixes HostedBrowserWebview.tsx so the <webview> element reliably gets the allowpopups attribute at attach time.
• Behavioral Change: setWindowOpenHandler now receives full details and uses details.url instead of bare url; non-http(s) URLs that previously may have opened as popups now navigate the current tab instead.

^{Macroscope summarized 3f60be1.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: e56baf0c-bdec-4082-8fa9-d71789606066

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

One finding in the web scope: the new allowpopups JSX attribute is the right ownership fix, but its string value conflicts with React's element typing, so apps/web typecheck (tsgo --noEmit) breaks. Details inline.

^{Posted via Macroscope — UI Consistency}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 0604de5. Configure here.}

[cursor]

Popup may inherit picker preload

High Severity

POPUP_WINDOW_OPTIONS overrides isolation flags but never clears preload. Electron merges overrideBrowserWindowOptions with the guest's preferences, so the picker preload can still run in the OAuth window and observe keystrokes and clicks on a third-party login page.

Additional Locations (1)

• apps/desktop/src/preview/Manager.ts#L1769-L1771

^{Reviewed by Cursor Bugbot for commit 0604de5. Configure here.}

[walid-baharwal]

I could not reproduce this one, so I am leaving the code as is. Details, in case I tested the wrong thing.

A popup opened from a webview guest does not inherit the guest's preload, with or without overrideBrowserWindowOptions. I checked with a standalone Electron 41.5.0 app that mirrors the preview setup: a <webview allowpopups> with a preload and contextIsolation=false, whose preload announces itself over IPC on load, then window.open(...) from inside the guest.

The preload reports from the guest and never from the popup:

RESULT preload-ran in: http://127.0.0.1:8899/popup-repro.html
RESULT popup created:

Same result with the override removed, and same with data: and http: popup URLs, so the override is not what is clearing it — the inheritance does not happen in the first place.

One thing worth flagging for anyone reading this later: webContents.getLastWebPreferences() does not report preload at all. It omits the key even for the guest, which definitely has one, so it cannot be used to check this.

If you have a case where the preload does reach the popup, I would like to see it — the exposure you describe would be real, since that preload listens for keydown and pointerdown.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR changes production preview behavior by enabling OAuth popup windows and altering Electron renderer security boundaries across the desktop and webview layers. An unresolved security concern about the preview preload potentially reaching third-party OAuth pages still requires validation.

Notes:

• No code objects were reviewed. Approvability was decided on eligibility alone.

^{You can add or adjust custom eligibility rules. Learn more.}

[MatthewFeroz]

hoping this gets merged!

[MatthewFeroz]

I double-checked the preload concern in Electron 41.5.0 and tested it myself. The preview’s preload script ran only inside the preview, not inside the popup. Electron’s code also confirms that preload scripts are not copied into new windows. This matches the author’s test, so I don’t think the Cursor warning is a real issue.

[walid-baharwal]

Status summary, since the Approvability verdict above predates the current head and reads as the most visible signal on this PR.

That verdict was posted at 8fa05ae and gives one reason: the preview picker preload may still execute in the popup and observe input. Two independent checks say it does not.

I tested it with a standalone Electron 41.5.0 app mirroring the preview setup — a <webview allowpopups> with a preload and contextIsolation=false, the preload announcing itself over IPC. It reports from the guest and never from the popup, with and without overrideBrowserWindowOptions, for both data: and http: popup URLs. @MatthewFeroz reproduced this independently and additionally checked Electron's source, which does not copy preload scripts into new windows.

Worth flagging for anyone testing this themselves: webContents.getLastWebPreferences() omits preload entirely, even for a webContents that has one, so it cannot be used to check this.

The popup is also created with contextIsolation: true, sandbox: true, nodeIntegration: false — verified at runtime as typeof require === "undefined" inside it — and denies its own window.open, so it cannot spawn further windows.

Current head is 8db8d83. All checks green, including Macroscope UI Consistency after the typing fix. Locally: 66 tests in Manager.test.ts pass, tsgo --noEmit clean for apps/web and apps/desktop, lint and format clean on the changed files.

No action needed from me unless something new turns up.

[MatthewFeroz]

Just sent a video to the maintainers of this working. Small limitation in this is that passkeys don't function but I think that's out of scope for this PR. Great work!

[walid-baharwal]

Thanks for running it and recording the video — I could not produce one myself, so that fills the gap CONTRIBUTING asks for on interaction changes.

On passkeys: that is pre-existing and tracked separately in #5665 ("In app browser not triggering passkey fingerprint to sign in on mac", open since 2026-08-07), so it predates this branch. Nothing here touches WebAuthn — the change only decides whether window.open gets a real window and what preferences that window is created with. A passkey prompt failing inside the preview fails the same way on main today, with or without a popup involved.

So I agree it is out of scope, and I would rather not widen this PR to chase it.

[walid-baharwal]

What Changed

Two changes, both needed for an OAuth popup to work in the integrated browser preview.

apps/web/src/browser/HostedBrowserWebview.tsx sets allowpopups as an attribute on the <webview> element instead of from the ref callback. Electron reads that flag when the guest attaches, and the ref callback runs after the element is already in the DOM, so every preview guest attached with popups disabled.

apps/desktop/src/preview/Manager.ts reads the disposition the window-open handler already received. A new-window disposition with an http or https URL now opens a real window; everything else, target="_blank" links included, keeps loading in the preview tab as before. The popup is created with contextIsolation, sandbox, and nodeIntegration: false set explicitly, since a popup is not a webview attach and never passes the will-attach-webview hardening in DesktopWindow. It also gets a deny-only window-open handler of its own, so a page inside it cannot spawn native windows without limit. about:blank popups keep loading in the preview tab: Chromium copies the guest preferences for them and gives no way to override.

Why

A local app opened in the preview cannot finish an OAuth popup flow. Firebase signInWithPopup(auth, new GoogleAuthProvider()) reports auth/popup-blocked and no window appears, while the same app works in a normal Chrome or Firefox window.

Two separate causes stack up. window.open was denied and the URL was force-loaded into the same webContents, so window.open() returned null (the SDK reads that as a blocked popup) and the in-tab load destroyed the opener the popup needs to postMessage its credential back to. Underneath that, the guest attached with allowpopups false, so Electron blocked the call before the handler ran at all.

Instrumenting will-attach-webview in a running desktop build showed it directly:

[popup-debug attach-webview] {"partition":"persist:t3code-preview-…","allowpopups":false} before
[popup-debug attach-webview] {"partition":"persist:t3code-preview-…","allowpopups":true} after

Surfaces

Desktop only in behavior. The <webview> element lives in apps/web because the desktop app wraps the web client, but the tag only exists inside Electron and remote web previews never reach setWindowOpenHandler. No contract, provider, or docs change.

UI Changes

No layout, styling, or motion changed. The observable difference is whether a popup window exists, captured below in a dev build against a local page that calls window.open(url, name, "width=520,height=640"), the same shape signInWithPopup uses.

Before

window.open() returns null and no window opens.

After

window.open() returns a window handle.

The popup window itself, sized from the requested window features:

Verification

Run in a dev desktop build (dev:desktop) with the preview open on a local page:

• Scripted popup: window.open(...) returns a handle. Handler logged disposition: "new-window" and decided popup.
• The popup reports window.opener present and typeof require === "undefined", so the opener survives and the hardening applied.
• A nested window.open from inside the popup returns null.
• A target="_blank" link logs disposition: "foreground-tab", decides navigate, and loads in the preview tab.
• previewWindowOpenAction has focused unit tests next to isPreviewRefreshShortcut, the existing pure helper in the same file.

Checks run locally:

• vp test run apps/desktop/src/preview/Manager.test.ts — 66 passed
• tsgo --noEmit in apps/web and apps/desktop — clean
• vp lint and vp fmt --check on the changed files — clean

The attach-timing half is not unit-testable in a meaningful way. A rendered-DOM assertion passes either way, because the ref callback does set the attribute, just too late for Electron to read it.

Checklist

• This PR is small and focused
• I explained what changed and why
• Before/after evidence included

Fixes#6561

Written with Claude Opus 5 in Claude Code.

---

Note

Medium Risk
Changes preview navigation and spawns hardened native windows from third-party pages; security-sensitive but scoped to http/https scripted popups with explicit hardening and nested popup denial.

Overview
Fixes OAuth and other scripted window.open flows in the integrated browser preview by enabling popups at attach time and opening real windows when appropriate instead of navigating the preview tab.

HostedBrowserWebview sets allowpopups="true" on the <webview> element at render time (not in a ref callback), so Electron sees it before the guest attaches.

PreviewManager adds previewWindowOpenAction: scripted popups (new-window + http:/https:) are allowed as separate BrowserWindows with contextIsolation, sandbox, and no Node integration; target="_blank" and non-hardenable URLs (about:blank, file:, javascript:, etc.) still load in the preview tab. Child OAuth windows get a deny-all setWindowOpenHandler via did-create-window.

Unit tests cover the new helper’s popup vs navigate decisions.

^{Reviewed by Cursor Bugbot for commit 3f60be1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix OAuth popups in desktop browser preview with hardened window.open handling

• Adds previewWindowOpenAction in Manager.ts to classify window.open requests: http/https scripted popups return 'popup' and open as real BrowserWindows; target=_blank tabs and disallowed/invalid schemes (about, javascript, file, vscode) return 'navigate' and load in the existing preview tab.
• New popup windows use hardened webPreferences (contextIsolation: true, nodeIntegration: false, sandbox: true) and deny further window.open calls from within them.
• Fixes HostedBrowserWebview.tsx so the <webview> element reliably gets the allowpopups attribute at attach time.
• Behavioral Change: setWindowOpenHandler now receives full details and uses details.url instead of bare url; non-http(s) URLs that previously may have opened as popups now navigate the current tab instead.

^{Macroscope summarized 3f60be1.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: e56baf0c-bdec-4082-8fa9-d71789606066

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

One finding in the web scope: the new allowpopups JSX attribute is the right ownership fix, but its string value conflicts with React's element typing, so apps/web typecheck (tsgo --noEmit) breaks. Details inline.

^{Posted via Macroscope — UI Consistency}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 0604de5. Configure here.}

[cursor]

Popup may inherit picker preload

High Severity

POPUP_WINDOW_OPTIONS overrides isolation flags but never clears preload. Electron merges overrideBrowserWindowOptions with the guest's preferences, so the picker preload can still run in the OAuth window and observe keystrokes and clicks on a third-party login page.

Additional Locations (1)

• apps/desktop/src/preview/Manager.ts#L1769-L1771

^{Reviewed by Cursor Bugbot for commit 0604de5. Configure here.}

[walid-baharwal]

I could not reproduce this one, so I am leaving the code as is. Details, in case I tested the wrong thing.

A popup opened from a webview guest does not inherit the guest's preload, with or without overrideBrowserWindowOptions. I checked with a standalone Electron 41.5.0 app that mirrors the preview setup: a <webview allowpopups> with a preload and contextIsolation=false, whose preload announces itself over IPC on load, then window.open(...) from inside the guest.

The preload reports from the guest and never from the popup:

RESULT preload-ran in: http://127.0.0.1:8899/popup-repro.html
RESULT popup created:

Same result with the override removed, and same with data: and http: popup URLs, so the override is not what is clearing it — the inheritance does not happen in the first place.

One thing worth flagging for anyone reading this later: webContents.getLastWebPreferences() does not report preload at all. It omits the key even for the guest, which definitely has one, so it cannot be used to check this.

If you have a case where the preload does reach the popup, I would like to see it — the exposure you describe would be real, since that preload listens for keydown and pointerdown.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR changes production preview behavior by enabling OAuth popup windows and altering Electron renderer security boundaries across the desktop and webview layers. An unresolved security concern about the preview preload potentially reaching third-party OAuth pages still requires validation.

Notes:

• No code objects were reviewed. Approvability was decided on eligibility alone.

^{You can add or adjust custom eligibility rules. Learn more.}

[MatthewFeroz]

hoping this gets merged!

[MatthewFeroz]

I double-checked the preload concern in Electron 41.5.0 and tested it myself. The preview’s preload script ran only inside the preview, not inside the popup. Electron’s code also confirms that preload scripts are not copied into new windows. This matches the author’s test, so I don’t think the Cursor warning is a real issue.

[walid-baharwal]

Status summary, since the Approvability verdict above predates the current head and reads as the most visible signal on this PR.

That verdict was posted at 8fa05ae and gives one reason: the preview picker preload may still execute in the popup and observe input. Two independent checks say it does not.

I tested it with a standalone Electron 41.5.0 app mirroring the preview setup — a <webview allowpopups> with a preload and contextIsolation=false, the preload announcing itself over IPC. It reports from the guest and never from the popup, with and without overrideBrowserWindowOptions, for both data: and http: popup URLs. @MatthewFeroz reproduced this independently and additionally checked Electron's source, which does not copy preload scripts into new windows.

Worth flagging for anyone testing this themselves: webContents.getLastWebPreferences() omits preload entirely, even for a webContents that has one, so it cannot be used to check this.

The popup is also created with contextIsolation: true, sandbox: true, nodeIntegration: false — verified at runtime as typeof require === "undefined" inside it — and denies its own window.open, so it cannot spawn further windows.

Current head is 8db8d83. All checks green, including Macroscope UI Consistency after the typing fix. Locally: 66 tests in Manager.test.ts pass, tsgo --noEmit clean for apps/web and apps/desktop, lint and format clean on the changed files.

No action needed from me unless something new turns up.

[MatthewFeroz]

Just sent a video to the maintainers of this working. Small limitation in this is that passkeys don't function but I think that's out of scope for this PR. Great work!

[walid-baharwal]

Thanks for running it and recording the video — I could not produce one myself, so that fills the gap CONTRIBUTING asks for on interaction changes.

On passkeys: that is pre-existing and tracked separately in #5665 ("In app browser not triggering passkey fingerprint to sign in on mac", open since 2026-08-07), so it predates this branch. Nothing here touches WebAuthn — the change only decides whether window.open gets a real window and what preferences that window is created with. A passkey prompt failing inside the preview fails the same way on main today, with or without a popup involved.

So I agree it is out of scope, and I would rather not widen this PR to chase it.