integrated-browser

Solid

Use this when working on the VS Code integrated browser ("browserView") to understand its architecture and mental model. Covers the embedded Chromium browser, its editor tab, navigation, overlay/layout, sessions, and agent browser tools under `src/vs/platform/browserView` and `src/vs/workbench/contrib/browserView`.

Web & Frontend 25 stars 0 forks Updated 5 days ago MIT

Install

View on GitHub

Quality Score: 82/100

Stars 20%
47
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Integrated Browser Architecture The integrated browser ("browserView") embeds a **real Chromium browser** in VS Code, backed by an Electron `WebContentsView`. It renders live pages, presents each as an editor tab, and lets agents drive those pages through tools. It powers the in-product browser tab and the agent "browser" tools. It is **not** the old `extensions/simple-browser` (an iframe-in-a-webview), which now delegates to this on desktop. It's a heavyweight, security-sensitive, multi-process primitive, and **almost every design decision follows from that.** This file describes the load-bearing ideas that rarely change. It deliberately does **not** enumerate current features/tools/commands/settings — those churn; the live `features/` and `tools/` folders are the source of truth. Build the mental model here, then go read the specific code you're changing. ## The one idea everything follows from **A page is a native `WebContentsView` that only the main process may create, own, and position. Nothing else can touch it directly.** It's owned by the main process and painted by the OS compositor *on top of* the workbench DOM — not inside it. Everything else works around this: - The **renderer** (editor UI + agent tools) can't hold the page; it holds a model/proxy and talks to main over IPC. - **Playwright** is heavy and long-lived, so it runs in the **shared process**, reaching the page over IPC too. - The page **paints over the DOM**, so the workbench choreographs alignme...

Details

Author
chapmanjw
Repository
chapmanjw/clawdius
Created
2 months ago
Last Updated
5 days ago
Language
TypeScript
License
MIT

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

Web & Frontend Listed

browser

Verify or measure the webview in a real browser. Use when the user says /browser, after any change to webview/src, or whenever a UI claim needs evidence — layout, spacing, colour, contrast, animation timing, or "does this actually render".

0 Updated 3 weeks ago
oldmilky
Web & Frontend Listed

browser

Drive a real browser to test a running app — navigate, read the page, click and fill, screenshot, and read console errors. Use for UI verification, form and login flows, and post-deploy checks.

3 Updated today
djnsty23
Web & Frontend Listed

workbench-builder

Builds disposable localhost workbenches — Bun.serve + bun:sqlite + React 19 + Astryx apps, zero build config, no deploy — giving an agentic coding/eval/PR/data session a live UI. The signature move is a two-way human↔agent loop over one SQLite file: the human acts in the browser, the agent acts from the terminal (bun run scripts), both seeing the same state update live via SSE with no reload. Ships recipes for eval viewers, PR review rooms, document redline surfaces, spreadsheet/grid editors, multi-surface triage queues, trace replays, and more. Use when the user wants a quick local UI for a coding/eval/PR/data task, OR mentions localhost workbench, eval viewer, PR review room, review/redline a document, select text and comment, a spreadsheet or editable grid, triage my inbox, live invalidation, two-way agent loop, or "build me a little UI for this." Do NOT use for production apps or deployed SPAs (use frontend-design), or for static data pages / HTML reports where a self-contained file is the right tool.

5 Updated 1 months ago
theagenticguy