skip to content

Runtime Startup

3 roadmaps11 questions

Which browser build a run actually uses, where it came from, and the options handed over when you launch one or attach to one already running. Asked because "works on my Chrome" starts here.

on this pageshow

explore

questions

11

Why does Playwright download its own Chromium, Firefox and WebKit builds instead of driving your installed browsers?

level: juniorimportance: must knowfreq 78%

answer

  1. Same browser on every machine
  2. Builds pinned to the package version
  3. Patched engines, not the branded product
  4. WebKit is not Safari
  5. Cache folder called ms-playwright

basics

~20 s

Playwright pins a patched build of each engine to its own release, so every machine runs an identical browser. Its WebKit is built from WebKit sources rather than Safari, and its Chromium is not the Chrome you have installed.

solid answer

~40 s

Each Playwright release pins a specific revision of Chromium, Firefox and WebKit, and `npx playwright install` downloads those builds into an `ms-playwright` cache folder. The builds carry Playwright's own patches, which is what makes the automation protocol work identically across all three engines, and pinning them to the package version means a failure reproduces on any machine rather than depending on whose browser was installed. Two identities follow from this: Playwright's WebKit is built from recent WebKit sources and cannot drive branded Safari at all, and its Chromium is a separate download that never auto-updates and ignores the enterprise policies your corporate Chrome obeys. The cost is an extra install step after every upgrade, and a few hundred megabytes per engine on disk.

code

bash · 4 lines
bash
npx playwright install
npx playwright install chromium
npx playwright install --list
npx playwright install --dry-run

go deeper

for a junior

Recall that Playwright ships its own Chromium, Firefox and WebKit, that a separate install command downloads them, and that those builds are not the branded browsers on your machine.

for a middle

Explain the pinning: each release names an engine revision, the builds land in revision-stamped folders in an ms-playwright cache, and an upgrade changes the revision the runtime expects.

for a senior

Show that you use the property. Identical engines across machines is what makes a failure attributable to code, and it is why an environment problem looks suite-wide and instant rather than flaky.

for a principal

Own the tradeoff between a pinned engine estate and the shipping product: determinism and lead time against fidelity, and who decides when the engine version moves.

## What a "bundled engine" is Playwright does not automate the Chrome, Firefox or Safari already installed on your machine. Every Playwright release **pins a specific build** of three engines — Chromium, Firefox and WebKit — and `npx playwright install` downloads those builds onto the machine. The `playwright-core` package carries a `browsers.json` manifest naming a **revision** per engine, and at run time the library resolves a folder such as `chromium-1244` inside a cache directory. Bump the npm package and the expected revision moves with it, which is why an upgrade is normally followed by another `npx playwright install`. ## Why ship builds rather than drive what is installed - **Reproducibility.** Every developer and every machine runs the *same* engine binary, so a failure in the hotel-booking search results is a property of the code, not of whose laptop ran it. - **Patched engines.** The builds carry Playwright's own patches, which is what makes the automation protocol, the inspector and features such as tracing work uniformly across all three. - **Lead time.** The bundled builds run ahead of the browsers the public is on, so a change that will break the room-detail page surfaces weeks before users meet it. - **No install lottery.** Nothing on the machine has to be present, at a version, or on a `PATH`. ## The two identities people get wrong **Playwright's WebKit is not Safari.** It is built from recent WebKit sources with Playwright's patches applied, so it typically runs ahead of what Apple has shipped. Playwright cannot drive branded Safari at all, because the automation depends on those patches. WebKit is a good proxy for Safari's rendering and JavaScript behaviour, not a substitute for it — and platform-dependent behaviour such as media codec support differs between WebKit on Linux and WebKit on macOS, so the closest-to-Safari signal comes from running it on a Mac. **Playwright's Chromium is not your Chrome.** It is a separate download that never auto-updates, is untouched by the enterprise policies, extensions and proxy rules your corporate Chrome obeys, and sits at a different version. Since Playwright 1.57 the bundled Chromium is a *Chrome for Testing* build (headed mode runs `chrome`, headless runs `chrome-headless-shell`); on Arm64 Linux it remains a Chromium build. If you want the shipping product instead, that is the branded channel story, a deliberate opt-in — not the default. ## Where the builds land Downloads go into an OS-specific cache folder named `ms-playwright`, and each engine occupies a few hundred megabytes: | Platform | Default location | |---|---| | Linux | `~/.cache/ms-playwright` | | macOS | `~/Library/Caches/ms-playwright` | | Windows | `%USERPROFILE%\AppData\Local\ms-playwright` | Playwright tracks which installations still reference each build and deletes versions no client needs any more, so upgrading repeatedly does not silently fill the disk. ## What the model costs you 1. **An extra install step.** Adding the package is not enough; the engines are fetched by a separate command, and forgetting it produces `Executable doesn't exist at ...`, whose own message tells you to run `npx playwright install`. 2. **Disk and download time.** Three engines plus the headless shell are large. You can narrow this by naming engines — `npx playwright install chromium` — or by installing only the headless shell with `--only-shell` when nothing runs headed. 3. **A second thing to keep in step.** The package version and the on-disk builds must agree, which makes the install a normal part of the dependency-install routine rather than a one-off. ## Checking what you actually have `npx playwright install --list` prints the builds present across all Playwright installations on the machine, and `npx playwright install --dry-run` reports what the current version *would* download without touching anything. Both are the quickest way to answer "which engine did that run really use?" before you start blaming the hotel-booking application itself.

  • If the engines are pinned to the release, what has to happen when you upgrade the Playwright package?
    The expected engine revision moves with the package, so `npx playwright install` has to run again. Skip it and the first launch throws `Executable doesn't exist at ...`, naming the path it looked for and the command that fixes it. Tying the install to the dependency-install step is the durable answer.
  • Does running tests in Playwright's WebKit tell you your site works in Safari?
    Only approximately. WebKit is built from recent WebKit sources with Playwright's patches, so it usually runs ahead of shipped Safari, and platform-dependent behaviour such as media codec support differs by operating system. It is a strong proxy for rendering and JavaScript behaviour, not proof about a specific Safari release.

