Summary
On Windows, double-clicking a cell to edit shows scrollbars on the bottom and right edges of the inline editor, shrinking the visible text area to roughly 40% of the cell. You can't see the text you're editing.
Reported by @SweetSophia in #1:
when I click on a cell in Windows, I get scrolling bars bottom and right at the cell, shrinking the visible text area to like 40%, meaning I can't see anymore what I edit at all.
Root cause
The inline cell editor is a <textarea> sized to the cell (ROW_HEIGHT = 28px, VirtualTable.tsx) with:
/* app/frontend/src/App.css */
textarea.vt-cell-editor {
resize: none;
overflow: auto; /* scrollbars appear on any overflow */
white-space: pre; /* no wrapping → wide content overflows horizontally */
}The behavior differs by platform because of how the OS renders scrollbars:
- macOS uses overlay scrollbars (semi-transparent, auto-hiding, drawn on top of content). They consume no layout space, so the maintainers — who work exclusively on macOS — never saw this.
- Windows (WebView2 / Chromium) uses classic scrollbars that take ~17px of physical layout space.
With a 28px-tall editor, a horizontal scrollbar leaves 28 − 17 = 11px for text — ~39%, matching the reported "40%". A vertical scrollbar additionally eats ~17px of the column width.
No ::-webkit-scrollbar or scrollbar-width styling exists anywhere in the project, so the editor inherits the platform default.
Decision: auto-grow inline editor
Rather than mitigating the scrollbar size, remove the need for scrollbars in the common case. When editing begins, the editor should grow beyond the cell bounds to fit its content (downward for multi-line / RFC 4180 embedded newlines, rightward/wrapping for long single-line values), rendered as an overlay above the neighboring cells (like Excel / Numbers). Scrollbars then only appear for pathological content, and we can style those thin as a fallback if needed.
This is a lighter-weight take on the modal CellEditDialog @SweetSophia prototyped in #1 — it solves the same real problem without changing the editing model to a full-screen dialog.
Acceptance criteria
Notes
Summary
On Windows, double-clicking a cell to edit shows scrollbars on the bottom and right edges of the inline editor, shrinking the visible text area to roughly 40% of the cell. You can't see the text you're editing.
Reported by @SweetSophia in #1:
Root cause
The inline cell editor is a
<textarea>sized to the cell (ROW_HEIGHT = 28px,VirtualTable.tsx) with:The behavior differs by platform because of how the OS renders scrollbars:
With a 28px-tall editor, a horizontal scrollbar leaves
28 − 17 = 11pxfor text — ~39%, matching the reported "40%". A vertical scrollbar additionally eats ~17px of the column width.No
::-webkit-scrollbarorscrollbar-widthstyling exists anywhere in the project, so the editor inherits the platform default.Decision: auto-grow inline editor
Rather than mitigating the scrollbar size, remove the need for scrollbars in the common case. When editing begins, the editor should grow beyond the cell bounds to fit its content (downward for multi-line / RFC 4180 embedded newlines, rightward/wrapping for long single-line values), rendered as an overlay above the neighboring cells (like Excel / Numbers). Scrollbars then only appear for pathological content, and we can style those thin as a fallback if needed.
This is a lighter-weight take on the modal
CellEditDialog@SweetSophia prototyped in #1 — it solves the same real problem without changing the editing model to a full-screen dialog.Acceptance criteria
CellEditorbehavior) are preserved.Notes