diff options
Diffstat (limited to 'FORK.md')
| -rw-r--r-- | FORK.md | 40 |
1 files changed, 40 insertions, 0 deletions
@@ -117,6 +117,46 @@ needed at all. Note the branch here is `master` (matching the other repos on castle) while upstream uses `main`. +## Browser profiles are local-only + +Upstream's `/browser-profile` does not work against a remote target, and this +fork now says so instead of guessing. + +Choosing a profile is not a CDP operation. `Target.createTarget` rejects another +profile's `browserContextId`, and a bare createTarget lands in the focus-derived +default context, so the only way in is the browser's own command line — +`--profile-directory`, delegated to the running browser by Chromium's +ProcessSingleton (`src/profile/launch.ts`). That is a local-process mechanism +with no remote equivalent. + +`discoverEndpoint()` already returns no `userDataDir` for a remote target, but +`resolveUserDataDir()` used to fall through to `userDataDirCandidates()` — the +Chromium user-data-dirs on *this* disk. On castle that meant the picker offering +Brave's profiles while the harness was connected to castle's Chrome on :9223, +and `seedProfileWindow()` could not catch it: its mismatch guard is +`connectedDir && connectedDir !== pin.userDataDir`, and `connectedDir` is +undefined on the remote path. Pinning launched a local Brave window and then +polled the remote browser for a sentinel that could never appear there, failing +only after the 15s seed deadline. + +So, for a remote target: + +- **setup never prompts.** `promptForProfileIfUnset()` returns early. A prompt + with no actionable answer is bad enough; because cancelling stores nothing, it + also came back every single session. +- **`/browser-profile` refuses**, naming the target and pointing at + `/browser-target local`. +- **`seedProfileWindow()` refuses**, which catches a pin left over from a local + session rather than letting it launch a browser on the wrong machine. + +The default against a remote browser is therefore unpinned — whichever window is +focused. castle's `~/.chrome-cdp-profile` has exactly one profile (`Default`), +so there is nothing to disambiguate. + +Making profiles selectable on castle needs the `--profile-directory` launch to +happen *on castle*, next to the browser — not a patch to this path, a separate +piece of machinery. Unbuilt so far. + ## Verifying after a merge With a browser exposed at `$BU_CDP_HTTP`: |