---
title: "Why a Mobile Login Button Complaint Led Us Into the Layout-Save Module"
canonical: https://dxdev.com/blog/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. It read as CSS, so it got a small priority and sat in the queue.

We 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 and addressed the login-button complaint.

The module-style issue was still open, so we 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: 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 the check was meant to distinguish. A module reaching that branch could pass the delete-list check when it should have been retained. So a layout save could remove a module with no error, no warning and no explanation in the save path.

What users saw was modules disappearing when they moved things around. It looked intermittent, 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.

We had been looking for a style bug and found a data-loss bug. The cosmetic complaint was the only way the system had of surfacing what was wrong.

## two small changes, a large release surface

Once both fixes were in, we cut the [hotfix branch](/blog/hotfix-branches-need-different-rules/). The changes are small: one property added to a class, one `||` flipped to `&&`.

The legacy platform runs on a [family of repositories and long-lived clones](/blog/four-hotfixes-187-commits/), so the hotfix also carried coordination work across the relevant release paths. A two-change hotfix can involve more than the code change itself. That overhead is a reason to keep the fix small, verify it carefully, and keep asking whether the release topology still earns its maintenance cost.

## what review has to ask on a save path

This ticket changes how we review. When a report touches a save path, the question is not "does the visible output look correct." The question is "what invariant does this symptom imply might be broken deeper in the path."

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

So when a report touches saved state, we don't stop at the screen. We exercise the save, reload the result, and confirm that the data that should remain was retained. A small-priority style ticket pointed us at a save path that could remove modules without any error or warning, and that check is the only thing that would have caught it before the ticket was filed as low priority.