You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Boring sidebar: threads can no longer be dragged onto the composer #26676
I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.
Area
apps/web
Steps to reproduce
Turn on Settings → Labs → Boring sidebar (group by project).
Open any thread.
Press on a thread row in a project folder (or a pinned row) and drag it onto the composer.
Expected behavior
The thread drops into the composer as a thread chip, as it does with the boring sidebar off. The composer guide still promises this on web and desktop without exceptions (docs/user/composer.md#L286). Reordering and moving threads stay off, which is what #21039 meant by "Drag ... off in this mode".
Actual behavior
The row does not start a drag at all, so the thread cannot be dragged anywhere, including the composer.
#21039 turns off every row's drag sensor with projectFolders !== null in sortableDisabled (Sidebar.tsx#L3185). Dragging a thread onto the composer rides the same sensor, so it went too. The Working shelf already handles this case: its rows cannot be reordered, but isContextDrag turns their drags into reference-only drags, and planSidebarThreadDrop ignores their drops inside the list.
A possible fix is to treat every row the same way while folders are shown: keep the sensor on, make the drag a context drag, and plan no drop inside the list. Boring mode then still cannot reorder or move threads, and the composer drop works again. I have a small patch for this and can open a PR if that direction is fine.
Impact
Minor bug or occasional failure
Version or commit
0.1.4-nightly.20261028.3841 (desktop). Code links point at main 9826dbb, which has the same lines.
Environment
T3 Code (Nightly) desktop on macOS
Logs or stack traces
No response
Screenshots, recordings, or supporting files
No response
Workaround
Type @ and part of the thread's title in the composer, or choose Copy thread from the row's menu and paste it into the composer.
Additional report for T3 Code (Nightly) 0.1.6-nightly.20261031.3977, macOS desktop.
The user reports the same failure in this newer build: enabling Settings → Labs → Boring sidebar (group by project) prevents dragging an existing thread into another thread's composer as a reference.
Local investigation:
Confirmed that the setting was on and the destination composer was empty.
A native drag attempt from a project-folder thread row onto that composer left it empty, with no reference chip.
Independently inspected the shipped client bundle. The sidebar destructures projectFolders as Dn and still passes sortableDisabled: Dn !== null || … to the row. This matches the cause described above: folder mode disables the sensor used for reference drags, rather than just disabling sidebar reordering.
Restored the original setting after the investigation. No message was submitted.
The reference-only drag approach in #26724 looks appropriate: keep thread-reference dragging available, while rejecting in-sidebar reorder/pin/settle operations in grouped mode.
Useful regression coverage would be one reference chip inserted on composer drop, unchanged thread order/project membership, and unchanged Snoozed/Settled state. Include keyboard cancellation and the native macOS/Electron path in addition to web pointer tests.
Verification limits: I have not run the proposed fix branch or completed an off-mode positive-control drag. This is an additional local observation plus source inspection, not a claim that the fix is verified on macOS.
Activity
lhagenmayer commentedon Oct 31, 2026
Additional report for T3 Code (Nightly) 0.1.6-nightly.20261031.3977, macOS desktop.
The user reports the same failure in this newer build: enabling Settings → Labs → Boring sidebar (group by project) prevents dragging an existing thread into another thread's composer as a reference.
Local investigation:
projectFoldersasDnand still passessortableDisabled: Dn !== null || …to the row. This matches the cause described above: folder mode disables the sensor used for reference drags, rather than just disabling sidebar reordering.The reference-only drag approach in #26724 looks appropriate: keep thread-reference dragging available, while rejecting in-sidebar reorder/pin/settle operations in grouped mode.
Useful regression coverage would be one reference chip inserted on composer drop, unchanged thread order/project membership, and unchanged Snoozed/Settled state. Include keyboard cancellation and the native macOS/Electron path in addition to web pointer tests.
Verification limits: I have not run the proposed fix branch or completed an off-mode positive-control drag. This is an additional local observation plus source inspection, not a claim that the fix is verified on macOS.
Prepared with Codex; all examples are anonymized.