feat: add focus command for SPAs that never render in a hidden tab - #8
Open
motin wants to merge 1 commit into
Open
feat: add focus command for SPAs that never render in a hidden tab#8motin wants to merge 1 commit into
focus command for SPAs that never render in a hidden tab#8motin wants to merge 1 commit into
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.
focusreports the resulting visibility rather than just claimingsuccess, 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.