Skip to content

feat: add focus command for SPAs that never render in a hidden tab - #8

Open
motin wants to merge 1 commit into
masterfrom
feat/focus-command
Open

feat: add focus command for SPAs that never render in a hidden tab#8
motin wants to merge 1 commit into
masterfrom
feat/focus-command

Conversation

@motin

@motin motin commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

Tabs are created in the background and never activated, so
document.visibilityState is "hidden". Most pages don't care. But an SPA
that gates its first data fetch on visibility sits on a spinner forever,
and read/snapshot/eval just keep returning "Loading…" with nothing to
explain why. It looks exactly like the site being down.

The remedy already exists in the codebase — forceForeground() — but only
click and drop call it, so there was no way to unstick a page you only
wanted to READ. This exposes it:

browser-automation focus -s app
browser-automation goto -s app --focus https://app.example.com

Both flip the tab to visible+focused via the same bringToFront +
setFocusEmulationEnabled + setWebLifecycleState trio, and still never
raise the Chrome window or take focus from the user's terminal.

focus reports the resulting visibility rather than just claiming
success, since all three CDP calls are best-effort and an older Chrome
may not support focus emulation — in which case you want to know that,
not a green tick.

Found against resend.com's dashboard, where every page hung indefinitely
in a background tab and rendered on the first poll after focusing.
Verified both forms against that reproduction.

Deliberately opt-in rather than folded into goto by default: that would
be the bigger quality-of-life win but changes behaviour for every
existing caller, so it seemed yours to decide.

Tabs are created in the background and never activated, so
document.visibilityState is "hidden". Most pages don't care. But an SPA
that gates its first data fetch on visibility sits on a spinner forever,
and read/snapshot/eval just keep returning "Loading…" with nothing to
explain why. It looks exactly like the site being down.

The remedy already exists in the codebase — forceForeground() — but only
click and drop call it, so there was no way to unstick a page you only
wanted to READ. This exposes it:

  browser-automation focus -s app
  browser-automation goto -s app --focus https://app.example.com

Both flip the tab to visible+focused via the same bringToFront +
setFocusEmulationEnabled + setWebLifecycleState trio, and still never
raise the Chrome window or take focus from the user's terminal.

`focus` reports the resulting visibility rather than just claiming
success, since all three CDP calls are best-effort and an older Chrome
may not support focus emulation — in which case you want to know that,
not a green tick.

Found against resend.com's dashboard, where every page hung indefinitely
in a background tab and rendered on the first poll after focusing.
Verified both forms against that reproduction.

Deliberately opt-in rather than folded into goto by default: that would
be the bigger quality-of-life win but changes behaviour for every
existing caller, so it seemed yours to decide.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant