The Mobile Menu Trilogy: One Button, Three Fixes, Mild Emotional Damage

This post is about a single button.

A tiny hamburger menu button.

A button so small you could miss it with your thumb.

That button consumed multiple commits and a non-trivial portion of my sanity.

Episode List (Yes, There Were Episodes)

The timeline:

• 0b5c0fe (2026-02-17): top tab + mobile menu functionality pass
• 8ee6bab (2026-02-17): mobile hamburger still broken on specific pages
• f472d14 (2026-02-17): missing hamburger HTML on mobile

If this sounds repetitive, that's because it was.

Root Cause Pattern

We didn't have one bug.
We had a class of consistency bugs:

1. JS toggle logic existed, but not uniformly
2. CSS states existed, but not consistently applied
3. Some pages were missing required HTML nodes

Each local fix looked correct inside its file, but globally the system remained fragile.

The Actual Toggle Logic We Added

From 0b5c0fe (js/app.js):

const mobileMenuBtn = document.getElementById('mobile-menu-btn');
const navLinks = document.querySelector('.nav-links');

if (mobileMenuBtn && navLinks) {
  mobileMenuBtn.addEventListener('click', () => {
    navLinks.classList.toggle('mobile-open');
  });

  document.addEventListener('click', (e) => {
    if (!mobileMenuBtn.contains(e.target) && !navLinks.contains(e.target)) {
      navLinks.classList.remove('mobile-open');
    }
  });
}

Nothing exotic. Just normal, reasonable UI behavior.

And still, we had breakage. Why? Because behavior logic is only half the contract.

The Missing HTML Problem

In f472d14, the fix was embarrassingly simple:

• some pages literally did not include the hamburger button HTML block

Meaning:

• JS listener setup ran
• queried element returned null
• UI did not expose menu entry at all

This is a perfect "works on my page" trap.
The code can be correct and still fail if page structures drift.

Why This Bug Was Sticky

The navigation layer existed in many HTML files.

Any time you run multi-page static layouts without strict templating, you risk:

• structural drift
• stale copies
• one-file hotfixes that never propagate

From the outside, it looks like one bug.
From the inside, it's a distribution problem.

The Non-Developer Lesson I Learned the Hard Way

I used to think UI bugs were mostly about "bad JS."

Now I think mobile UI bugs are often about this triangle:

• structure (HTML)
• behavior (JS)
• state styling (CSS)

If one side is inconsistent, the triangle collapses and your users get a broken menu.

How We Reduced Repeat Incidents

Not perfect, but better:

1. standardized nav structure across pages
2. repeated toggle logic where needed
3. added visual pass on multiple routes, not just home

And yes, that last one matters.
Because bugs love pages no one manually tests at midnight.

Screenshot Reality Check

The finder page is exactly where these bugs hide:

• complex layout
• enough content to distract you
• different scroll and viewport behavior

If nav works on home but fails here, users still call it broken.

Tangent (But Useful): Why This Is Actually Product Work

I know, this sounds like "just front-end bugfixing."

But from user perspective:

• if nav fails, trust drops
• if trust drops, strategy outputs feel less credible
• if outputs feel less credible, your core value is discounted

So yes, a hamburger button can impact perceived product quality way beyond navigation.

Final Notes from the Button Wars

What I would do if restarting:

1. centralized nav partial/template from day one
2. route checklist for responsive controls
3. tiny e2e mobile smoke test on critical pages

Because the menu bug is never "just one bug."
It is usually your architecture politely telling you to standardize before you add more features.

And yes, I still stare at hamburger buttons like they owe me money.