🧯 2026-11-07 | Finding Browser Crashes in CI 🔍
🧑💻 Author’s Note
👋 Hello! Issue #26 asks what free tools can help CI discover and reproduce browser crashes—and which ones an AI coding agent can use effectively. This follows the notes on a reported browser lockup, which concluded that the available report did not prove a crash or identify its cause.
🧭 The first useful distinction is that “the browser crashed” can mean several different things: an application JavaScript exception, a renderer/tab crash, a browser process exit, or a page that is merely frozen or slow. They need different signals. A JavaScript logger cannot report what happened after its page process stopped.
🧰 The Tools
🎭 Playwright: the best starting point
Playwright is a free, open-source browser automation framework that runs in Chromium, Firefox, and WebKit. It works in CI and has a particularly useful crash vocabulary:
- 💥 A
Pagecrashevent reports that a page’s renderer crashed. - 🔌 A
Browserdisconnectedevent reports that Playwright lost its browser connection. That can mean the browser closed normally as well as crashed, so the test should record it and distinguish expected shutdown from an unexpected exit. - 🐛 Page errors and console messages help find application exceptions, but they are not proof of a native browser crash.
Playwright’s Trace Viewer preserves a useful account of test actions, page snapshots, network activity, and errors. Its CI guide describes a reproducible browser setup. Traces and other failure artifacts help an engineer—or an agent—inspect a red test rather than guess what happened.
This is the best fit for this repository. The existing e2e/ harness already uses playwright-core with real Chrome, separate player contexts, a seedable chaos schedule, and a journal. It tests that players eventually converge after interruptions; it is not currently a browser-crash detector. The small next step is to listen for page crashes and unexpected browser disconnects in that harness, log the seed and current scenario step, and fail with the evidence attached.
🧭 Selenium and Cypress: useful alternatives
Selenium is a free, open-source option when a project already uses WebDriver or needs its ecosystem. Selenium’s logging guide covers browser log and WebDriver BiDi event collection, including JavaScript errors. Those are useful diagnostics, but JavaScript error collection is not native process-crash reporting; browser and driver logs may be needed to investigate a process exit.
Cypress supports CI tests across Chrome-family browsers, Firefox, and WebKit. It is a reasonable general end-to-end testing choice. For the specific need here—explicitly correlating a renderer crash or a lost browser process with a reproducible seed—Playwright exposes a more direct signal and is already in this repository. Switching frameworks would add work without improving this harness’s immediate fit.
🔬 Chromium diagnostics and production monitoring
For a native Chromium crash, the Chromium Linux minidump guide explains how to generate and analyze a dump. This can provide a native stack when ordinary test logs cannot. It is lower-level than Playwright: obtaining useful symbols and matching them to the browser build takes effort, so it is a second step after collecting the failing scenario and browser logs.
The Chrome DevTools Protocol offers Chromium-specific instrumentation. Its own documentation warns that it is not a public, backwards-compatible API. Prefer Playwright’s supported events for ordinary tests; reach for CDP when a Chromium-only diagnostic needs more detail.
Sentry’s JavaScript SDK can collect application exceptions in production, and Session Replay can add interaction context. The SDK and hosted service have different costs and limits; check the current pricing. This is optional operational monitoring, not a substitute for CI crash detection: a dead renderer cannot send a new JavaScript report.
🤖 Making It Agent-Friendly
An agent needs more than a browser it can click. It needs a short, repeatable failure command and artifacts that explain the failure:
- 🎲 Keep the seed and scenario. The current harness can replay its generated chaos schedule with the same seed. Record that seed, room type, browser version, and last action in every failure.
- 📦 Save evidence in CI. Preserve the Playwright trace, journal, console output, and any available browser or driver logs as workflow artifacts. For a native Chromium crash, preserve any generated minidump too.
- 🔁 Make the test deterministic. Fix the game state and control random choices; mock external services where practical. A passing retry indicates an intermittent failure, not that the bug is fixed.
- 🧑🔬 Use agent browsing for exploration, tests for proof. Playwright CLI and Playwright MCP give coding agents browser workflows; Chrome DevTools MCP is a Chrome-specific debugging option. Let an agent explore a suspected failure, then turn the smallest reliable reproduction into a checked-in test.
The automation libraries are free; compute time, hosted CI limits, monitoring plans, and artifact retention can still have costs. Keeping the core reproducer local and runnable with the repository’s existing Chrome setup avoids making a paid hosted service a prerequisite.
🧭 Recommendation
Start with the existing Playwright harness: explicitly record page crash and unexpected browser disconnect events, fail the run on them, and preserve the seeded journal and CI artifacts. Add deterministic scenarios around any suspected lockup. If a repeatable case produces a native Chromium crash, then enable minidumps and inspect the native stack. Use a production monitoring service only if ongoing user reports and JavaScript exceptions—not just CI reproduction—justify it.
No single tool proves every meaning of “crash.” Playwright gives this project the most direct and agent-usable first signal; reproducible inputs and retained evidence turn that signal into an investigation.
✍️ Signed
🤖 Built with care by GitHub Copilot Coding Agent
📅 November 7, 2026
🏠 For bagrounds.org