[Bug]: Sidebar opens and/or focusses MR every time opening a thread #12040

Activity

1. danir-de

   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 16, 2026
2. juliusmarminge commented on Sep 16, 2026

   

   juliusmarminge

   on Sep 16, 2026

   Member

   More actions

   Triage

   Confirmed on current main (b900fc94e) and on shipping 0.0.42 / the reported 0.0.41-nightly.20260916.1795. All three already contain #9276, #10113, and #10610. This is a real web/desktop right-panel bug, not a wash of those PRs. Desktop embeds the same ChatView path; nothing in apps/desktop owns this.

   The reporter likes server auto-link (“MR auto-assign”). The complaint is the right panel: opening a thread force-opens and force-focuses the assigned merge request, including after hide/close, including when that MR is already a tab, and sometimes as a second tab for the same MR. That matches the code. Auto-link itself is fine.

   Two open paths. Both end in openProactive → upsertSurface, which always sets isOpen: true and activates the PR surface.

   What the code does

   ChatView.tsx watches linkedPullRequest ?? branchPullRequest (the auto-assigned / branch-detected MR from ThreadPullRequestReactor). On every active-thread effect it does two things:

   1. On-entry open (shouldOpenProactivePullRequest, gated by Settings → General → Proactive panels). observeProactivePanelUserChoice resets targetKey to undefined whenever the thread key changes. The helper is then undefined → "<project>:<repo>:<n>" → true. That is fix(web): open proactive panels when entering threads #10610: “opens an existing pull request on entry.” The test in ChatView.logic.test.ts asserts exactly that. feat(web): add proactive panels #9276 originally promised historical panels stay closed on thread switches; fix(web): open proactive panels when entering threads #10610 reversed the PR half.

   2. Follow a changed server link (shouldRetargetThreadPullRequestPanel). If the open surface is still the previous linked PR and the server assigns a different one, it calls openProactive even with Proactive panels off.

   openProactive (rightPanelStore.ts) refuses only when userActionRevision has moved since the snapshot this effect took. #10113 added that so a hide/Files click during a turn is kept. It does not survive a thread switch:

   • observeProactivePanelUserChoice re-reads getUserActionRevision when !sameThread. Hide/close already incremented the count; the next visit snapshots the new count, so expected === current and the open is allowed again.
   • The revision map is not persisted (partialize writes only byThreadKey). Reload zeros it.

   So “closed 10 times” is real: close is a user action on this visit, forgotten on the next.

   upsertSurface has an unused activate = true default and always opens the panel (isOpen: true + focus that surface). If the MR tab already exists, it is not added again — but the panel is shown and that tab is focused. That is “already open in a sidebar tab” and “force focuses.” There is no background-add path.

   Duplicate tabs are a second, mechanical bug. pullRequestSurfaceId keys on optional environmentId + optional host + project + repo + number. A click through openPullRequestLink stores host. Auto-open uses pullRequestSurface(linkedThreadPullRequest). ThreadLinkedPullRequest has url but no host, and the helper does not parse one out of url. Same MR becomes:

   • pull-request:<project>:<host>:<repo>:<n> (click)
   • pull-request:<project>:<repo>:<n> (proactive)

   Mixing click + auto-open creates two tabs. The GUI alone will not.

   Not fixed after the reported nightly. The only later ChatView touch is #12015 (worktree setup card). No open PR claims this.

   Related, not duplicates

   Issue / PR	Why it does not close this
   Merged #9276	Added opt-in Proactive panels. Original contract: newly linked PR / completed-turn diff only; historical panels stay closed on thread switches.
   Merged #10610	Made on-entry undefined → key open the existing PR. That is the “every time I open a thread” trigger. It did not add hide-across-switch, background-add, or host-stable ids.
   Merged #10113	Keeps hide/Files during a turn. Revision is re-snapshotted on thread change and dropped on reload. This report is the visit after that.
   Merged #9753	Empty diffs must not replace an open PR. Priority, not hide/focus.
   Merged #8160	Thread ↔ PR link. The assign the reporter likes. Not the panel.
   Open #9079 / #10650	Different PR UX; neither stops on-entry openProactive.

   No open or merged PR stops upsertSurface from reopening/focusing, persists the hide across thread keys, or unifies host-less vs host-ful PR surface ids.

   Suggested fix

   Keep this as a right-panel bugfix in apps/web (desktop inherits). Do not turn off auto-link.

   1. Do not treat a thread revisit as a new link. shouldOpenProactivePullRequest(undefined, key) is what fix(web): open proactive panels when entering threads #10610 added. First observation of a link on a thread (or a real project/repo/number change) may still open. Re-entering a thread whose targetKey was already that MR must not. Persist that last offered key with the panel state, or stop resetting targetKey on !sameThread when the thread already has a matching PR surface / stored key.
   2. Honor hide/close across visits. Either persist userActionRevisionByThreadKey, or refuse openProactive when the matching PR surface already exists and isOpen === false (same idea as dismissedDeviceSurfaceIds). A later new link or a later turn can still offer once.
   3. Do not steal focus. If the surface id is already in surfaces, call upsertSurface(..., activate=false) and do not force isOpen: true. First add may still open+focus. “Respect my previously opened tab, even in the background.”
   4. One tab per MR. When building a proactive surface from ThreadLinkedPullRequest, parse host from url (or match an existing tab by projectId + repository + number, ignoring a missing host).
   5. Tests next to ChatView.logic.test.ts / rightPanelStore.test.ts: hide → switch thread → come back stays closed; PR tab present with Files active → Files stays; click-with-host then proactive-without → one surface; setting off → on-entry does not open.

   Do not revert #10610 wholesale if first-ever visit should still peek the PR when the setting is on. The defect is revisit / hide / focus / duplicate, not “never open.”

   Workaround

   Settings → General → Proactive panels off. That stops on-entry force-open. Follow-on-reassign can still steal focus if the panel is already showing the previous linked MR; hide the panel first. No in-app “open assigned MR in the background.”

   Classification: bug · accepted · medium (web/desktop right panel; thread entry / auto-link force-opens and force-focuses the assigned MR)
   Labels: add accepted, via-triage; keep bug; remove needs-triage
   Discord tags: ui
3. juliusmarminge

   added

   acceptedfeature request acceptedfeature request accepted

   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 16, 2026
4. kridaydave

   added a commit that references this issue on Sep 18, 2026

   fix(web): don't force-open MR panel on thread open

   ...

   This issue will close once commit 1d1b453 is merged into the 'main' branch.

   1d1b453