2.5 Cross-Browser & Mobile Viewport Execution

How to execute tests across Chromium, Firefox, WebKit, and mobile viewport emulations.

One Test, Every Engine It Actually Needs to Work On

A test that only ever runs in Chromium tells you the feature works in Chromium – nothing about how it behaves for the share of real users on Safari or Firefox. WebKit and Gecko diverge from Chromium in ways that show up in production: a date picker that renders fine in one engine can misbehave in another, a flexbox edge case, a form-autofill quirk. A mobile viewport surfaces its own class of bug entirely – elements that overlap cleanly at 375px wide never do on a 1440px desktop screen. CertiQA ships Playwright’s own browser engines embedded, so the same authored case runs unmodified against whichever engine and viewport you choose, with no second “mobile version” of the test to maintain.

Choosing an Engine and Viewport

Target	Engine / Emulation	Good For
Chromium	Real Chromium engine	The default target – matches the majority of real-world Chrome and Edge users.
Firefox	Real Gecko engine	Catching layout and JS-engine differences Chromium alone won’t surface.
WebKit	Real WebKit engine	The closest available proxy for Safari/iOS behavior without a physical Mac or device.
Device presets	Chromium or WebKit emulating a phone or tablet, chosen with the project Default Device Preset setting	Responsive layout and touch-interaction bugs a desktop viewport cannot reveal.

Running a Suite Across a Matrix

• 1. Open the Run Suite modal for the suite you want to execute.
• 2. Choose the browser in the run panel (Chromium, Firefox or WebKit). To cover several browsers, run the suite once per browser; the report keeps each run separate.
• 3. Click Run – the report groups results by target, so a failure that only shows up on WebKit or at mobile width appears as its own row instead of being hidden inside an otherwise-green Chromium run.

Reading a Mixed-Result Matrix

• A case that passes on Chromium and fails on WebKit isn’t automatically a WebKit bug – it’s just as often a selector or timing assumption the test happened to only violate under WebKit’s slightly different rendering and event timing.
• Running every suite on every browser on every commit adds real execution time; many teams keep per-commit runs to Chromium alone and reserve the other browsers for nightly or pre-release runs.