Blue Outlines Stuck in One Customer's Firefox. The Fix Was in Our Hover Script

A staff member reported blue outlines stuck on the 3-month calendar of our schedule page in Firefox. Nobody on our side could reproduce it, including me in my own Firefox.

The first hypothesis

The ticket filed that morning said the trigger was “likely environment-specific”: her Firefox version, hardware acceleration, GPU compositing or a zoom setting, “not a rule that applies to every Firefox user.” Its working hypothesis, marked unverified, was a Firefox paint artifact. The agent’s reasoning in the session was: “the outlines clear where her mouse passes. A CSS rule that’s genuinely applied doesn’t erase itself under the cursor.” It read that, combined with my not reproducing it in my own Firefox, as “this may well be her GPU/driver rather than our code.” It did say it would not call that until our side was checked, so it sent a read-only investigation through our code, and it suggested she turn off hardware acceleration as a test.

So the first theory on paper pointed at her machine, and I had not been able to reproduce it myself. The same symptom, an outline that clears under the cursor, is also what a leftover class from our own script would look like. Reading our code was the way to tell the two apart.

The investigation found that the blue was a real, designed feature of our own calendar: classes like weekHoverDay flipped a cell border from white to blue, and the mouseout handler stripped them again. Its unverified best-evidence hypothesis was a Firefox paint bug, possibly newly tripped by a Firefox update, and it proposed a repaint workaround. It said plainly that it had not reproduced anything.

What the code showed

The hover highlight was not a hover style. JavaScript added a class on mouseover and removed it on mouseout, so the page tracked hover itself instead of leaving it to the browser. Two plausible failure modes followed from that: a mouseout that did not arrive cleanly, or Firefox not repainting after the class came off. Neither was confirmed, and a driver cause was not ruled out either.

What changed

The single-cell highlight moved from the weekHoverDay class in Schedule.js to real CSS :hover, so the browser owns that state. The change also added a mouseleave safety net for the whole-week highlight, which still needs script because it spans sibling cells, and fixed a cleanup selector that used a different scope for the same strip. It shipped as a hotfix. Checking the live page with direct browser debugging showed a non-selected day cell drawing its blue border from CSS :hover alone. She tried the calendar again and said it was fixed.

What I did not verify

Nobody reproduced the original outlines, so I cannot say which failure it was, a missed mouseout or a missed repaint. The ticket says as much: the fix closes both plausible modes without identifying the real one. Her retest was the only verification against the actual symptom, and it was one person on one machine.

Check this tomorrow

Search your front end for a class that a mouseover handler adds and a mouseout handler removes. For each one, ask whether plain CSS :hover could draw it. If a bug report says “only in one browser, clears when I move the mouse”, look there before you ask the customer about her graphics driver.

dxdev LESSON · paste into your AI coding agent
LESSON: Let The Browser Own Native Visual State
SOURCE: dxdev.com/blog/2026-09-08_browser-owns-hover-state
WHAT HAPPENED: A staff member reported blue outlines stuck on a 3-month calendar in Firefox, and nobody could reproduce them. The first read was that it looked like her graphics driver rather than our code, because the outlines cleared where her mouse passed. An investigation found the outline was drawn by a class that our own JavaScript added on hover and removed on mouseout. The fix moved that highlight to plain CSS hover and shipped as a hotfix, and she confirmed it fixed on her end. The root cause was never reproduced, so the fix closes the plausible failure modes rather than proving one.
THE RULE: A symptom that clears under the cursor points at a repaint problem, but check the state your own script keeps before blaming the client. Where the browser can own a visual state such as hover, use the native mechanism instead of mirroring it in script.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Visual hover effects use plain CSS hover when no application-specific state is required.
      2. No script adds a persistent class solely to duplicate whether the pointer is over an element.
      3. For each script-managed UI state, the code identifies why a browser-native state mechanism cannot be used instead.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.