#2146

`click` reports ✓ Done but misses when the pinned tab is in the background (visibilityState hidden)

Openaster-voidopened 12d ago

When a session's pinned tab is not the active tab in its window (document.visibilityState === "hidden"), click on some elements reports ✓ Done but the page's handler never runs. The same element clicks fine once the tab is in front, and a JS-dispatched click works even while the tab stays hidden.

Repro

Several sessions share one Chromium over --cdp + --pin-tab. Any open from another session pushes your tab to the background.

agent-browser open https://www.google.com
agent-browser --session other open about:blank   # our tab is now hidden
agent-browser eval 'document.visibilityState'    # "hidden"
agent-browser fill '[name=q]' 'test'             # suggestion dropdown opens
agent-browser snapshot -i                        # first `button "Google Search"` = the one inside the dropdown (not covered)
agent-browser click @eN                          # ✓ Done
agent-browser get url                            # still https://www.google.com/
tab stateactionnavigated
hiddenclick @ref (dropdown "Google Search")0/6
visiblesame3/3
hiddeneval dispatching mousedown→mouseup→click on the same element3/3
hiddenclick on "Google apps" toggle (aria-expanded flips)10/10

So not every click fails in a hidden tab, only some handlers (here a dropdown that closes on blur). We also saw the same pattern on the Gmail send button and Google sign-in/consent pages.

Expected

Either the click lands, or click doesn't report success. For example, click could bring the tab to the front first, or warn when the target's page is hidden.

Related: #1624 (background tabs are throttled, so screenshots stall), #1247 (bringToFront / background mode).

Environment: agent-browser 0.38.2, Chrome 154.0.8037.97, Linux (Xvfb), --cdp 9222 with pinTab. The 0.39.x release notes don't mention click changes.


Investigated and filed by Claude (Claude Code) on behalf of @aster-void.

Activity

1
Brandon1683d ago

Measured on 0.39.4 with several --pin-tab sessions sharing one CDP-attached Chrome: in a pinned tab that wasn't frontmost, Chrome took about 5 s to acknowledge each mouse event and some clicks missed. Holding Emulation.setFocusEmulationEnabled on that target for the length of the command fixed it (click 5.19 s → 0.16 s), which matches what #1427 proposes. My setup now runs every non-read command through that hold in a wrapper.