playwright-rs-usage

Using playwright-rs

Rust bindings for Microsoft Playwright. This crate is a thin JSON-RPC client to the upstream Playwright server, so the API mirrors playwright-python / java / .NET semantics. When unsure about a method's behavior, the upstream Playwright docs are the authoritative reference.

Drift discipline. The canonical API tour lives in the crate-level rustdoc at https://docs.rs/playwright-rs — that's compile-checked against the actual code. This skill is the "what to reach for, what to avoid" overlay: durable conventions, not a method-by-method reference. Two build gates hold it to the crate: the Rust code block below is compiled against the real API, and every cargo feature and browser engine the crate exposes must be named somewhere in this file, so a capability cannot ship here undocumented.

Neither gate checks that this prose is accurate. That residue is real. The text is written in concepts (auto-wait, builder pattern) rather than specific method names so it ages slowly, but when it and the crate disagree, the crate wins: check https://docs.rs/playwright-rs for the version you actually have.

Before any of this works

Two things, and the second one is the one that surprises people.

The crate. playwright-rs in [dependencies], or [dev-dependencies] if it is test-only, alongside tokio with the full feature. Defaults are native-tls, macros and ring: transport, the locator!() macro, and the crypto backend respectively.

Prefer leaving them on. default-features = false is only needed to swap ring for aws-lc, and it drops all three, so the replacements have to be listed back explicitly or locator!() disappears and no TLS transport remains:

playwright-rs = { version = "0.17", default-features = false, features = [
    "aws-lc",
    "native-tls",
    "macros",
] }

Two capabilities are opt-in and off unless asked for. screenshot-diff turns on pixel-diff screenshot assertions, so reach for it when the task calls for comparing a rendering against a baseline rather than asserting on the DOM. cli builds an installer binary for use outside a Cargo project; inside one, prefer the example below, because cargo install compiles a second copy of the crate that then has to be kept in sync with the project's lockfile.