chrome: nav hash duplicates on repeated click → reload → click

[yigitdot]

Summary

Clicking the DecDN Labs wordmark or any in-nav section link, hard-reloading the page, and then clicking the same link again leaves the URL with a duplicated fragment — e.g. decdn.org/#method#method#method#method after a few cycles. Repeating the click → reload → click loop keeps appending. The fragment is invalid (browsers only recognise the first #), the page no longer scrolls to the intended section on subsequent loads, and the URL is unshareable.

Repro

1. Open https://decdn.org/.
2. Click the DecDN Labs wordmark, or any section link in the nav (e.g. "method").
3. URL becomes decdn.org/#method. ✓
4. Hard-reload (Cmd+R / Ctrl+R).
5. Click the same link again.
6. Observe: URL becomes decdn.org/#method#method. Repeat to grow further (#method#method#method#method, …).

Expected

URL stays decdn.org/#method. Clicking a same-hash link should be a no-op for the URL (and at most re-trigger the scroll to the section).

Affected

Desktop Next.js <Link> path in components/site/Chrome.tsx:

• Wordmark — Chrome.tsx:148-174 (<Link href=\"/#intro\">).
• Section list — Chrome.tsx:176-192 (<Link href={\/#${item.id}`}>`).

These are plain next/link Links with no onClick interception. The mobile drawer goes through MobileMenu.handleClick + history.replaceState(null, \"\", \#${anchor}`) (MobileMenu.tsx:236, 269-276`) and appears unaffected — worth confirming during triage.

Environment

• next@16.2.6, react@19.2.6.
• next.config.ts: output: \"export\", trailingSlash: true.
• Reproduced on the deployed site (Cloudflare Pages serving out/).

Hypothesis / open questions

Repeated <Link href=\"/#method\"> clicks while the URL already carries #method appear to append the hash rather than replace it — consistent with an App Router hash-navigation quirk under output: \"export\" + trailingSlash: true. Could be a Next.js 16 bug or a local interaction; needs a clean repro to determine which.

Suggested next steps

• Reduce to a minimal Next 16 repro outside this project to determine upstream vs. local.
• If local: intercept these Link clicks (or wrap them) to detect same-hash navigation and fall back to history.replaceState + smooth scroll, similar to the helper in MobileMenu.tsx:55-91 — that scroll routine is already a good reuse target.

[github-actions]

🎯 Agentic Issue Triage

Bug: Desktop nav <Link href="/#section"> entries append the hash to the current URL rather than replacing it when the URL already carries the same fragment, producing /#method#method#method... on repeated click → hard-reload → click cycles.

📍 Root cause analysis

The desktop nav links (Chrome.tsx:148–192) are plain <Link href="/#intro"> / <Link href={/#${item.id}}> with no onClick override. Under Next.js App Router with output: "export" + trailingSlash: true, the router resolves the pathname as / (already current), so it treats the navigation as a same-page hash change. The browser/router appears to push the fragment onto the existing URL rather than replace it — so /#method becomes /#method#method after another click.

The mobile path avoids this because MobileMenu.handleClick calls history.replaceState(null, "", #${anchor}) directly (bypassing <Link>), which always writes an absolute fragment.

🔬 Reproduction steps

1. `(decdn.org/redacted) — fresh load.
2. Click any desktop nav section link (e.g. "Method") → URL = /#method.
3. Hard-reload (Cmd/Ctrl+R).
4. Click "Method" again → URL = /#method#method. ✓ bug confirmed.
5. Repeat to accumulate further fragments.

🛠 Suggested fix

Option A — onClick intercept (minimal, local):

Add an onClick handler to the desktop (Link) components in Chrome.tsx that calls history.replaceState when the target hash is already present, exactly as MobileMenu.tsx:269-276 does. The shared scroll helper at MobileMenu.tsx:55–91 is already a good reuse target — extract it to lib/scroll.ts or similar so both Desktop and Mobile use the same routine.

// lib/scroll.ts (extracted from MobileMenu)
export function scrollToSection(anchor: string) {
  history.replaceState(null, "", `#${anchor}`);
  document.getElementById(anchor)?.scrollIntoView({ behavior: "smooth" });
}

Then in Chrome.tsx nav items:

<Link
  href={`/#${item.id}`}
  onClick={(e) => { e.preventDefault(); scrollToSection(item.id); }}
  ...
>

Option B — investigate upstream: Reduce to a minimal Next.js 16 + output: export + trailingSlash repro to determine if this is a router bug worth filing upstream. Worth doing in parallel.

✅ Sub-tasks checklist

• Confirm bug is reproducible on latest deploy
• Confirm mobile drawer (MobileMenu) is not affected
• Extract scrollToSection helper from MobileMenu.tsx:55–91 into lib/scroll.ts
• Add onClick intercept to wordmark <Link> (Chrome.tsx ~line 148)
• Add onClick intercept to section nav <Link> items (Chrome.tsx ~line 180–192)
• Update MobileMenu to use the shared helper
• Verify: repeated click → reload → click no longer duplicates fragment
• (Optional) File upstream Next.js issue if minimal repro confirms router bug

🔗 Relevant code pointers

• components/site/Chrome.tsx — desktop nav wordmark + section links
• components/site/MobileMenu.tsx:55–91 — existing scroll helper (reuse candidate)
• MobileMenu.tsx:236, 269–276 — history.replaceState usage that avoids the bug
• Related open issue: chrome: navbar home-route check assumes single locale, no basePath #115 (Chrome home-route assumption) — same file, different concern

📚 Resources

• [Next.js App Router hash navigation]((nextjs.org/redacted)
• [history.replaceState MDN]((developer.mozilla.org/redacted)
• [Next.js output: export constraints]((nextjs.org/redacted)

Generated by Agentic Triage for issue #116 · ● 1.4M · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/issue-triage.md@c7d030cd6d4607b90d9ac3ffc8b24aff4f251632