Summary
Named or sized window.open() calls in the desktop in-app browser are converted into in-panel tabs and the page receives null instead of a Window. This breaks OAuth flows that depend on window.opener and postMessage; those flows should open a native, sandboxed popup while ordinary target="_blank" links continue to open as in-panel tabs.
Versions and environment
- bb 0.40.0 desktop app
- Also reproduced from source on
main at f4bbc2fe81a9b7639ff9a7396e172bddd89109e4
- macOS 26.5.2
- Node 22.22.0
- Electron 41.7.0
Steps to reproduce
- Create a minimal cross-origin popup fixture:
mkdir -p /tmp/bb-popup-repro
cat >/tmp/bb-popup-repro/index.html <<'HTML'
<!doctype html>
<button id="open">Open popup</button>
<pre id="output"></pre>
<script>
const output = document.querySelector("#output");
let received = false;
window.addEventListener("message", (event) => {
received = true;
output.textContent += "\npostMessage: " + event.data;
});
document.querySelector("#open").addEventListener("click", () => {
const popup = window.open(
"http://localhost:8791/popup.html",
"oauth",
"width=520,height=700"
);
output.textContent =
popup === null
? "window.open returned null"
: "window.open returned Window";
setTimeout(() => {
if (!received) output.textContent += "\npostMessage: TIMEOUT";
}, 1000);
});
</script>
HTML
cat >/tmp/bb-popup-repro/popup.html <<'HTML'
<!doctype html>
<pre id="output"></pre>
<script>
document.querySelector("#output").textContent =
"window.opener: " + Boolean(window.opener);
window.opener?.postMessage(
"oauth-complete",
"http://127.0.0.1:8791"
);
</script>
HTML
python3 -m http.server 8791 --directory /tmp/bb-popup-repro
- In bb desktop, open a new Browser tab in the secondary panel.
- Navigate to
http://127.0.0.1:8791/index.html.
- Click Open popup.
Expected vs actual
Actual in the parent page:
window.open returned null
postMessage: TIMEOUT
Actual in the page that bb opens as a separate in-panel tab:
window.opener: false
Expected in the parent page:
window.open returned Window
postMessage: oauth-complete
Expected in the native popup:
window.opener: true
Evidence
- The handler on the tested base commit routes the URL to an in-panel tab and then unconditionally returns
{ action: "deny" }: desktop-browser-view.ts lines 437-457.
- Public investigation artifact and regression test: kravtsovd/bb commit ef65dcc2f.
- The regression test fails on the base implementation with
expected "allow", received "deny".
- A real Electron 41.7.0 probe against the proposed handler returned
{"opened":true,"message":{"kind":"oauth-complete","hasOpener":true,"nestedBlocked":true,"sharedCookie":true},"timeout":false}.
What you ruled out
- Still present in the latest release and on
main at f4bbc2fe81a9b7639ff9a7396e172bddd89109e4.
- Not a cookie-persistence problem: the desktop browser already uses a persistent partition, and the real Electron probe confirms the popup shares that partition.
- Not a duplicate found under popup, OAuth,
window.open, window.opener, or postMessage in open and closed issues.
- Bare
target="_blank" links do not need a native popup and remain compatible with the existing in-panel tab behavior.
Suggested priority and effort
Medium - blocks OAuth providers that require opener communication; alternate login methods may exist; implementation effort is small to medium.
Checks
AGENT GENERATED
Summary
Named or sized
window.open()calls in the desktop in-app browser are converted into in-panel tabs and the page receivesnullinstead of aWindow. This breaks OAuth flows that depend onwindow.openerandpostMessage; those flows should open a native, sandboxed popup while ordinarytarget="_blank"links continue to open as in-panel tabs.Versions and environment
mainatf4bbc2fe81a9b7639ff9a7396e172bddd89109e4Steps to reproduce
http://127.0.0.1:8791/index.html.Expected vs actual
Evidence
{ action: "deny" }: desktop-browser-view.ts lines 437-457.expected "allow", received "deny".{"opened":true,"message":{"kind":"oauth-complete","hasOpener":true,"nestedBlocked":true,"sharedCookie":true},"timeout":false}.What you ruled out
mainatf4bbc2fe81a9b7639ff9a7396e172bddd89109e4.window.open,window.opener, orpostMessagein open and closed issues.target="_blank"links do not need a native popup and remain compatible with the existing in-panel tab behavior.Suggested priority and effort
Medium - blocks OAuth providers that require opener communication; alternate login methods may exist; implementation effort is small to medium.
Checks
main.