It is the difference between shipping a toolchain with your project and trusting whatever compiler happens to be on the box.

saying these in an interview costs you the question

  • Says Playwright automates the Chrome installed on the machine
  • Calls Playwright's WebKit Safari
  • Thinks installing the npm package downloads the engines automatically
  • Believes the bundled Chromium auto-updates like a real browser
  • Assumes Playwright can drive branded Safari directly
open as a page

In Playwright, what does the headless option on browserType.launch() control, and what is its default?

level: juniorimportance: must knowfreq 76%

basics

~20 s

Playwright's headless launch option decides whether the browser draws a visible window. It defaults to true, so launch() starts an invisible browser; passing headless: false opens a real window you can watch a failing flow in.

open as a page

What does the --with-deps flag add to npx playwright install on a fresh Linux machine?

level: middleimportance: must knowfreq 61%

basics

~10 s

It installs the operating-system shared libraries the engine binaries link against, on top of downloading the engines themselves. On Linux it runs the system package manager as root; on macOS it is unnecessary.

open as a page

Your Playwright suite suddenly fails with "Executable doesn't exist at .../chromium-1244/..." after a dependency update. What happened?

level: seniorimportance: must knowfreq 53%

basics

~20 s

The Playwright package moved to a version that expects a newer engine revision, and nobody re-ran the download. Engine builds live in revision-stamped folders, so the runtime looked for a build that was never installed.

open as a page

In Playwright, what does setting PLAYWRIGHT_BROWSERS_PATH change about where engine builds live?

level: middleimportance: should knowfreq 44%

basics

~20 s

It moves the directory Playwright installs engine builds into and reads them from. An absolute path selects that directory; the value 0 puts the builds inside the installed package itself, giving the project its own private copy.

open as a page

What does Playwright's chromium.launchPersistentContext(userDataDir) buy you, and what does it cost?

level: middleimportance: should knowfreq 37%

basics

~10 s

It launches a browser against a profile directory on disk and returns the single BrowserContext that owns it. You gain state that survives runs plus Chromium extensions; you lose fresh isolation and independent contexts.

open as a page

What does Playwright's slowMo launch option do, and why does it not make a flaky test reliable?

level: middleimportance: should knowfreq 44%

basics

~10 s

slowMo is a launch option that pauses Playwright by the given number of milliseconds between operations so a human can follow the run. It hides races behind extra delay; it never removes them.

open as a page

When would you attach with browserType.connect rather than browserType.connectOverCDP?

level: seniorimportance: should knowfreq 38%

basics

~20 s

Use browserType.connect whenever the far side is a Playwright browser server: it speaks Playwright's own protocol, works for all three engines, and keeps full fidelity. connectOverCDP is the Chromium-only, lower-fidelity way to attach to a browser someone else started.

open as a page

Your Playwright suite must reach a staging hotel-booking site only through an authenticated HTTP proxy. How do you configure that?

level: seniorimportance: should knowfreq 31%

basics

~20 s

Pass a proxy object to browserType.launch(): server, plus optional username, password and a comma-separated bypass list. Set at launch it covers every context that browser creates, and the credentials should come from environment variables, not source.

open as a page

How would you weigh Playwright's bundled Chromium against a branded chrome or msedge channel for a booking suite?

level: principalimportance: should knowfreq 33%

basics

~20 s

Default to the bundled build: it is pinned to the Playwright version, reproducible everywhere and runs ahead of the stable browsers. Reach for a branded channel only where fidelity to the shipping product matters, and accept that it auto-updates.

open as a page

When is passing custom args or an executablePath to Playwright's launch justified, and what do you take on by doing it?

level: principalimportance: nice to knowfreq 24%

basics

~20 s

Rarely, and only for a capability no supported option provides. Playwright computes a default argument set and supports the browsers it ships; every custom flag or foreign binary is a divergence your team owns, debugs and revisits at each upgrade.

open as a page