My unit tests were green. My integration tests were green. The feature was broken in a way that produced no error, no warning, and no visual clue that anything was wrong.
The feature was a CSS difference blend mode, used to compare a design mockup against a live page: matching pixels turn black, so only the differences light up. Mine turned nothing black. It looked exactly like normal mode, and I lost about a week to it.
The cause was one line of CSS, and the reason no test caught it is the interesting part. The blend mode that silently did nothing
Here is the overlay, simplified. A closed shadow root holds an image positioned over the page:
mix-blend-mode blends an element with its backdrop — but only within its own stacking context. And z-index on a positioned element creates a stacking context. So the host became a sealed box, and the image blended against the empty space inside that box instead of against the page underneath.
The result isn't an error. It isn't even visibly wrong unless you know what difference should look like. The image just renders normally, as though you never set the property.
The same applies to opacity below 1, filter, transform, isolation, backdrop-filter, mask, contain: paint and will-change of any of those. Any one of them on an ancestor silently disables blending. On a page you don't control — which is the entire premise of a browser extension — any of them might arrive from the site's own CSS.
The fix was to stop creating a stacking context on the host and move z-index onto the children that actually need it:
Plus a MutationObserver re-pinning those properties inline with !important, because hostile page CSS will try to set them back.
Why no test caught it: every assertion I had was of the form getComputedStyle(img).mixBlendMode === 'difference'. That was true the entire time. The property was set. It was applied. It just had nothing to blend with. Computed style tells you what the engine parsed, not what the compositor drew.
The extension has a paid tier backed by licence keys. Validation looked like this:
Spot it? The success path writes to storage. The failure path returns an error object and touches nothing.
So when a subscription lapsed and the key was disabled, pressing Re-check in the UI did this: called the API got back valid: false, status: "disabled" displayed "This license key is disabled." to the user left isPro: true in storage
The customer read an accurate error message while keeping every paid feature. The only thing that ever revoked access was a once-per-24-hours background revalidation, so a cancelled subscriber kept Pro until their browser happened to check again.
Why no test caught it: my test suite faked the paid tier by writing isPro: true straight into storage. Every test of a Pro feature started from "pretend they're Pro". Nothing ever ran the activation path. I had thorough tests of what Pro users could do and zero tests of how someone becomes — or stops being — a Pro user.
Finding it meant buying my own product. I made a real subscription purchase in the payment provider's test mode, activated the key, then disabled it from the dashboard and watched what the extension actually did. The fix:
Those three guards are the whole problem in miniature. "Revoke on failure" is a one-line change that would also have logged out every customer whose wifi dropped. The SVG that rendered at 240×150
A user drops in an SVG mockup. It renders at roughly a quarter of its real size.