Feature request: allow Agent Window to be created already minimized (chrome.windows.create state)

Open
  • Is something wrong?
#649 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
65/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
backend, desktop

Research direction

Start by reading the window-creation helper in background.js and trace how session options reach it; the issue also identifies a tab-detach creation path with the same shape. Check the extension tests or existing coverage for window creation, then verify that a session configured to start minimized creates both windows minimized while page automation still works. The issue does not name a test file.

Written by the indexing model from the issue text.

Description

Summary

When a session is started with the default background mode (--no-focus), the Agent Window is still created as a normal, visible window. On a normal (non-fullscreen) desktop it paints its first frame — a white about:blank window — before any caller can react, so users see a brief white flash even when the automation immediately minimizes it.

Request: let the Agent Window be created in the minimized state, so it never exists as a visible normal window.

Environment
OS Windows 10 (18362)
Browser Microsoft Edge
Extension BrowserSkill 0.4.2 (Edge Add-ons build)
CLI bsk session start (default --no-focus)

Steps to reproduce

  1. Have a dark window in the foreground (e.g. a video player, windowed).
  2. Run bsk session start with the default background mode.
  3. Watch the screen.

Expected: nothing appears; the Agent Window only exists in the taskbar.

Actual: a white window frame flashes for a moment before the caller minimizes it.

Root cause

chrome.windows.create is called without a state field, in the window-creation helper of background.js:

const win = await chrome.windows.create({
  type: `normal`,
  focused: t.focused ?? !1,
  incognito: t.incognito ?? !1,
  url: e,
  ...(t.size ? { width: t.size.width, height: t.size.height } : {})
});

The tab-detach path has the same shape:

const id = (await this.api.windows.create({
  tabId: e, type: `normal`, focused: !1, ...(a.incognito ? { incognito: !0 } : {})
}))?.id;

focused: false only means "don't steal focus" — the window is still shown and composited. A caller can therefore only minimize it after windows.create resolves, and by then the first white frame may already have been presented. Measured latency from a polling caller is ~40 ms, which still lands on several vsync intervals and is clearly visible against dark content.

Proposed fix

chrome.windows.create already accepts state: "minimized":

const win = await chrome.windows.create({
  type: `normal`,
  focused: t.focused ?? !1,
  state: t.minimized ? `minimized` : undefined,   // <-- new
  incognito: t.incognito ?? !1,
  url: e,
  ...(t.size ? { width: t.size.width, height: t.size.height } : {})
});

Any of these interfaces would work:

  • Extension setting — "Open Agent Window minimized" (best: users opt in once, no CLI change needed).
  • CLI flag — bsk session start --minimized, forwarded to the extension.
  • New default — when --no-focus is used, create minimized unless --focus is explicitly requested.

Notes

  • A minimized window keeps its renderer alive: navigating, DOM queries, screenshots and sync all still work. Verified against 0.4.2 by minimizing an Agent Window externally and then driving the page normally.
  • The extension already performs the same transition elsewhere — the focus-restore helper after a task popup calls windows.update(id, { state: minimized }) — so the state change itself is known-good; only the create-time path is missing it.
  • If state at creation is not viable, a windows.update({state:'minimized'}) issued immediately after create (before returning) would also narrow the exposure window considerably, though create-time state is the clean fix.
Dominant language
TypeScript
Stars
10.1k
Forks
732
Avg merge
1d 21h
Merged PRs (30d)
97

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Tencent/BrowserSkill

All issues in Tencent/BrowserSkill

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.