Known Limitations

DontBreak runs your tests in real browsers on cloud infrastructure, and a few things behave differently there than in the browser on your laptop. This page lists the limitations we know about, what they look like when you hit them, and what to do instead. If you run into something that isn't listed here, email support@dontbreak.io with a link to the test or run.

Media and browsers

MP4 video doesn't play

Symptom: a <video> element on the page renders as an empty dark player with controls but never shows a frame, both in the test editor and in run recordings. Images and everything else on the page load normally.

Why: the browsers that run your tests are open-source Chromium and Firefox builds without the licensed H.264 and AAC codecs that most MP4 files use. The page still loads and works, but the browser has nothing to decode the video with. Videos encoded as WebM (VP9 or AV1) play fine.

What to do: treat video players as a blank box. Don't select a video frame as a step target, and don't assert on it. Everything around the player, including its controls, can be tested as usual. If your site relies on a video's ended or playing event to reveal content, add a wait or assert on the content itself.

DRM-protected video never plays

Streams protected with Widevine or another DRM system don't play at all, since the test browsers ship no content decryption module. This applies to the test editor and to runs alike. Test the surrounding UI instead of playback.

Safari and WebKit

Tests run on Chromium and Firefox only. See Browser Support for the full engine matrix and why Safari isn't part of it.

Sites and networking

Hostnames that don't resolve cleanly

Symptom: the test editor opens on a blank page, or the first step of a run fails with a navigation timeout, while the site opens fine in your own browser.

Why: some domains publish several IP addresses for the same hostname, and one of them may be unreachable from our cloud region. When the browser picks that address first it can stall for the full navigation timeout. Your browser at home may have cached the working address, so you never notice.

What to do: use the hostname that resolves to a single healthy address, which is often the www. variant of the domain. If in doubt, run dig yourdomain.com and check whether every address listed responds.

Links that open a new tab

Symptom: a link with target="_blank" or a window.open() call opens in the same tab instead of a new one.

Why: DontBreak deliberately redirects pop-ups and new tabs into the current tab so a test stays on one page and every step has something to act on. A flow that needs two windows side by side can't be recorded.

What to do: author the test as if the link opened in place. Clicking the link navigates the current tab; subsequent steps act on the destination page. To come back, add a Go to URL step.

Animations are slowed on heavy 3D and canvas pages

Symptom: on a page with a full-screen 3D scene or a heavy animated canvas (a product configurator, a logo or model editor, an animated mascot or hero background), the animation in the test editor runs at about one frame per second, and if the page stays that heavy a notice (shown once per site) says the animation was slowed while authoring. Test runs treat the page the same way.

Why: the test browsers have no graphics card, so such a scene is drawn entirely in software and would otherwise keep the browser's processor busy, making every selection and click take seconds. DontBreak detects a page whose animation frames are consistently late or expensive to draw and caps that page's animation at one frame per second. Slowness that comes from the page still loading does not count, and every few seconds DontBreak checks whether the page has become light again and lifts the cap if it has. Everything else on the page keeps working at normal speed, and time-based animations still finish on schedule with fewer intermediate frames. A navigation starts fresh, so ordinary pages on the same site are unaffected.

What to do: in most cases nothing. Expect the animated area itself to be a poor target (see Animated regions are poor targets) and select stable elements around it. In rare cases a page stays too heavy even at one frame per second; you will then see "timed out" notices and a warning that the page appears to be rendering continuously. Treat such a page as outside what DontBreak can test today: test the flow up to the point where it opens, and pick up again on the next ordinary page.

Bot protection and WAFs

Cloudflare, AWS WAF, and similar services may block or challenge the test browser. See Testing Behind Bot Protection for the header-based allow-listing that gets you through.

Mobile

Mobile clicks are mouse clicks

Symptom: on a mobile run, a tap on a control inside an embedded third-party widget seems to land somewhere else, or a control only reacts to a real finger.

Why: mobile runs emulate a phone viewport, user agent, and touch support, but Click, Fill, and Type Text steps dispatch mouse clicks at the element rather than synthetic touch taps. That choice is deliberate: synthetic taps misfire inside some cross-origin embeds, most notably payment forms, while mouse clicks land reliably. The trade-off is that a control which reacts only to touch events won't respond.

What to do: the real touch gestures, Swipe, Long Press, and Pull to Refresh, dispatch genuine touch input on Chromium mobile. Use those when a control needs touch semantics. Firefox mobile has further gesture limits, listed in Browser Support.

Visual matching

Animated regions are poor targets

Symptom: a step that targets a carousel slide, a video frame, a loading spinner, or an animated hero image passes sometimes and fails other times.

Why: visual matching compares your recorded target image with the page as it looks during the run. A region that looks different on every frame matches by luck.

What to do: select a stable element next to the animation, such as a caption, a button, or the container's edge, and let DontBreak find it there. See Element Targeting and Handling Dynamic Content.

The editor's match preview can differ from what a run clicks

Symptom: the Match result panel in the test editor highlights one element, but a run clicks a different one, or the run picks the right element even though the preview looked wrong.

Why: the preview shows the first matching stage only, a pixel comparison against your target image. Runs add two further stages when that comparison is ambiguous: feature-based matching, and a check that the matched element is the same DOM element you recorded. The preview is a debugging aid, not a prediction.

What to do: trust the run report over the preview. If a run clicks the wrong element, re-select a larger, more distinctive area, and read Test Reliability.

Very large or featureless selections can time out

Symptom: a step fails with a match aborted notice in the Debug section, even though the recorded element is clearly visible in the run screenshot.

Why: matching has a fixed time budget per attempt. A selection that covers most of the viewport, or a flat area with little detail, produces so many near-identical candidates that the matcher runs out of time before it can rank them.

What to do: re-select a smaller area that contains a distinctive detail, such as text, an icon, or a corner of the element. Small, sharp targets match faster and more reliably.

AI Check only reads text and controls

Symptom: an AI Check step passes or fails in a way that doesn't match what the page visually shows.

Why: AI Check sends the page's visible text and controls (buttons, links, inputs with their labels and values) to an AI decision model — it never sees the screenshot, layout, colors, or images. A question about something that only exists visually, like an icon or a canvas, can't be answered from text alone. The model also returns a probability rather than a certainty, so borderline pages land in a "Needs review" band (20–80%) instead of a clean pass or fail.

What to do: use AI Check only for questions answerable from on-page text and controls; use Element is Visible for anything purely visual. Treat frequent Needs review results as a sign the question is ambiguous on that page and needs sharpening.