Planning: playwright-rs-trace-viewer-wasm crate (browser-hosted trace UI)

[padamson]

Planning issue for a browser-hosted Playwright trace viewer built in Rust + WASM, consuming the `playwright-rs-trace` parser (#80). Targets v0.14.0-era work; not scheduled.

What this is

A Rust crate that compiles to WASM, ships as a bundled HTML/JS/WASM artifact, and lets a user drag-drop a Playwright trace zip into a browser tab and explore it — same UX as `npx playwright show-trace`, but:

• No Node dependency
• Embeddable anywhere (CI bots posting trace links, internal dashboards, the `playwright-rust` GitHub Pages site Planning: GitHub Pages landing page (Rust-based, dogfoods playwright-rs) #78)
• Pure-Rust stack from parser through render — `playwright-rs-trace` (Planning: playwright-rs-trace crate (programmatic Playwright trace parsing) #80) compiled to WASM, plus a UI framework (`leptos` / `yew` / `dioxus`)

Why this is a strategic move

Without `@playwright/trace-viewer` running, the only existing way to inspect a Playwright trace is to install Node and run the JS viewer. That's a distribution friction. Shipping a static-asset bundle (a single `index.html` + `.wasm` blob) means:

• CI tooling can host it on a pull-request comment URL
• Internal company dashboards can embed it without a Node runtime
• Our GitHub Pages landing page (Planning: GitHub Pages landing page (Rust-based, dogfoods playwright-rs) #78) gets a flagship interactive demo

The strategic moat is that `playwright-rs-trace` (#80) is the only programmatic trace parser anywhere; the WASM viewer is the canonical UI for it.

Where it lives

Workspace member: `crates/playwright-rs-trace-viewer-wasm/`. Independent versioning. Distributes as:

• A crate on crates.io (for downstream embedders that want to bundle it themselves)
• A static-asset GitHub Release artifact (for users who just want `viewer.zip` to drop in S3)
• The viewer hosted on the `playwright-rust` GitHub Pages site (Planning: GitHub Pages landing page (Rust-based, dogfoods playwright-rs) #78), as the showcase deployment

Surface to scope

• Drag-drop zip ingestion (no server side)
• Action timeline scrub
• Per-action detail panel: selector, params, before/after snapshot, network entries, log
• Filter / search by action kind or selector substring
• Per-action screenshot if the trace has one
• Stretch: side-by-side DOM-snapshot diff viewer

Coupling

• Depends on `playwright-rs-trace` (Planning: playwright-rs-trace crate (programmatic Playwright trace parsing) #80). That crate must be `no_std`-friendly or at least `std + WASM` compatible (no spawning Node processes — pure parsing).
• Independent of the main `playwright-rs` crate.
• Independent of the landing page (Planning: GitHub Pages landing page (Rust-based, dogfoods playwright-rs) #78) — landing page is one host, not the only host.

Out of scope

• Live trace streaming (would require a server component; not what this is)
• Trace recording (the main `playwright-rs` crate already does that)
• Trace editing (read-only viewer)

Next step

Land #80 first. Once the parser is stable, scope this with: UI framework choice, deployment artifact spec (single static bundle with no external CDN), and a list of trace features the viewer must surface (vs. defer).