computer_use/browser/
mod.rs

1//! P10: Chrome DevTools Protocol (CDP) attach-only client.
2//!
3//! The CLI thread stays sync. Every browser call spins up a fresh
4//! `tokio::runtime::Builder::new_current_thread()` runtime, runs the async CDP
5//! request, and drops the runtime before returning. The backend never spawns
6//! Chrome — the user already started the browser with
7//! `--remote-debugging-port=N`, and we just attach.
8//!
9//! Built only when the `cdp` feature is on. The default build exposes the
10//! `unsupported` error code and nothing else.
11//!
12//! ## Port discovery
13//!
14//! When the caller passes `--cdp` without `--cdp-url`, we look up the Chrome
15//! pid that owns the `--app` (or the frontmost one if no app is named) and
16//! read its argv:
17//!
18//! * macOS: `sysctl KERN_PROCARGS2` for the pid.
19//! * Linux: `/proc/<pid>/cmdline` (NUL-separated UTF-8).
20//! * Windows: best-effort; not implemented in this phase (see ROADMAP.md).
21//!
22//! Only the first matching `--remote-debugging-port=N` wins. The handler
23//! `ws://127.0.0.1:<N>` is what we hand to `chromiumoxide::Browser::connect`.
24//!
25//! ## Viewport -> screen mapping (P5 reuse)
26//!
27//! `browser_click` resolves a CSS selector, asks the element to click, and
28//! chromiumoxide clicks in CSS pixel space. The screenshot layer maps those
29//! coordinates into physical screen coordinates for the existing P3 click
30//! path. HiDPI and CSS pixels-above-fold cases still rely on the configured
31//! `coord` ratio like the rest of the codebase; we do not introduce a new
32//! viewport transform here.
33
34pub mod cdp;
35
36pub use cdp::{discover_debug_port, parse_debug_port, ActionOptions, AttachOptions, TabSummary};
computer_use/browser/mod.rs

computer_use/browser/
mod.rs
