fix(desktop): an overflowing Author tree scrolls instead of crushing rows - #484
Merged
physercoe merged 1 commit intoJul 30, 2026
Conversation
…rows The Author nav's .author-nav-sec.grow had flex:1 + min-height:0 but no overflow-y: when the tree exceeds the section height the flex column compresses its direct children — root-level file rows rendered 11px tall while rows nested in dir wrapper divs kept 26px (visible as two row heights, the shorter ones at the bottom of the list). Give the section overflow-y:auto so it scrolls, and flex-shrink:0 on its children so rows always keep their content height. Regression e2e: seed a 65-file workspace, assert uniform row heights + the section scrolls (fails without the fix: maxH-minH of 26px vs 11px rows).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The Author surface's workspace tree crushes rows when its content overflows instead of scrolling: root-level file rows render 11px tall while rows nested inside directory wrapper divs keep their full 26px — visible as two row heights in the same list, the squashed ones illegible (12px text in an 11px row).
Reported by a user whose
research/folder (expanded by default, like all top-level dirs) holds enough entries to overflow the nav: the expanded dir's children looked fine, every root-level file below was squashed.Root cause
.author-nav-sec.grow(desktop/src/styles/partials/09-canvas-tail.css) isflex: 1; min-height: 0— a flex column that fits its parent — but has nooverflow-y. When the tree exceeds the available height there is nothing to scroll, so the flex layout compresses its children: direct-child file rows (.author-nav-item filebuttons) shrink below their content height, while directory rows survive inside their plain-<div>wrappers (the wrapper shrinks; the row inside doesn't). Latent since the styles split (120937ff) — it fires only once a workspace grows enough entries to overflow.Fix
.author-nav-sec.growgetsoverflow-y: auto— the section scrolls..author-nav-sec.grow > *getsflex-shrink: 0— rows always keep their content height even if the overflow rule is ever defeated.Two-selector, six-line CSS change; no new tokens (ratchet clean).
Regression coverage
New e2e
desktop/electron/e2e/author-nav-overflow.spec.ts: seeds a 65-file workspace (60 root files + a dir of 5), then asserts every.author-nav-itemrow is within 2px of the tallest and the section actually scrolls.Verified locally (macOS, real Electron):
scrollHeight > clientHeight✅maxH - minH ≤ 2(11px vs 26px rows) ✅ — the test pins the bug, not just the shapeThe user's exact state (their workspace copy + their 5 open drafts) was also reproduced end-to-end during diagnosis; the fix renders it uniformly.
Verification
lint-desktop-tokens.shclean (afternpm run sync:tokens— the generated primitives file is git-ignored)