Bohdan Triapitsyn
a5aa32446d
The preview panel worked by proxying a dev server through OpenChamber's own origin and rewriting the HTML that came back. Anything the rewriter did not anticipate broke, and pages that refuse to be embedded never loaded at all. This deletes the proxy (-1604 lines and its tests) and merges the preview and browser panels into one surface backed by a real Chromium view. What the panel is now - A `<webview>` in its own session partition: logins and cookies persist, hot reload works because nothing is rewritten, DevTools are one click away. - Annotation: pick one element, drag a region, or draw freehand, write a note, and it reaches chat with a screenshot of the visible page with the marks on it. - Toolbar: hard reload, page zoom, device sizes, a light/dark switch that applies to the page rather than the app, and cookie/cache clearing scoped to the panel alone. - Several pages at once, each tab showing the page's own favicon, and an address bar that suggests pages already visited in this project. - Dev servers are listed from what is actually listening on the machine, checked against what a project announced, so a server is offered no matter how it was started. One that is still starting is waited for instead of failing. Remote dev servers The desktop app binds a local port and pipes raw bytes to the OpenChamber host over the existing authenticated connection, so the page keeps its own origin at the root of its own host. The reachable set is exactly what discovery reports and is re-checked per connection, so an authenticated client cannot dial arbitrary local services on the host. Links and redirects to another loopback port stay on the machine that served the page. A tunnel that cannot be opened is reported; it is never replaced by the plain loopback URL, which would answer from the user's own machine under a remote address. Agent control Browser actions are a separate `openchamber_web` tool: open, snapshot, click, type, scroll, inspect computed styles, resize between mobile/tablet/desktop, and capture a screenshot into `.openchamber/screenshots/` in the project. The existing `openchamber` tool keeps sessions, worktrees and scheduled tasks. Each has its own setting in the new Settings -> General -> OpenChamber Tools section, and the plugin is not injected at all when both are off. Capability belongs to the connected client, not to configuration: a client declares on its event stream that it can drive a page, which only a Chromium host does. Exactly one client performs each request — it claims the request before acting, and the first claim wins — because deciding by whose result arrives first would be too late for a click that already happened. No client listening is answered immediately with an explanation rather than a timeout. Runtime boundaries Web tabs get a plain iframe that can display a page but not inspect one. The VS Code extension no longer offers the surface at all, since nothing that makes the panel worth having works there. Mobile is unaffected. Native boundary Camera, microphone, location and device-picker requests from panel pages are denied — Electron grants them by default when no handler is set, and the panel loads whatever address the user types. Page capture, appearance emulation and storage clearing verify that their target belongs to the panel's own session instead of trusting a web-contents id from the renderer. Persisted state Stored `preview` tabs migrate to `browser` (v13 -> v14). Context panel tab limits are now per surface, so filling one surface no longer evicts another's tabs. Address history is stored per project and per runtime. Documentation `preview.mdx` and `desktop-browser.mdx` rewritten across all locales, the agent tool settings path corrected, new `DOCUMENTATION.md` for the browser-control broker and the dev tunnel, and the `ui-api-decoupling` skill updated where it still described the deleted proxy.
64 lines
3.8 KiB
Plaintext
64 lines
3.8 KiB
Plaintext
---
|
|
title: Browser Panel
|
|
description: Browse any page inside the app, annotate it, and let the agent drive it.
|
|
---
|
|
|
|
# Browser Panel
|
|
|
|
The browser panel opens any page right next to your chat. Open it from the globe button in the app header.
|
|
|
|
On the desktop app it is a real browser: your logins persist, hot reload works, and developer tools are one click away. In a web browser tab the panel can still display a page, but it cannot look inside one — the annotation tools below are desktop-only. The VS Code extension has no browser panel at all: VS Code is already an editor with a browser beside it, and everything that makes this panel worth having needs the desktop app.
|
|
|
|
Pages opened here cannot use your camera, microphone, or location: those requests are refused.
|
|
|
|
## The toolbar
|
|
|
|
The address bar remembers pages you have opened in this project and offers them as you type, matching part of an address or a page title. Arrow keys move through the list, Enter opens the highlighted entry, and the button on a row removes it.
|
|
|
|
**Reload** is next to it, along with a **hard reload** that ignores the cache when a change refuses to show up, and zoom controls that scale the page only.
|
|
|
|
**Clear cookies** and **Clear cached data** apply to this panel alone. Your OpenChamber session and any other window are untouched.
|
|
|
|
## Annotate a page
|
|
|
|
Press **Annotate** and a toolbar appears over the page with three tools:
|
|
|
|
- **Element** — click an element. Clicking another moves the selection; clicking the same one again clears it.
|
|
- **Region** — drag a box around an area, when what you mean covers more than one element.
|
|
- **Draw** — sketch freehand over the page.
|
|
|
|
Write what you want in the box that appears beside your mark, and press **Attach** — or just press Enter. Your chat message gets a card with everything you marked, your note, and a screenshot of the visible page with your marks drawn on it — so you can say "this button, a bit rounder" instead of describing where it is.
|
|
|
|
The page itself is never modified — annotating marks what is there. `Esc` cancels and closes the toolbar.
|
|
|
|
## Let the agent drive
|
|
|
|
The agent can use the browser panel itself — opening a page, reading what is on it, clicking, typing, scrolling, and switching between mobile, tablet and desktop layouts — so it can check its own work instead of asking you to. You will see it happening in the panel.
|
|
|
|
The agent cannot run arbitrary code in the page. The browser keeps your real logins, so it is limited to the specific actions above.
|
|
|
|
It can also save a picture of what it is looking at into `.openchamber/screenshots/` in your project and show it to you in its reply. That is what makes a before-and-after possible, and the file stays there afterwards to attach to a pull request.
|
|
|
|
The browser actions are the **OpenChamber Web tool**, which can be turned on and off on its own in **Settings → General → OpenChamber Tools**.
|
|
|
|
This needs the desktop app: a page shown in a web browser tab cannot be driven.
|
|
|
|
## Size and appearance
|
|
|
|
Press the phone button to open the device bar. Pick a preset or type a width and
|
|
height, and the page is laid out at that size — scaled down to fit the panel
|
|
when it is bigger, but still measuring itself at the size you asked for.
|
|
|
|
The same bar forces the page to light or dark, so a theme can be checked without
|
|
changing anything on your machine. It leaves DevTools alone; a page can only
|
|
have one debugger attached, so close DevTools first if it is open.
|
|
|
|
## Developer tools
|
|
|
|
Press the terminal button in the toolbar to open Chromium's own developer tools for the page — console, network, elements, everything you would expect.
|
|
|
|
## Related
|
|
|
|
- [Preview & Dev Servers](/preview/) — opening your running app, including on a remote machine
|
|
- [Agent Control Tool](/agent-control-tool/) — sessions, worktrees and scheduled tasks from chat
|