Which Browsers Actually Earn a Test Run

This post is part of the Playwright Essentials series. If you missed the previous post, read Part 11 — Network Control in Playwright first.

---

Introduction — Three Browsers, Three Bills

Playwright can run Chromium, Firefox, and WebKit in one config. That line in the config is not a decision. A decision is which project gates a merge, and which project exists because a user on Safari hit a bug you could not see in Chrome.

Chromium Gates the Pull Request

Most of your users, and all of your debugging, will happen in Chromium. The pull-request bucket from the CI series runs here. Traces, screenshots, and the inspector match the browser you have open.

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox', use: { ...devices['Desktop Firefox'] }, grep: /@firefox/ },
    { name: 'webkit', use: { ...devices['Desktop Safari'] }, grep: /@webkit/ },
  ],
});

The grep is the point. Firefox and WebKit do not inherit the whole suite.

When Another Engine Earns a Tag

Add @webkit when you have a bug, or a control, that Safari handles differently and your users actually use:

• date and file inputs
• position: sticky inside a scroll container you depend on
• a permission prompt, which part 13 covers
• a payment or login widget that ships a Safari-specific build

Add @firefox for the same reason, not for symmetry. If you have no Firefox defects and no Firefox traffic, you do not owe Firefox a job.

Mobile device emulation is a viewport and a user agent until you have a touch bug. A separate phone project for the whole suite doubles the bill and finds little.

Nightly, Not Never

The tagged tests can run on a schedule even when they do not gate a pull request. A WebKit failure on Monday that nobody sees until release is the failure mode of “we will add Safari later.”

- name: WebKit slice
  run: npx playwright test --project=webkit
  if: github.event_name == 'schedule'

Keep the slice small enough that a red nightly is still readable.

Do Not Debug Three Reports at Once

A failure that exists only in WebKit gets a WebKit trace. A failure that exists in all three is a product bug. Fix it in Chromium, then rerun the tagged projects. Staring at three HTML reports of the same missing button wastes the afternoon the extra browsers were supposed to save.

Conclusion

Chromium protects the merge. Other engines protect the defects you have evidence for. Tag those tests, run them on a schedule, and resist the config that runs everything everywhere.

Action for this week: Open the last quarter of browser-specific bugs. Tag one regression for each engine that actually appeared. Remove any project that has no tag and no traffic.

---

Next in the series: Part 13 — Browser Permissions Users Refuse.