Sign up
View stargazers13Sign up

[Bug]: Sidebar does not follow active thread after Cmd+[ / Cmd+] (back/forward) navigation#16534

opened17d agobyWWarutC

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/desktop (sidebar / navigation)

Steps to reproduce

  1. Open T3 Code desktop with 2+ projects, each with several threads. Keep default sidebarThreadPreviewCount (6).
  2. Open a thread in project A, then open a thread in project B (via Cmd+K, Cmd+1..9, or clicking).
  3. Make one of these true for the thread you will return to: its project is collapsed in the sidebar, the sidebar project filter is set to a different single project, or the thread is beyond the first 6 shown in its project.
  4. Press Cmd+[ (navigation.back) to return to the earlier thread, or Cmd+] to go forward.

Expected behavior

The sidebar follows the active route: the owning project is expanded, the sidebar scope is widened if the thread is filtered out, the thread list reveals the thread if it is hidden behind "show more", and the active thread is scrolled into view and highlighted. This matches what a user sees after clicking the thread directly.

Actual behavior

The main pane switches to the thread but the sidebar does not change. The active thread is not visible or highlighted, so it is unclear which project/thread is now open.

From reading the bundled renderer, navigation.back / navigation.forward only call window.history.back() / window.history.forward(). Nothing reveals the active thread in the sidebar on route change (no project expand, no scope reset, no scroll-into-view).

Impact

Minor bug or occasional failure. It makes back/forward navigation across many projects disorienting.

Version or commit

T3 Code (Alpha) 0.0.45, macOS (Darwin 25.6.0)

Workarounds

Set the sidebar filter to "All projects", expand the project manually, increase sidebarThreadPreviewCount, or pin the thread.

JJulius Marminge17d ago

Note

Grok responding on behalf of Julius.

Triage

Thanks @WarutC for the clear repro. Reading current main (b38aa18365), which matches the 0.0.45 build in the report, I don't see a duplicate. navigation.back / navigation.forward only call history.back() / history.forward() (NavigationHistoryShortcuts in apps/web/src/components/AppSidebarLayout.tsx). Highlight is route-driven: a row that is actually rendered gets the active style whenever its key matches the route, including after history navigation.

What I found

  • Some cases already follow the route.
    • Default sidebar (legacy sidebar off): a settled thread past "Show more" is inserted into the visible tail when it is the open route, and a collapsed Working, Snoozed, or Settled shelf still renders the open thread's row. sidebarThreadPreviewCount (default 6) is unused here; the settled page starts at 10.
    • Legacy sidebar (Settings → Legacy features → Sidebar): a collapsed project still renders the open thread as that project's only row. The project header stays collapsed.
  • Two gaps are real, and they're shared by every route change, including the command palette. A click only looks correct when that row was already on screen.
    1. Default sidebar project scope. filterSidebarV2VisibleThreads drops every thread outside the scoped project, with no exception for the open route. setSidebarProjectScopeKey runs from the scope menu, the "filter by project" context-menu item, and when a saved scope's project disappears. Going back to a thread in another project leaves the filter in place, so the row isn't rendered and there's nothing to highlight. Pinning doesn't bypass that filter.
    2. Legacy sidebar, project expanded, thread past the preview count, "show more" not opened. The rendered list is the preview slice (sidebarThreadPreviewCount, default 6). The open thread isn't added.
  • No scroll-into-view. Neither sidebar scrolls the active row into view. The only scrollIntoView in the thread sidebar is for search results, so a row that exists below the fold stays off screen after history navigation.

Likely fix area

Sidebar route follow / filterSidebarV2VisibleThreads and the legacy preview slice. Some options:

  • For a scoped project filter, either widen the scope when the open thread is outside it, or keep the filter and still show the open row (what the shelves already do).
  • In the legacy sidebar, include the open thread in the preview list when it sits past sidebarThreadPreviewCount.
  • Scroll the active row into view on route change, not only for search results.

Which sidebar was on, and which of those two gaps you hit, would help pin the fix.

A maintainer will decide on the fix direction.

WWarutC17d ago
Synced from GitHub

Thanks for the triage. To answer the questions: I'm on the default (non-legacy) sidebar.

With "All projects" selected, the highlight is correct after Cmd+[ / Cmd+], so I did not hit the scope-filter gap in practice. What I would still confirm is the missing scroll-into-view for rows below the fold. The single-project scope case follows from your reading of filterSidebarV2VisibleThreads, but I haven't tested it myself.

Separately, back/forward stopping on the Settings page is a different bug, so I filed it on its own: #16542.

JJulius Marminge2d ago

Reproduced on main a12d6ed942 using the web dev server in Chromium on Linux, 1280×800, with two isolated fixture projects and eight threads each. Ctrl+[ / Ctrl+] exercise the Linux back/forward bindings.

  • New sidebar: opened A8, then B8, filtered to B, pressed Back. The main pane returned to A8 while the sidebar kept the B filter and omitted A8. Forward returned to B8. Recording.
  • Legacy sidebar, preview count 6: opened A1 via Show more, switched to B8, clicked Show less for A, pressed Back. The main pane returned to A1 while A1 remained hidden. Recording.
  • Collapsed legacy project: Back revealed the active row beneath its collapsed header on this commit.

No duplicate found among 949 open issues. macOS/Electron shortcut handling is unverified here.