"Broken in Safari" tickets die in triage because nobody has the device, the repro steps are vague, and the difference could be an engine bug, a missing feature, a prefix, or your own code's assumption. An agent that drives real browser engines can reproduce the report, bisect the cause to a class, and hand you a minimal repro plus a guarded fix.
Tier: Foundation · Workflow area: Performance & debugging
This playbook turns cross-browser tickets from "works on my machine" stalemates into classified, minimally-reproduced, properly-guarded fixes.
:has(), popover, container queries, View Transitions) and need to know the degradation story.Skip it for bugs reproducible in every browser — that is ordinary debugging; the value here is isolating difference.
Reproduce across the matrix before theorizing. Have the agent script the reported steps and run them under all three engines, capturing screenshots and console/page errors per engine:
Write a Playwright script (not a test yet) that: opens /checkout,
selects "monthly", opens the country dropdown, screenshots it, and
dumps console messages and any page errors. Run it under chromium,
webkit, and firefox projects and give me a per-engine comparison table.
Outcome A: reproduces only in one engine — proceed. Outcome B: reproduces everywhere — ordinary bug, exit this playbook. Outcome C: reproduces nowhere — the difference is environmental (device, version, extension, network); refine the matrix (viewport, touch emulation, older engine version, reduced motion, locale) before giving up.
Bisect to a cause class. The agent strips the page down — commenting out CSS, isolating the component, stubbing data — until the difference is minimal. Classify what remains:
100vh on iOS). The fix is a workaround your code owns, plus possibly an upstream report.-webkit- or alternate syntax; usually an autoprefixer/build config gap.Make the agent commit to a class and cite the evidence: which minimal change makes the difference appear and disappear.
Verify the claim against reality, not the model's memory. Models' support tables are stale and confidently wrong about recent engine versions. Confirm the classification: the minimal repro (an HTML file or CodePen-sized snippet) behaves as claimed in the actual engines, and the support claim matches current data (MDN/caniuse) — have the agent fetch it rather than recall it, or check yourself.
Fix with a guard, not a fork. Prefer, in order: (a) a universally-supported alternative that removes the difference entirely; (b) feature detection — @supports in CSS, capability checks in JS — with a designed fallback, never user-agent sniffing; (c) a narrowly-scoped workaround with a comment linking the minimal repro and the upstream bug. The PR includes the repro file in the repo (or a linked gist) so the workaround can be safely deleted the day the engine fixes it.
Pin it in the matrix. Turn the repro script into a real Playwright test asserting the fixed behavior, running under all three engine projects in CI. If the bug was Safari-specific and business-critical, add the one real-WebKit check (device cloud or a Mac in CI) for that flow — Playwright WebKit for breadth, real Safari for the money path.
Cross-browser triage is reproduce → bisect → classify → guard. The agent does the tedious matrix-driving and stripping-down; you enforce that the classification cites evidence and that fixes detect features instead of sniffing browsers.
100vh, touch), which desktop WebKit cannot fully represent.The whole loop runs against local builds with locally-installed engines; nothing needs to leave the machine except what you choose to share.
Do not let an agent-driven browser session run the repro against production with a real user's account — screenshots and console dumps flow into model context. Repro on local or staging builds with synthetic data.