The Bug That Was Only Visible on Desktop

At desktop width, the tournament navigation disappeared. The controls were still in the page. They were just not where we thought the breakpoint logic would put them.

We were reworking the tournament bracket module after feedback. The visible request looked ordinary enough: restore the missing competition and find-a-team filters, make every view tab and search tool available by default, add location search, remove the Display Type toggle, and rename the module. The work had to hold together on a live test tournament site, not merely in a component preview.

The first thing I did was open the current page in a browser. That check changed the job before I wrote a line of code.

The visible symptom lied

I went in expecting a missing-element bug. A filter or tab that is absent from a desktop screen often points to conditional rendering, incomplete data, or a component that never mounted. That would have sent us straight into the template and its data path.

The live page showed something narrower and more useful. The navigation element existed, but a viewport rule was hiding it at the desktop size we were testing. The assumption behind the old behavior was that the element would be hidden in a different viewport. It was not. The bug was not in the tournament data, the search state, or the filter configuration. It was in the relationship between one element and its breakpoint.

That distinction matters because every plausible first fix would have made the page harder to reason about.

The fixes we did not ship

We could have added a second navigation control for the desktop layout. That would have created two elements with overlapping responsibilities and another place for active-state behavior to drift.

We could have special-cased the missing controls in the module code. That would have treated a CSS visibility failure as an application-state problem. It might have made the desktop screenshot look correct while leaving the wrong breakpoint intact.

We could have kept the existing Display Type toggle and hidden the restored tools behind it. Product feedback had already made the direction clear: the view tabs and search tools should be present by default, and Display Type should go away. Folding the controls behind another switch would have preserved the old confusion with better styling.

Instead, we fixed the visibility behavior at the point where it was wrong, restored the competition and find-a-team filters, added location search, and made the intended controls visible by default. Then we verified the complete flow on the live test site and committed the feature branch.

Browser first, code second

The useful part was not that a browser found a CSS bug. The useful part was that the browser check ruled out a whole category of code changes before they existed.

A local component state can tell me that an element should render. It cannot prove that the rendered element survives the actual viewport rules around it. A code review can confirm that a condition is logically sound. It cannot tell me that the wrong media query owns the final display value.

The difference took minutes to find because we checked the live interface first. Without that check, we could have spent the session repairing data flow, duplicating navigation, or polishing a toggle that should have been deleted.

The bug was only visible on desktop. The real failure was treating an assumption about the desktop as evidence.

dxdev LESSON · paste into your AI coding agent
LESSON: Verify The Live Rendered UI Before Diagnosing A Missing-Element Bug In Code
SOURCE: dxdev.com/blog/2026-08-22_desktop-hidden-ui-bug-verify-before-coding
WHAT HAPPENED: During a rework of a tournament bracket module, desktop-width navigation controls appeared to be missing. Before writing any code, the author opened the live test tournament site and found the controls were present in the DOM but hidden by an incorrect viewport rule, not by missing data, broken state, or a component that failed to mount. That ruled out fixes like adding a duplicate desktop navigation element, special-casing the missing controls in application code, or hiding restored tools behind the existing Display Type toggle. Instead, the team fixed the visibility rule at its source, restored the filters and added location search, verified the full flow live, and shipped.
THE RULE: When a UI element appears missing, check the live rendered page in the actual viewport before assuming it's a data, state, or component-mounting bug, since a component or state check cannot reveal a CSS visibility or breakpoint failure.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Was the 'missing' element inspected in the live rendered DOM/viewport before any code change was proposed?
      2. Does the proposed fix address a rendering/visibility rule (CSS, breakpoint, media query) rather than duplicating logic or state to compensate for it?
      3. Was the fix verified across the actual affected viewport sizes on a live or live-like environment, not just a component preview?
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.