[Bug]: Collapsing a project with many visible threads blocks the UI for seconds

Before submitting

• 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

1. Open a project containing around 100 threads.
2. Expand the project in the sidebar.
3. Use “Show more” until all or most threads are rendered.
4. Collapse the project.

Investigation

The thread list in apps/web/src/components/Sidebar.tsx is wrapped with FormKit's autoAnimate.

Collapsing a large project removes all visible thread rows at once. autoAnimate observes those removals and appears to:

• reinsert every removed row temporarily;
• read layout and computed styles for each row;
• apply absolute positioning;
• create a separate exit animation for every row.

In a local reproduction with 100 threads, collapsing produced approximately:

• 3.4 seconds of main-thread blocking;
• 204 getBoundingClientRect() calls;
• 304 computed-style reads;
• 102 animations.

The React state update and component unmounting took only around 27 ms. With the list animation bypassed, the entire collapse completed in around 37 ms.

This suggests repeated DOM writes followed by geometry reads are forcing synchronous layouts for every removed row.

Suggested direction

Avoid per-row exit animations when a large number of sidebar rows are removed together. Possible approaches:

• disable autoAnimate for bulk project collapse;
• apply a row-count threshold above which removal animations are skipped;
• animate the list container as one element instead of animating every removed row.

Small list changes and drag/reorder animations could continue using autoAnimate.

Environment

Current main, Chromium-based browser.

Expected behavior

The project should collapse immediately, or within the duration of a short animation. The UI should remain responsive.

Actual behavior

Collapsing the project blocks the main thread for several seconds. The delay becomes significantly worse as the number of visible threads increases.

Investigation

The thread list in apps/web/src/components/Sidebar.tsx is wrapped with FormKit's autoAnimate.

Collapsing a large project removes all visible thread rows at once. autoAnimate observes those removals and appears to:

• reinsert every removed row temporarily;
• read layout and computed styles for each row;
• apply absolute positioning;
• create a separate exit animation for every row.

In a local reproduction with 100 threads, collapsing produced approximately:

• 3.4 seconds of main-thread blocking;
• 204 getBoundingClientRect() calls;
• 304 computed-style reads;
• 102 animations.

The React state update and component unmounting took only around 27 ms. With the list animation bypassed, the entire collapse completed in around 37 ms.

This suggests repeated DOM writes followed by geometry reads are forcing synchronous layouts for every removed row.

Impact

Minor bug or occasional failure

Version or commit

main@c1ec1915fc16f3dc1ec5d47d9a97f6210a574526

Environment

linux, browser and electron

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

No response

Start in apps/web/src/components/Sidebar.tsx and inspect how FormKit's autoAnimate wraps the thread list during project collapse. Reproduce the slowdown with a project containing around 100 visible threads, then compare the collapse with bulk row animations bypassed. Done means large collapses keep the UI responsive while small list and drag/reorder animations continue working.