The Scroll That Wouldn't Stop

Why this exists

When two pages on the same site show the identical bug, the natural assumption is that they share a cause - fix it once, copy the fix, done. That assumption is exactly what makes this kind of bug take longer than it should. Sometimes two pages really do share a root cause. Sometimes they only share a symptom, and the fastest way to lose an afternoon is treating the second one as a copy of the first.

This is a small-business site where two separate pages developed the same mobile bug at some point during ordinary content work, for two reasons that turned out to have nothing in common.

The starting point

Visitors on mobile flagged a strange behavior on two pages - an About page and a Contact page. Both scrolled horizontally past their own content, endlessly, well beyond anything actually on the screen. Every other page on the site behaved normally. Both broken pages showed the exact same symptom: same direction, same "scrolls forever" feel, same absence of any visible cause when just looking at the rendered page.

That similarity was the first trap. Two pages, one symptom, visited in the same week - it reads like one bug in two places.

What was actually happening

Confirming the bug was real (and not just a visual glitch) meant checking the actual layout math rather than trusting the screen: the page's visible width was correctly constrained to the device, but the page's full scrollable width was hundreds of pixels wider than that - a genuine overflow, not a rendering artifact.

Finding the cause meant walking the page structure from the outer container inward, comparing each element's width against its own parent's width, until landing on the exact element whose box was wider than the box holding it. That's the point where a layout actually breaks - everything downstream of it is just inheriting the damage.

On the About page, that point traced back to the site's shared footer component - the same footer used on dozens of other pages without issue. The footer itself wasn't the cause; it was a downstream victim.
On the Contact page, the same tracing process led somewhere completely different: a page-specific style block, nowhere near the footer.

Two pages, two independent breakpoints, in two different parts of the codebase. The shared symptom had been a coincidence of timing, not a shared cause.

The decision log

Decision 1: Treat "same symptom" as a hypothesis, not a diagnosis

The efficient-looking move was fixing the first page and applying the identical fix to the second. That was deferred until each page had been traced independently, specifically to avoid "fixing" the second page's symptom without ever finding its actual cause.

Decision 2: Follow the About page's overflow past the footer, not into it

The widest element on the page turned out to be inside the shared footer - but that footer renders correctly everywhere else it's used, which ruled it out as the actual cause. The real problem was upstream: a content wrapper earlier in the page was missing its closing tag, corrupting how the rest of the page nested inside it and pushing the footer outside the container meant to clip it. The footer was just the first place the damage became visible.

Decision 3: Trace the Contact page from zero, not from the About page's answer

A missing closing tag was the temptation to check for first, since it had just explained the previous page. It wasn't there. The actual cause was a page-specific style rule that had been intended to style a decorative background layer, but was written targeting the real page container directly instead - taking that container out of normal flow, locking its height, and changing how it handled content wider than the screen.

Decision 4: Fix each at its own source

The About page's fix was closing the tag that had been left open. The Contact page's fix was correcting the selector so it styled the decorative layer it was always meant to, not the page container standing behind it. Two one-line changes, in two unrelated places, for a bug that looked identical from a phone screen.

Before and after

Before

Both pages scrolling endlessly right on mobile
Identical symptom, assumed shared cause
A corrupted nesting hiding behind the shared footer
A mis-targeted selector hiding in page-specific styles

After

Each page traced independently to its real cause
Missing tag closed on the first page
Selector corrected on the second page
Neither fix borrowed from the other

What this actually took

Both fixes were small once found. What took the time was resisting the shortcut of treating a shared symptom as proof of a shared cause, and instead tracing each page's layout from the outside in until the actual point of breakage showed up on its own.

The bigger takeaway wasn't either specific bug. It was that "looks the same" and "is the same" are different claims, and confusing them is exactly how a five-minute fix on one page turns into a mystery on the next.

Frequently asked questions

If two pages have the same bug, why not just copy the fix?

Because "same bug" is often an assumption based on how the bug looks, not on what's actually causing it. Applying one page's fix to another page without confirming the cause is shared risks leaving the second page's real problem untouched while looking like it's been addressed.

How do you find the actual element causing an overflow like this?

By comparing each element's rendered width against its own parent's width, moving from the outer page container inward, until reaching the specific element that's wider than the box holding it. That element - not whatever happens to be visually near the overflow - is where the fix belongs.

Does a single missing closing tag really cause damage that far away?

Yes. A missing closing tag doesn't just affect the element it belonged to - it changes how every element after it gets nested for the rest of the document, since the browser has to guess where that tag should have closed. Content meant to sit safely inside a contained wrapper can end up outside it entirely.