Summary
bsk click returns success — exit code 0 plus a plausible click coordinate — while no input is delivered to the page at all when the session's Agent Window is not in the foreground (session started with --no-focus). Nothing in the response distinguishes "clicked" from "did nothing", so an agent that trusts the CLI proceeds as if the interaction happened.
Environment
- bsk: 0.2.1 (
bsk update --check → bsk 0.2.1 is already up to date)
- OS: Windows 11 (x64)
- Browser: Chromium-based, BrowserSkill extension connected (
bsk doctor: extension connected · 1 browser, browser protocol compatible)
- Driver: a harness plugin that shells out to the
bsk CLI (@wxg-prc-cpg/browser-skill-dsh-plugin 0.2.1). The plugin forwards the target verbatim (bsk click --session <id> <ref|selector>); the behaviour is reproducible from the CLI alone.
- Page viewport at the time: 631x880 CSS px,
devicePixelRatio 1.5
- Test page: plain local HTML (no framework, no iframe)
Minimal reproduction
Test page — the two buttons and the four capture-phase listeners are all that matter:
<!doctype html>
<html><head><meta charset="utf-8"><title>bsk click probe</title>
<style>button{display:block;width:260px;padding:12px}#status{font-size:15px;font-weight:700;color:#b00;white-space:pre-wrap}
.f{height:60px;border-bottom:1px solid #ddd}</style></head>
<body>
<button id="top" onclick="mark('TOP')">TOP</button>
<div id="status">status: none</div>
<div id="filler"></div>
<button id="bottom" onclick="mark('BOTTOM')">BOTTOM</button>
<script>
const filler = document.getElementById('filler');
for (let i = 0; i < 40; i++) { const d = document.createElement('div'); d.className = 'f'; filler.appendChild(d); }
window.mark = n => { document.getElementById('status').textContent = 'status: clicked ' + n; };
const log = [];
for (const k of ['pointerdown', 'mousedown', 'mouseup', 'click']) {
document.addEventListener(k, e => {
log.push(`${k} client=(${Math.round(e.clientX)},${Math.round(e.clientY)}) target=${e.target.tagName}#${e.target.id||''}`);
document.getElementById('status').textContent = 'events:\n' + log.slice(-6).join('\n');
}, true);
}
</script>
</body></html>Steps:
bsk session start --no-focus → navigate the Agent Window to the page (background window, never brought to the front)bsk click --session <id> '#top' — CSS selector on purpose, to rule out snapshot-ref staleness- Read the page: the status line is still
status: none; none of the four listeners fired
bsk session stop, then bsk session start (no --no-focus) → repeat the identical click → the status line becomes status: clicked TOP
Observed
Background window — success reported, nothing delivered:
$ bsk click --session <id> '#top'
clicked at (138, 39.33333396911622) on tab <tabId>
…while the page's event log stayed empty (status: none).
Foreground window — identical target, identical reported coordinate (138, 39.33), and the click lands (status: clicked TOP).
So the coordinates bsk computes are correct in both runs; only delivery differs, and neither the CLI output nor the exit code reflects it. Repeating the click (ref form, then selector form) does not help while the window is in the background — both attempts report success, neither is delivered.
Expected
Either:
- Deliver it: activate/raise the Agent Window (or the target tab) before dispatching input, so a click works regardless of how the session was started; or
- Fail loudly: a non-zero exit plus an explicit error such as
input not delivered: Agent Window is not focused, so callers can focus and retry.
Reporting a coordinate plus success while delivering nothing is the dangerous middle ground.
Impact
We hit this while filling a 12-question multiple-choice form. The session was started with --no-focus to avoid stealing the user's focus. The clicks issued while the window was still in the background never registered (those four questions were left unanswered), while the ones issued later landed — and every single call reported success. The transcript looked perfect; the form was partially unset. That is a silent-corruption failure mode for any agent-driven form or UI task.
(The "window came to the foreground" transition is our inference from the session; the A/B test above is the hard evidence.)
What did not help
bsk click --help exposes --ref, --selector, --button, --click-count, --modifiers, --timeout, --tab-id — there is no activate / bring-to-front option.bsk window only has resize; there is no focus / raise subcommand.bsk tab select exists ("Activate (focus) a tab in the session's Agent Window") but I could not verify whether it also raises the containing window: the daemon is owned by the integrating harness, so from an outer shell bsk status / bsk session list answer ensure daemon is running (exit code 2). If tab select does raise the window, documenting "input commands require a foreground Agent Window" would already be a big improvement — and a bsk click --activate (or equivalent) would be the natural fix.
中文摘要
问题：Agent Window 处于后台时（会话以 --no-focus 启动），bsk click 会静默失效——返回成功、还打印一个完全正确的点击坐标，但页面收不到任何输入事件（pointerdown / mousedown / mouseup / click 一个都没触发）。把窗口置于前台后，同样的目标、同样的坐标就能点中。
对照证据：同一页面、同一目标 #top、同一坐标 (138, 39.33)；后台窗口下页面事件日志为空，前台窗口下 status: clicked TOP。
期望：点击前自动激活 Agent Window；若确实无法投递输入，请报错并非零退出，而不是返回成功。现在这种"报成功却什么都没发生"的行为，会让 agent 在填表/操作 UI 时静默把任务做错——我们填 12 道选择题时就遇到：12 次点击全部报成功，实际有几道根本没选上。
Summary
bsk clickreturns success — exit code 0 plus a plausible click coordinate — while no input is delivered to the page at all when the session's Agent Window is not in the foreground (session started with--no-focus). Nothing in the response distinguishes "clicked" from "did nothing", so an agent that trusts the CLI proceeds as if the interaction happened.Environment
bsk update --check→bsk 0.2.1 is already up to date)bsk doctor:extension connected · 1 browser,browser protocol compatible)bskCLI (@wxg-prc-cpg/browser-skill-dsh-plugin0.2.1). The plugin forwards the target verbatim (bsk click --session <id> <ref|selector>); the behaviour is reproducible from the CLI alone.devicePixelRatio1.5Minimal reproduction
Test page — the two buttons and the four capture-phase listeners are all that matter:
Steps:
bsk session start --no-focus→ navigate the Agent Window to the page (background window, never brought to the front)bsk click --session <id> '#top'— CSS selector on purpose, to rule out snapshot-ref stalenessstatus: none; none of the four listeners firedbsk session stop, thenbsk session start(no--no-focus) → repeat the identical click → the status line becomesstatus: clicked TOPObserved
Background window — success reported, nothing delivered:
…while the page's event log stayed empty (
status: none).Foreground window — identical target, identical reported coordinate
(138, 39.33), and the click lands (status: clicked TOP).So the coordinates bsk computes are correct in both runs; only delivery differs, and neither the CLI output nor the exit code reflects it. Repeating the click (ref form, then selector form) does not help while the window is in the background — both attempts report success, neither is delivered.
Expected
Either:
input not delivered: Agent Window is not focused, so callers can focus and retry.Reporting a coordinate plus success while delivering nothing is the dangerous middle ground.
Impact
We hit this while filling a 12-question multiple-choice form. The session was started with
--no-focusto avoid stealing the user's focus. The clicks issued while the window was still in the background never registered (those four questions were left unanswered), while the ones issued later landed — and every single call reported success. The transcript looked perfect; the form was partially unset. That is a silent-corruption failure mode for any agent-driven form or UI task.(The "window came to the foreground" transition is our inference from the session; the A/B test above is the hard evidence.)
What did not help
bsk click --helpexposes--ref,--selector,--button,--click-count,--modifiers,--timeout,--tab-id— there is no activate / bring-to-front option.bsk windowonly hasresize; there is nofocus/raisesubcommand.bsk tab selectexists ("Activate (focus) a tab in the session's Agent Window") but I could not verify whether it also raises the containing window: the daemon is owned by the integrating harness, so from an outer shellbsk status/bsk session listanswerensure daemon is running(exit code 2). Iftab selectdoes raise the window, documenting "input commands require a foreground Agent Window" would already be a big improvement — and absk click --activate(or equivalent) would be the natural fix.中文摘要
问题：Agent Window 处于后台时（会话以
--no-focus启动），bsk click会静默失效——返回成功、还打印一个完全正确的点击坐标，但页面收不到任何输入事件（pointerdown/mousedown/mouseup/click一个都没触发）。把窗口置于前台后，同样的目标、同样的坐标就能点中。对照证据：同一页面、同一目标
#top、同一坐标(138, 39.33)；后台窗口下页面事件日志为空，前台窗口下status: clicked TOP。期望：点击前自动激活 Agent Window；若确实无法投递输入，请报错并非零退出，而不是返回成功。现在这种"报成功却什么都没发生"的行为，会让 agent 在填表/操作 UI 时静默把任务做错——我们填 12 道选择题时就遇到：12 次点击全部报成功，实际有几道根本没选上。