Reported by multiple users in the same organization, all on Chrome on Windows PCs. We (37signals support/on-call) have not been able to reproduce the trigger ourselves — not on Mac, not on other Windows machines, not via BrowserStack — so we're opening this up hoping someone can reproduce it or recognize the environment-specific trigger.
What happens
After dragging a card on a board, the "Drag cards here" drop zones of the empty columns fail to collapse. They remain visible, peeking out at the bottom of each column, and the column headings get pushed up and partially obscured. The board stays in this state — the user can't scroll it back — and a full page refresh is the only fix.
Expected (empty columns' drop zones hidden, headings aligned at the top):
Actual (after dragging a card — truncated "D…" drop-zone stubs peeking at the bottom, count badges/headings pushed up out of view):
Environment
- Chrome 149.0.7827.158 and 149.0.7827.197, Windows PCs
- Several machines in one organization are affected consistently; other Windows/Chrome machines with the same versions (including BrowserStack) are not
- Persists in incognito with extensions disabled, after clearing cache/cookies
- Chrome console shows no errors while it happens
What we found investigating
The visual state itself is reproducible on any machine. Mechanically:
.card-columns is the horizontal board scroller: overflow-x: auto; overflow-y: hidden (app/assets/stylesheets/card-columns.css, ~line 58).- Each empty column's
Drag cards here blank slate (.blank-slate--drag) is rendered below the column's transition container, hanging past the bottom edge of .card-columns. It's normally invisible only because overflow-y: hidden clips it. In our test board the overhang is exactly 70px (scrollHeight - clientHeight).
overflow-y: hidden still makes the element a scroll container: it can't be scrolled by the user, but it can be scrolled programmatically or by browser-internal scrolling (drag auto-scroll, focus-triggered scroll-into-view, etc.).
So scrolling that container down reproduces the reported state pixel-for-pixel. On any board with empty columns:
- Open a board where the columns fill the viewport height, with at least one empty column.
- In the DevTools console run:
document.querySelector(".card-columns").scrollTop = 9999
- The container scrolls down by the drop-zone overhang (70px here) and sticks: the "Drag cards here" stubs appear at the bottom, the column headings shift up, and there's no way to scroll back without a refresh. That is exactly what the affected users see after dragging a card (screenshot above).
Nothing in the app ever scrolls this container vertically on purpose, and nothing resets scrollTop after a drag — so once any vertical scroll happens there, the board is stuck.
What we don't know — help wanted
What scrolls .card-columns vertically during a real drag on these specific machines? Candidates we suspect but couldn't confirm:
- Chrome's drag-and-drop auto-scroll kicking in for
overflow: hidden scroll containers under some GPU/driver/display-scaling configuration
- Mouse/trackpad driver software issuing scrolls under the cursor mid-drag
- Focus-triggered
scrollIntoView behaving differently on those machines (plain focus()/scrollIntoView does not scroll this container in our tests)
If you can reproduce the trigger with a real card drag, please share: Windows version, display scaling (DPI), input device/driver software, chrome://gpu snippet, and whether it happens at other zoom levels.
Independently of the trigger, a likely hardening fix is to reset the container's vertical scroll after drag operations (or ensure the drop-zone blank slates can't create vertical scrollable overflow in the first place).
Internal tracking: Basecamp card.
Reported by multiple users in the same organization, all on Chrome on Windows PCs. We (37signals support/on-call) have not been able to reproduce the trigger ourselves — not on Mac, not on other Windows machines, not via BrowserStack — so we're opening this up hoping someone can reproduce it or recognize the environment-specific trigger.
What happens
After dragging a card on a board, the "Drag cards here" drop zones of the empty columns fail to collapse. They remain visible, peeking out at the bottom of each column, and the column headings get pushed up and partially obscured. The board stays in this state — the user can't scroll it back — and a full page refresh is the only fix.
Expected (empty columns' drop zones hidden, headings aligned at the top):
Actual (after dragging a card — truncated "D…" drop-zone stubs peeking at the bottom, count badges/headings pushed up out of view):
Environment
What we found investigating
The visual state itself is reproducible on any machine. Mechanically:
.card-columnsis the horizontal board scroller:overflow-x: auto; overflow-y: hidden(app/assets/stylesheets/card-columns.css, ~line 58).Drag cards hereblank slate (.blank-slate--drag) is rendered below the column's transition container, hanging past the bottom edge of.card-columns. It's normally invisible only becauseoverflow-y: hiddenclips it. In our test board the overhang is exactly 70px (scrollHeight - clientHeight).overflow-y: hiddenstill makes the element a scroll container: it can't be scrolled by the user, but it can be scrolled programmatically or by browser-internal scrolling (drag auto-scroll, focus-triggered scroll-into-view, etc.).So scrolling that container down reproduces the reported state pixel-for-pixel. On any board with empty columns:
Nothing in the app ever scrolls this container vertically on purpose, and nothing resets
scrollTopafter a drag — so once any vertical scroll happens there, the board is stuck.What we don't know — help wanted
What scrolls
.card-columnsvertically during a real drag on these specific machines? Candidates we suspect but couldn't confirm:overflow: hiddenscroll containers under some GPU/driver/display-scaling configurationscrollIntoViewbehaving differently on those machines (plainfocus()/scrollIntoViewdoes not scroll this container in our tests)If you can reproduce the trigger with a real card drag, please share: Windows version, display scaling (DPI), input device/driver software,
chrome://gpusnippet, and whether it happens at other zoom levels.Independently of the trigger, a likely hardening fix is to reset the container's vertical scroll after drag operations (or ensure the drop-zone blank slates can't create vertical scrollable overflow in the first place).
Internal tracking: Basecamp card.