---
title: "The CSS Bug That Was Actually a Delete Bug"
canonical: https://dxdev.com/blog/2026-04-05_css-bug-was-delete-bug/
datePublished: 2026-04-05
---
A ticket arrived on April 5 as two complaints: a mobile login button rendering wrong on certain schedule pages, and a loosely described module-style issue. The kind of report that reads as CSS, gets a small priority, and sits in the queue.

I opened it expecting to write a few lines of style code and move on.

That was the wrong read.

## the first fix was uninteresting

A schedule component was missing a background-color property. Without it, the layout fell back to frame-level color rules that behaved unpredictably once modules were rearranged on the page. Adding the property stopped that fallback behavior and addressed the login-button complaint that came in with it.

The module-style issue was still open, so I kept reading.

## the boolean that always said yes

Deep in the layout-save module, there is a boolean check on the delete-list. That check gates a save-path decision. It determines whether a given module is retained or dropped when a layout is saved.

The condition used `||` where it needed `&&`.

With `||`, the gate evaluated true for the states this check was meant to distinguish. A module reaching that branch could pass the delete-list check when it should have been retained. The practical effect was that a layout save could remove a module without an error, warning, or explanation in the save path.

The symptom users saw was modules disappearing when they moved things around. It looked intermittent. It looked like a rendering quirk or a drag-drop misfire. It was neither. It was the save path dropping data on a condition that could never be false.

I had been looking for a style bug. I found a data-loss bug. The cosmetic complaint was the only way the system knew how to surface what was actually wrong.

## the repo family multiplies the cost

Once both fixes were in, the hotfix branch was cut and the changes are small: one property added to a class, one `||` flipped to `&&`. Neither is complicated.

The legacy platform uses a family of repositories and long-lived clones, so this hotfix also carried coordination work across the relevant release paths. A two-change hotfix can therefore involve more than the code change itself. That overhead is a reason to keep the fix small, verify it carefully, and keep reassessing whether the release topology still earns its maintenance cost.

## what the review step needs to ask differently

There is a habit change I want to carry out of this ticket. When a report touches a save path, the right question is not "does the visible output look correct." The right question is "what invariant does this symptom imply might be broken deeper in the path."

The login button rendering wrong was a style problem. But a layout dropping modules on save is silent data corruption. Both complaints were in the same ticket, described in the same language, assigned the same small priority. One of them was not small.

A cosmetic report can sometimes be the first clue that a deeper write-path invariant deserves attention. When a report touches saved state, do not stop at the screen: exercise the save, reload the result, and confirm the data that should remain was retained.

## Related

- [A New Feature Is the Best Fuzz-Tester for Your Existing Data Model](new-feature-is-the-best-fuzz-tester-for-your-data-model): another case where a visible feature symptom exposed a missing shared data-model behavior
- [Same Root Cause Is Not Same Fix: Verify the Data Shape, Not Just the Symptom](same-root-cause-is-not-same-fix-verify-the-shape): how to verify the underlying shape before carrying a familiar-looking fix into another path