Browser Bridge: new windows steal focus on macOS (should use tabs instead)

[rickexpgame]

Problem

The Browser Bridge extension creates new Chrome windows (chrome.windows.create) for each automation workspace. On macOS, every new window steals focus from the user's active application, making the computer unusable during automated scans.

Current behavior

1. Each opencli command triggers getAutomationWindow() in the extension's background.js
2. If no existing session for the workspace, it calls chrome.windows.create({ focused: false, ... })
3. macOS ignores focused: false — the new window always activates and comes to front
4. Different OPENCLI_CDP_TARGET values create separate workspaces, each spawning its own window
5. Windows idle-timeout after 30s (WINDOW_IDLE_TIMEOUT), so repeated scans keep creating/destroying windows

Impact

When running batch scans (e.g., 146 restaurants across tabelog/omakase/tablecheck), the user experiences:

• Constant window pop-ups stealing keyboard/mouse focus
• Inability to use other applications during the ~60 min scan
• Chrome windows flashing on screen every few seconds

Attempted workarounds (all insufficient)

Approach	Result
focused: false	macOS ignores this for new windows
state: "minimized" in create()	Conflicts with focused/width/height params
chrome.windows.update(id, {state:"minimized"}) after create	Works but window still flashes briefly on main screen
left: -9999 (off-screen)	Chrome rejects: "Bounds must be at least 50% within visible screen space"
Move to secondary monitor after create	Works but still flashes on primary screen first
--window-position Chrome flag	Ignored by Google Chrome (only works in Chromium)

Suggested fix

Follow the pattern used by the Claude in Chrome extension:

• Use tabs within an existing window (chrome.tabs.create) instead of new windows (chrome.windows.create)
• Optionally use a tab group to isolate automation tabs
• This avoids the macOS focus-stealing issue entirely, since new tabs don't activate the window

Minimal code change suggestion

In the extension's background.js, getAutomationWindow():

// Instead of:
const win = await chrome.windows.create({ url: BLANK_PAGE, ... });

// Consider:
// Reuse the existing Chrome window, create a tab in it
const [existingWindow] = await chrome.windows.getAll({ windowTypes: ['normal'] });
const tab = await chrome.tabs.create({ 
  windowId: existingWindow.id, 
  url: BLANK_PAGE, 
  active: false  // this actually works for tabs, unlike focused:false for windows
});

Environment

• macOS 15 (Darwin 25.3.0)
• Google Chrome 146.0.7680.178
• opencli v1.6.1, extension v1.5.5
• Dual monitor setup (Studio Display + DELL S2722QC)

[Astro-Han]

Thanks for the detailed report!

I tried to reproduce on macOS 26.3.1 + Chrome 146.0.7680.178 (same Chrome version as yours), including waiting for the 30s idle timeout to force a fresh chrome.windows.create(). The new window did not steal focus in any test.

Could you provide some additional info to help narrow this down?

1. macOS minor version — exact sw_vers output
2. Single vs dual monitor — does the issue occur with only one display connected?
3. Chrome flags — any flags enabled in chrome://flags?
4. System Settings > Desktop & Dock > "Stage Manager" — enabled or disabled?
5. Extension version — output of the Browser Bridge version in chrome://extensions

[gucasbrg]

Fix confirmed

Root cause: getAutomationWindow() always calls chrome.windows.create() when session expires (30s idle timeout), creating a new window each time.

Fix: Check for existing Chrome windows first via chrome.windows.getAll(), reuse if available:

// In getAutomationWindow(), replace chrome.windows.create with:
const allWindows = await chrome.windows.getAll({ windowTypes: ["normal"] });
let windowId;
if (allWindows.length > 0) {
  windowId = allWindows[0].id;
} else {
  const win = await chrome.windows.create({ url: BLANK_PAGE, focused: false, width: 1280, height: 900, type: "normal" });
  windowId = win.id;
}

resolveTabId() already handles tab reuse within the window, so no tab management changes needed.

