Repository navigation
[Bug]: New project name dialog cannot scroll past environment and options rows #17053
Description
Before submitting
- I searched existing issues and did not find an exact duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web (also used by the desktop renderer)
Steps to reproduce
- Have three connected environments available for project creation and an authenticated GitHub source-control account.
- Open Add project, then New project (the name-based creation flow, not the clone destination picker).
- At a 1280 × 800 CSS-pixel viewport, leave the name blank. The dialog shows the project/path preview, Environments, three machine rows, Options, the GitHub repository toggle, and Add existing project.
- Try to scroll downward in the results area using the mouse wheel/trackpad or the scroll container.
Expected behavior
The results area scrolls within the space between the project preview and keyboard-shortcut footer. Every environment, option, and the complete Add existing project row can be brought into view. The name input, Create action, and footer remain usable.
Actual behavior
Add existing project is clipped behind the Navigate / Enter / Backspace / Esc footer. The list reports no scrollable overflow, so trying to scroll does nothing.
The reporter's macOS screenshot shows the same New Project name/environment screen with three environments; its lower options are cut off.
Impact
Minor bug or occasional failure: options in project creation are obscured and cannot be reached by scrolling.
Version or commit
Reproduced against upstream main at 9fba209 (web package 0.0.45). The reporter's installed build version was not supplied.
Environment
macOS host, T3 Code collaborative Chromium browser, 1280 × 800 viewport. Electron was not separately run.
For a deterministic isolated reproduction, I used the actual New Project UI and added two disposable presentation-only environment options beside its real local environment. This reproduced the three-row layout without connecting to the reporter's remote machines. No project creation or remote operation was performed. Development state was isolated from the live installation.
Investigation and local PR comparison
Related: #10829 and #10844. Those describe and test the clone destination picker, not this name/environment/options step. Both remain open. #6159 is specifically PageUp/PageDown navigation, which is a different symptom.
New Project by name was introduced in #14527. The current command palette uses the virtualized results added in #15266.
Relevant code:
apps/web/src/components/CommandPalette.tsx: the project/path preview is a sibling aboveCommandPaletteVirtualizedResults.apps/web/src/components/CommandPaletteContent.tsx: the default results panel is capped but is not a flex column.apps/web/src/components/ui/command.tsx:CommandPanelclips overflow;CommandListVirtualizedlacksmin-h-0.apps/web/src/components/ui/autocomplete.tsx:AutocompleteListVirtualizedappliessize-full.apps/web/src/components/CommandPaletteResults.tsx: the inner LegendList owns scrolling.
Measured on main:
- Popup height: 420 px.
- Panel: y=129–459, height 330 px; overflow hidden.
- Project preview consumes 56 px above the list.
- List starts at y=185 but still takes the entire 330 px panel height.
- Inner scrollport has clientHeight=318 and scrollHeight=318, with scrollTop=0 after a downward scroll attempt.
- Final row is y=447–495; the footer starts at y=459, so most of that row is clipped.
I fetched #10844 at d4fa8ce. Its exact patch no longer applies to current main because the panel-class prop has since been replaced by panelSize. I ported only its two equivalent changes locally: flex/min-h-0/flex-col on the default panel, and shrink-0 on the Repository header.
That port did not fix the New Project screen. The virtualized list wrapper retained its automatic minimum height: the scrollport remained 318 px high with scrollHeight=318 and scrollTop=0, and the final row was still y=447–495 behind the footer.
As a diagnostic experiment, setting min-height: 0 on the virtualized command-list wrapper in addition to the ported panel fix let it shrink to the remaining 274 px. The scrollport then had scrollHeight=318, accepted scrollTop=44, and displayed the final row at y=403–451, fully above the footer. This identifies the missing sizing constraint; it is not a completed or regression-tested implementation.
Acceptance criteria
- All rows in the New Project name/environment/options step scroll fully into view, including the last Add existing project row.
- The project preview, name input/Create action, and keyboard-shortcut footer remain visible and usable.
- Verify the three-environment layout and a larger environment list, including a shorter viewport.
- Preserve mouse/trackpad scrolling, arrow-key highlight visibility, and existing clone/local-folder browsing behavior.
- Keep the change focused on shared web/desktop palette layout; no contracts, provider behavior, or dependency changes are expected.
Workaround
No user-facing workaround confirmed. The additional minimum-height constraint above was tested only as a local diagnostic.
Activity
juliusmarminge commentedon Oct 8, 2026
Note
Grok responding on behalf of Julius.
Thanks for the detailed write-up and measurements. Triage against
main@9fba209:Root cause (confirmed by reading the code)
The New project flow uses the shared palette chrome. Its results panel is a plain block box, but the virtualized list inside it is sized as if it were the panel's only child:
max-h-105,flex min-h-0 flex-col):apps/web/src/components/ui/command.tsx:64-69,apps/web/src/components/ui/dialog-styles.ts:7-8.CommandPanelismin-h-0 overflow-hidden, so it shrinks to whatever space the input and footer leave and clips anything past that:ui/command.tsx:151-160.panelSize, so it gets the default"list"panel, which is onlymax-h-[min(28rem,70vh)]and isn't a flex container. Only"fill"getsflex min-h-0 flex-1 flex-col:apps/web/src/components/CommandPaletteContent.tsx:56-63.apps/web/src/components/CommandPalette.tsx:3495-3512. The same applies to the clone flow's Repository header (:3513-3526) and the browse status rows (:3527-3535). The results follow at:3536.CommandListVirtualizedisflex max-h-[inherit] flex-col(ui/command.tsx:129-140) on top ofAutocompleteListVirtualized'ssize-full min-w-0(apps/web/src/components/ui/autocomplete.tsx:173-181). It has nomin-h-0and isn't told to take only the remaining space. The LegendList inside is the actual scroller (apps/web/src/components/CommandPaletteResults.tsx:120-154).So the list wrapper is sized against the full panel instead of the panel minus the preview. It overflows the panel by the preview's height,
overflow-hiddenclips the overflow, and the inner scroller has nothing to scroll because it already fits its own box. That matches your numbers: a 330 px panel, a 56 px preview, and a list still 330 px tall.Why porting #10844 alone wasn't enough (checked mechanically)
Making the panel
flex flex-col min-h-0lets the panel act as a flex container. However, flex items default tomin-height: auto, and the list wrapper isn't a scroll container itself (the LegendList inside it is). Its automatic minimum size is therefore its content height, so it refuses to shrink below the scroller's content.min-h-0on the wrapper removes that floor. That matches your result: 274 px of remaining space, andscrollTop44 became reachable. For comparison, the non-virtualized path'sScrollArearoot already carriesmin-h-0and is the overflow element itself (ui/scroll-area.tsx:49-60).Suggested fix direction
"list"/"tall-list"panels flex columns as well (flex flex-colalongside their existingmax-h-*) inCommandPaletteContent.tsx:56-63.CommandListVirtualizedmin-h-0 flex-1(or at leastmin-h-0) inui/command.tsx:135.CommandPalette.tsx:3495-3535shrink-0so the list absorbs the squeeze, not the preview.A regression test that puts a header plus enough rows in the palette and asserts the last row can be scrolled above the footer would cover both this and #10829.
Related work
[&::-webkit-scrollbar-track]:my-2to the LegendList class inCommandPaletteResults.tsx:150. It's cosmetic (scrollbar track inset), doesn't touch panel or wrapper sizing, and won't fix this. It touches a neighbouring file, so a conflict with the change above seems unlikely.panelClassNameprop that has since been replaced bypanelSize, so it no longer applies as-is. It only does step 1 plusshrink-0on the Repository header. Per your experiment that isn't sufficient without the wrappermin-h-0. A single fix in the shared chrome could likely cover both flows (untested).Not confirmed here
CommandPaletteContentusers of the"list"/"tall-list"panel (ProjectFilePicker,ProjectFaviconPickerDialog) once the panel becomes a flex column. Those should be checked visually.