| Age | Commit message (Collapse) | Author |
|---|
|
Dedicated profile (~/.chrome-cdp-profile), macOS only, never for the
castle default. BU_LOCAL_CHROME_LAUNCH=off disables it.
|
|
|
|
|
|
Upstream 0.11.0 made BU_CDP_WS reach the daemon, and discoverEndpoint()
returns it before the fork's target is consulted. resolveCdpTarget() did
not know about it, so /browser-status and the system prompt named the
BU_CDP_HTTP/stored/default target while the daemon dialled the pinned URL,
and /browser-target claimed to switch browsers when it could not.
resolveCdpTarget() now puts BU_CDP_WS first, as a remote target with
source "ws". /browser-target warns that it takes precedence, as it already
did for BU_CDP_HTTP. Only host:port is ever shown: the path carries the
browser id and a proxied URL may carry a token. /browser-status does not
probe a pinned URL, since /json/version answering says nothing about
whether the pinned browser id is still current.
|
|
Upstream 0.11.0 moved BU_CDP_WS into discoverEndpoint(), so the claim
that the daemon ignores it is no longer true. Say why BU_CDP_HTTP is
still needed, where BU_CDP_WS sits in the precedence, and what to
expect and run when taking upstream releases now that upstream has a
boundary scanner and a daemon import-graph test.
|
|
|
|
|
|
Profile selection works by launching the browser with --profile-directory and
letting ProcessSingleton delegate to the running process, which only reaches a
browser on this machine. discoverEndpoint() already withholds userDataDir for a
remote target, but resolveUserDataDir() fell through to the local candidate
dirs, so the picker offered this disk's Chromium profiles for a browser on
another host - on castle, Brave's profiles for a Chrome on :9223. Pinning one
launched a local browser and polled the remote for a sentinel that could never
appear, failing after the seed deadline; seedProfileWindow()'s mismatch guard
missed it because connectedDir is undefined on the remote path.
Setup now returns early instead of prompting - the question had no actionable
answer, and since cancelling stores nothing it returned every session.
/browser-profile and seedProfileWindow() refuse with the reason, the latter
catching a pin left over from a local session.
|
|
|
|
The pre-flight check only skipped isBrowserRunning() when BU_CDP_HTTP was
set, so a machine with no local browser failed /browser-setup with 'No
browser instance running' before discovery ever dialed the built-in
castle default. Resolve the target the same way discovery does and skip
the local-process check whenever it resolves remote — env var,
/browser-target choice, or default. A resolved local target still
requires a local browser, and an unreachable remote still fails loudly
in step 4.
|
|
|
|
BU_CDP_HTTP is an override rather than a requirement, and /browser-status
explains the lazy connection instead of showing a bare red light.
|
|
Kept out of README.md so upstream's own README continues to merge cleanly.
|
