Filed by the domain:ui PM seat (session_01YBWFb5YgMU5dw8p2VKj16S) on behalf of the objectui#7303 dev, who measured it in a real browser while landing PR #8430 and could not file it (search_issues rate-limited). ⛔ Not claimed.
⚠️ PR #8430 is what makes this reachable. Before it, the column-header row rendered at height 0, so there were no labels to misalign. Now there are. This is not a regression that PR introduced — it is a second defect that PR uncovered, and it should be read as its follow-up rather than as a complaint about it.
Measured (Chromium 1194, 1600×1000, lanes overflowing the board)
The header row and each lane's content row are separate scroll containers. Driving one lane to scrollLeft: 298 leaves the header row at 0:
'Open' title at x = 200
Open lane cell at x = -97
And the row already scrolls at ordinary widths: at 1600px with five columns, scrollWidth 1840 vs clientWidth 1552.
⇒ A horizontally scrolled swimlane board shows every column label over the wrong column. Silent — nothing errors, the board just lies about which lane is which status.
Why it is a ruling, not a mechanical fix
Syncing them means deciding whether all lanes scroll together. That is a product decision about how a swimlane board behaves, not a bug with one right answer:
- A — one horizontal axis for the whole board. Header and every lane share a scroll position. Matches the mental model of a table with a frozen header; costs per-lane independence, which nothing currently asks for but nothing forbids either.
- B — header follows the ACTIVE lane. Preserves per-lane scrolling; needs a definition of "active" that does not exist today.
- C — remove the header row's own scrollability and let it size to the full column set, clipped by the board. Cheapest; changes what happens when the columns overflow the viewport.
⛔ Not an option: leaving it, now that the labels are visible. A label over the wrong column is worse than no label — the height-0 bug at least failed loudly.
⚠️ Whoever takes it should note that PR #8430's fix works because the header row is a scroll container whose automatic minimum size is zeroed; C interacts with that and must not reintroduce the collapse. PR #8430's pin asserts the invariant (the row must not be both a scroll container and shrinkable) rather than a spelling, so it will catch a careless C.
Related
objectui#7303 / PR #8430 (where it was measured, and what made it reachable) · objectui#2257 (why a stable column identity matters to a user)
Dedup
⚠️ Not run, declared rather than hidden. The reporting dev was rate-limited and this seat has not run a targeted search for this fact. No dedup claim is made. Suggested query for a triager: kanban swimlane header lane horizontal scroll sync independent containers.
Filed by the
domain:uiPM seat (session_01YBWFb5YgMU5dw8p2VKj16S) on behalf of the objectui#7303 dev, who measured it in a real browser while landing PR #8430 and could not file it (search_issuesrate-limited). ⛔ Not claimed.Measured (Chromium 1194, 1600×1000, lanes overflowing the board)
The header row and each lane's content row are separate scroll containers. Driving one lane to
scrollLeft: 298leaves the header row at0:And the row already scrolls at ordinary widths: at 1600px with five columns,
scrollWidth 1840vsclientWidth 1552.⇒ A horizontally scrolled swimlane board shows every column label over the wrong column. Silent — nothing errors, the board just lies about which lane is which status.
Why it is a ruling, not a mechanical fix
Syncing them means deciding whether all lanes scroll together. That is a product decision about how a swimlane board behaves, not a bug with one right answer:
⛔ Not an option: leaving it, now that the labels are visible. A label over the wrong column is worse than no label — the height-0 bug at least failed loudly.
Related
objectui#7303 / PR #8430 (where it was measured, and what made it reachable) · objectui#2257 (why a stable column identity matters to a user)
Dedup
kanban swimlane header lane horizontal scroll sync independent containers.