Board drag-and-drop: "Drag cards here" drop zones don't collapse after dragging a card (Chrome on Windows)

**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:

1. Open a board where the columns fill the viewport height, with at least one empty column.
2. In the DevTools console run:
```js
document.querySelector(".card-columns").scrollTop = 9999
```
3. 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](https://app.basecamp.com/2914079/buckets/27/card_tables/cards/10036823625).

Start with app/assets/stylesheets/card-columns.css and reproduce the stuck state by setting .card-columns.scrollTop = 9999 in DevTools on a board with empty columns. Then investigate what changes the container's vertical scroll during a real card drag on the affected Chrome and Windows setups. Done means the drop zones collapse and headings remain aligned after dragging, without requiring a page refresh.

Written by the indexing model from the issue text.