The Display Type Toggle and the Breakpoint That Hid Our Controls

At desktop width, the event 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 event module after feedback. The request looked ordinary: restore the missing filters, make every view tab and search tool available by default, add location search, remove the Display Type toggle, and rename the module. It had to hold together on a live test event site, not just in a component preview.

Before writing any code, we opened the current page in a browser. That check changed the job.

What the live page showed

We went in expecting a missing-element bug. A filter or tab that is absent on a desktop screen usually 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. The navigation element existed, and a viewport rule was hiding it at the desktop size we were testing. The old behavior assumed the element would be hidden at a different viewport, and it wasn’t. Nothing was wrong with the event data, the search state, or the filter configuration. The fault sat between one element and its breakpoint.

That mattered 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 left 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, and the desktop screenshot might have looked right while the wrong breakpoint stayed in place.

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

Instead we fixed the visibility behavior at the point where it was wrong, restored the missing 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.

Why the browser came first

The browser didn’t just find a CSS bug. It ruled out a whole category of code changes before they existed.

Local component state can tell you an element should render. It can’t prove the rendered element survives the viewport rules around it. A code review can confirm a condition is logically sound. It can’t tell you the wrong media query owns the final display value.

Finding this took minutes because we looked at the live interface first. Without that, 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, and treating an assumption about the desktop as evidence was the failure. When an element seems to be missing, open the live page and confirm what is happening before approving any change. Here the navigation was present, a viewport rule was hiding it, and the fix belonged in exactly one place.

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/desktop-hidden-ui-bug-verify-before-coding
WHAT HAPPENED: During a rework of an event module, desktop-width navigation controls appeared to be missing. Before writing any code, the author opened the live test 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.