Which browser targets does Playwright leave uncovered when you weigh it against an existing browser grid?
answer
- Three engines arrive in the box
- Branded builds come through a channel
- One engine family is simply absent
- Engine versions ride the release pin
- Emulation is not a real handset
basics
~20 sPlaywright 1.63 ships Chromium, Firefox and WebKit, and drives locally installed Chrome or Edge through channels. It cannot drive Internet Explorer, arbitrary historical engine builds, or real phones, so those targets still need a grid or a device cloud.
solid answer
~40 sA Playwright install downloads three engines -- Chromium, Firefox and WebKit -- pinned to the Playwright release, and a project can set `channel: 'chrome'` or `channel: 'msedge'` to drive a branded build already installed on the runner. That covers the mainstream matrix with no infrastructure. What it does not cover: Internet Explorer, at all; one specific historical engine build, because bundled versions move with the Playwright version you pin; the shipping Safari application, since WebKit here is Playwright's own build of the engine; and real handsets, because `devices['Pixel 5']` emulates viewport, user agent and touch rather than running Android. So in Playwright 1.63 the evaluation is a set-difference: list the targets the business requires, subtract those, and price whatever is left as the grid or device cloud you keep.
code
typescript · 10 linesimport { defineConfig, devices } from '@playwright/test';
export default defineConfig({
projects: [
{ name: 'chromium', use: { ...devices['Desktop Chrome'] } },
{ name: 'firefox', use: { ...devices['Desktop Firefox'] } },
{ name: 'webkit', use: { ...devices['Desktop Safari'] } },
{ name: 'edge', use: { ...devices['Desktop Edge'], channel: 'msedge' } },
],
});go deeper
Remember what an install actually fetches: Chromium, Firefox and WebKit, selected per project. Chromium is not the same thing as branded Chrome.
Explain the mechanics: bundled builds are pinned to the Playwright release, the channel option points at a branded browser already installed on the machine, and device descriptors emulate rather than run a real handset.
Show the evaluation as a set-difference against a written target list, and be ready to say which residue still needs a grid, a device cloud or a manual check, and what that residue costs.
Own the consequence for infrastructure: if the bundled matrix covers most targets, argue for shrinking the fleet rather than keeping or scrapping it wholesale, and name who pays for the leftovers.
## What a Playwright install actually gives you Running `npx playwright install` downloads three browser builds and pins them to the Playwright version in your `package.json`: Chromium, Playwright's own build of Firefox, and Playwright's own build of WebKit. A project picks one with `browserName`, or by spreading a `devices` entry such as `devices['Desktop Safari']`. Nothing is rented and nothing is shared -- every engineer and every CI runner resolves the same three engines. In Playwright 1.63 that is the whole default matrix, and it is the part of the coverage argument that needs no infrastructure at all. ## Branded builds arrive through a channel, not a download Chromium is not Chrome. When the requirement is the shipping branded browser -- proprietary media codecs, or a compliance document that names the product by name -- a project sets `channel`: - `channel: 'chrome'` and `channel: 'msedge'` drive the stable branded build already installed on the machine. - Beta and dev variants of those channels exist for early-warning runs against the next release. - The browser must already be installed on every runner: a channel is a pointer, not a download. ## The gaps, in the order they usually bite | Target | Playwright 1.63 | What still covers it | |---|---|---| | Chrome, Edge and the Chromium family | bundled Chromium, or a `channel` | nothing else needed | | Firefox | bundled build | nothing else needed | | Safari's engine | bundled WebKit, not the Safari application | a macOS machine for the shipping browser | | Internet Explorer | not supported at any version | another tool, or retire the screen | | One specific historical engine build | only by pinning an older Playwright | a grid that still keeps that image | | Real iOS and Android handsets | emulation only | a device cloud | Four of those deserve spelling out: - **Internet Explorer is absent.** There is no channel, no flag and no compatibility mode. A legacy insurance-quote screen that only renders in IE stays wherever it runs today. - **Engine versions move with the release.** You choose browser versions by choosing a Playwright version. You cannot pin one old Firefox and one new Chromium against each other. - **WebKit is the engine, not the application.** It is close enough to catch the Safari-family layout and API differences that break a quote form, but it is not the binary a customer launches, and it does not carry everything the shipping product ships. - **Device descriptors emulate.** `devices['Pixel 5']` sets viewport, user agent, device scale factor and touch support; the page still runs in a desktop-class bundled engine on your runner. ## Turning coverage into an adoption decision 1. Write down the browser targets the business actually requires -- from analytics, from the support contract, from the accessibility statement -- not the targets the current grid happens to have. 2. Subtract everything the three bundled engines plus `channel` already cover. 3. Price whatever is left: a thin grid, a device cloud, or a documented manual check. 4. Compare that residue against the cost of the grid you run today. Adoption rarely has to be all-or-nothing. ## What this does to the grid argument - If the residue is one legacy engine on one screen, keep a small dedicated lane for it and move the rest; a shrunken grid is still a win. - If the residue is real handsets, that was never a runner choice in the first place -- no test runner turns emulation into a device. - If nothing is left over, the grid's remaining value is concurrency and operating-system spread, which is a throughput argument rather than a coverage one, and has to be argued separately. ## The misread to avoid Teams evaluate "cross-browser support" as a yes/no feature and then discover the mismatch a quarter later, usually on the one legacy screen nobody demoed. Coverage is a set-difference exercise against a written target list, and the answer to "which targets does Playwright leave uncovered?" is specific and short -- which is exactly why it should be settled on day one of the evaluation rather than after the first fifty tests are ported.
- If one legacy quote screen only renders in Internet Explorer, does that rule Playwright out for the whole suite?No. Playwright cannot drive Internet Explorer at any version, but that is one screen, not the suite. Move everything the bundled engines cover, and keep a thin dedicated lane -- or a documented manual check -- for the legacy screen. A shrunken grid is still a real saving.
- How do you pick which browser version the suite runs against?By pinning Playwright: the bundled Chromium, Firefox and WebKit builds advance with each release, so the Playwright version in `package.json` is the browser-version decision. For branded builds, `channel` points at whatever Chrome or Edge is installed on the runner, including beta and dev variants for early warning.
saying these in an interview costs you the question
- Assuming Playwright's WebKit is the Safari binary customers launch
- Thinking Internet Explorer works through some compatibility flag
- Believing device descriptors prove the site works on real phones
- Expecting to pin each engine's version independently of Playwright
- Treating cross-browser support as a yes or no feature
- Assuming a channel downloads the branded browser for you