Tested on macOS 26.2, Chrome 146, opencli v1.6.1 — ran opencli sinafinance news 3 times in sequence, no new windows created.

[gucasbrg]

Additional findings

We traced the root cause further:

The 30s WINDOW_IDLE_TIMEOUT is causing repeated window creation/destruction.

Our setup: a news collector calls opencli sinafinance rolling-news every 60 seconds. Since 60s > 30s timeout, each call triggers:

1. Previous automation window destroyed (idle timeout)
2. New chrome.windows.create() → steals focus on macOS
3. Command runs, then window sits idle
4. 30s later, destroyed again
5. Repeat

Questions for maintainers:

1. Why does the automation window need to be destroyed at all? Creating once and reusing forever would avoid the focus-stealing issue entirely. The window uses minimal resources when idle.

2. Could WINDOW_IDLE_TIMEOUT be made configurable via an environment variable (e.g. OPENCLI_WINDOW_IDLE_TIMEOUT)? This would let users set it to match their polling interval, or disable it entirely with 0 or Infinity.

3. Would you accept a PR that changes the default to never auto-destroy (or a much longer timeout like 10 minutes)?

Current workaround: Manually patching dist/background.js to increase WINDOW_IDLE_TIMEOUT, but this gets overwritten on every npm update.

[Astro-Han]

Thanks for the deep dive on the idle timeout, @gucasbrg. Reducing window recreation frequency would be a big improvement for polling use cases like yours.

One thing worth flagging: the chrome.windows.getAll() approach would return all Chrome windows including the user's personal ones. Picking allWindows[0] could inject automation into a regular browsing window, which conflicts with the isolation design of getAutomationWindow().

Also, even with an infinite timeout, the first window creation (or any recreation after user closes it) would still steal focus on macOS. So this would be a great mitigation for the frequency problem, but the original focus-stealing issue from chrome.windows.create() would remain for the initial creation.

[rickexpgame]

Thanks for the investigation @gucasbrg!

I tested the chrome.windows.getAll() reuse approach on our setup (macOS 15, Chrome 146, dual monitor). Results:

First scan succeeded (tablecheck returned 4 dates), but then the service worker crashed and all subsequent scans failed with "Browser Bridge not connected". The extension's service worker disappeared entirely from chrome://extensions — no restart, no error in the UI.

Steps to reproduce:

1. Applied the patch to getAutomationWindow() in dist/background.js
2. Reloaded extension via chrome.developerPrivate.reload()
3. First opencli tablecheck availability call worked (reused existing window)
4. Second call: Bridge disconnected
5. opencli doctor shows Extension: not connected
6. Service worker not listed in CDP /json/list

My guess: when reusing an existing window that wasn't created by the extension, the resolveTabId() or tab management logic may reference state (like session.idleTimer) that doesn't match, causing an unhandled exception that kills the service worker.

Our current workaround: We patch chrome.windows.create to immediately move the new window to a secondary monitor via chrome.windows.update(win.id, { left: 2600, top: 100 }). The window still steals focus momentarily but it's on a different display so the user doesn't notice.

@Astro-Han to answer your questions:

• sw_vers: macOS 15.3.1 (Build 24D70)
• Dual monitor: Studio Display (primary) + DELL S2722QC
• Issue occurs with dual monitors; haven't tested single
• Stage Manager: disabled
• No custom chrome://flags
• Extension: v1.5.5 (unpacked, loaded via chrome://extensions)

[Astro-Han]

The key difference might be the macOS version. I tested on macOS 26.3.1 (same Chrome 146) and couldn't reproduce the focus stealing. Both of you are on macOS 15.x (Sequoia, released late 2024).

This suggests macOS 15's window server forces focus on newly created windows regardless of the app's focused: false request, and Apple changed this behavior in a later release. Since Chrome version is identical across all our setups, it's likely a platform-level issue.

@rickexpgame the secondary-monitor workaround via chrome.windows.update is clever for dual-display setups. Also good to know the getAll() approach crashes the service worker, confirms the isolation concern.