[Bug]: Agent browser automation (orca tab create/switch) forcibly steals Windows foreground focus — no setting or flag to disable #16674

Summary

When a coding agent drives the built-in Orca browser via the CLI (core workflow for browser-automation tasks), the Orca main window forcibly steals the Windows foreground focus on every tab create/switch, interrupting whatever the user is typing in other apps. There is currently no setting or flag to disable this.

Related but more specific than #13278 (which describes the symptom without a repro or root cause).

Environment

• Orca: 1.4.188 (Windows installer)
• OS: Windows 10/11 (focus stealing is most aggressive on Windows due to the foreground-lock workaround, see below)
• Workflow: agent sends orca tab create / orca tab switch / orca snapshot ... from an Orca-managed terminal while the user is working in another app (IDE, browser, chat).

Steps to reproduce

1. Focus any other application (e.g. a text editor) and start typing.
2. From an agent terminal (or any shell), run:

   orca tab create --url https://example.com --json
   

3. The Orca window jumps to the foreground; your keystrokes now land into Orca.
4. Same happens on orca tab switch --index <n> while another app is focused.

Commands that do not steal focus (good): orca snapshot, orca click, orca eval, orca navigate — when targeted at an already-active tab via --page <browserPageId>.

Root cause (from app.asar of 1.4.188)

I dug into the bundled main-process bundle and found three distinct paths that force window activation, none of which are gated by a user setting:

1. focusOnCreate defaults to true when creating browser tabs

const shouldFocusOnCreate = args.focusOnCreate !== false; // default: focus

→ creating a tab focuses the renderer, which raises the main window.

2. The CDP bridge handles Page.bringToFront unconditionally

if (msg.method === "Page.bringToFront") {
    if (!this.webContents.isDestroyed()) this.webContents.focus();
    ...
}

Agent-browser tab activation (what orca tab switch drives) always triggers webContents.focus() → window raised, no "is the window currently in the background?" check.

3. activateWindow() uses a Windows-specific foreground-lock bypass

function activateWindow(window, app, platform, setTimer) {
    safelyFocusApp(app);
    safelyRevealWindow(window);
    if (platform === "win32") {
        window.moveTop();
        pulseAlwaysOnTop(window, setTimer); // setAlwaysOnTop(true) … 250ms … false
        retryFocus(window, app, setTimer);  // +100ms retry
    }
}

pulseAlwaysOnTop is a deliberate workaround for Windows' SetForegroundWindow restrictions — i.e. even when the OS tries to protect the user's foreground, Orca forces itself on top. This is reached via shouldActivateDesktopForSecondInstance(argv) → !argvRequestsServeMode(argv), so essentially every second-instance CLI invocation is eligible.

Impact

Agent-driven browser testing/verification is a headline Orca workflow, but it makes the machine unusable for anything else while the agent runs: every tab operation rips the user out of their current window. Users must either minimize Orca (downgrades to taskbar flash) or move it to another virtual desktop.

Requested behavior (any of these would fix it)

1. CLI flag: orca tab create --no-focus / orca tab switch --no-focus (and/or a global ORCA_NO_FOCUS=1 env var) so agent-driven automation can stay fully background.
2. Setting: a "Keep Orca in the background when agents use the browser" toggle (Settings → Browser or → General).
3. Conditional activation: in the Page.bringToFront handler, skip webContents.focus() when the Orca window is not the foreground window at that moment (only mark the tab active internally).

Option 3 is the least invasive and keeps interactive use behaving exactly as today.

Happy to provide traces/procmon evidence if useful. Thanks for the great product — the agent browser skill itself works beautifully once focus stealing is out of the way!