[Bug]: Markdown preview table of contents links open a new thread instead of scrolling to headings #13946

Activity

1. odzangba

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 27, 2026
2. juliusmarminge commented on Sep 27, 2026

   

   juliusmarminge

   on Sep 27, 2026

   Member

   More actions

   Triage

   Confirmed. This is a desktop bug, and it is still present on main (the 0.0.43 nightly from 2026-09-26 is not missing a later fix). No duplicate issue turned up.

   The desktop app keeps the route in the URL hash (createHashHistory in apps/web/src/main.tsx), so a thread lives at something like t3code://app/#/<environmentId>/<threadId>. The Markdown preview renders through ChatMarkdown. A table-of-contents link such as #1-operating-model becomes a real <a href="#1-operating-model">.

   Clicking it replaces that hash. Chrome fires popstate for the fragment change, and TanStack Router reads the new hash as the pathname 1-operating-model. That pathname matches the chat index route /, not a heading. IndexDraftLanding in apps/web/src/routes/_chat.index.tsx then calls handleNewThread for the most recent project, which is the new thread you see.

   Two details in handleMarkdownFragmentClick (apps/web/src/components/ChatMarkdown.tsx) make this reliable:

   • Rendered headings never get GitHub-style slug ids, so #1-operating-model has no element to scroll to. When the target is missing, the handler returns without preventDefault, and the browser follows the link.
   • When a target does exist, the handler still does history.pushState with nextUrl.hash set to the fragment alone. On desktop that overwrites the route hash the same way. The router’s patched pushState picks it up immediately.

   On the hosted web app the route is the path, not the hash, so the same click stays on the thread. It still does not scroll, because the heading id was never generated.

   A fix needs to keep same-document fragment clicks inside the preview (always preventDefault, and do not write a route-replacing hash on desktop), and to give headings stable ids that those links can find. A missing target should leave the thread and document where they are.
3. juliusmarminge

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   and removed

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 27, 2026
4. juliusmarminge

   closed this as completedin #16950on Oct 8, 2026