GeezerVison

The auto-grow-while-typing path is solid — caps cleanly at 7 lines with a working scrollbar. But the manual drag-resize floor is stored unclamped, and that one gap produces three visible bugs: dragging past 7 lines sticks forever, you can't drag back below the cap once you've got >7 lines of text, and the scrollbar disappears after a tall drag. Could we clamp the remembered floor to the 7-line max?

Repro'd each against a faithful copy of the CSS+JS (measured offset/scroll heights, not eyeballed). Details for whoever picks this up:

Root cause: getNoteMaxHeight() (the 7-line cap) governs only the auto-grow path. The mouseup handler stores userPreferredNoteHeight = noteField.offsetHeight with no clamp, and targetHeight = Math.max(fitHeight, userPreferredNoteHeight) then treats that unbounded value as a permanent floor.

• Drag past 7 lines sticks: floor of e.g. 300px persists across all later typing; the cap is never applied to the drag path. Partly preexisting — resize: vertical with no max-height has always allowed unbounded drag; what's new is persisting it.
• Can't drag smaller with >7 lines: the drag records the smaller height, but the next keystroke snaps back — fitHeight = Math.min(contentHeight, cap) pins at the cap when content exceeds 7 lines, overriding any floor below it.
• No scrollbar after a tall drag: overflowY keys off the inflated floor, not true content height — contentHeight > targetHeight ? "auto" : "hidden" goes hidden once the floor exceeds content.

Suggested fix — two small changes that resolve all three:

1. Clamp the floor on mouseup: userPreferredNoteHeight = Math.min(noteField.offsetHeight, getNoteMaxHeight()).
2. Add a matching max-height to #note-field so the native drag handle can't physically exceed the cap even before JS runs (keep it in sync with NOTE_MAX_LINES).

With the floor clamped to the cap, overflowY naturally keys off content vs. cap and the scrollbar returns.

Great catch Eric Chen (@wikirby) — thanks for the precise, measured repro. Fixed in ba8975f with both suggested changes:

1. Clamp the floor on mouseup: userPreferredNoteHeight = Math.min(noteField.offsetHeight, getNoteMaxHeight()).
2. Add max-height: 150px to #note-field (7 × 20px line-height + 8px padding + 2px border) so the native resize handle can't drag past the cap, mirroring NOTE_MAX_LINES.

With the floor clamped to the cap, overflowY keys off content vs. cap, so the scrollbar returns. All three repros (drag-past-7 sticking, can't-shrink-below-cap-with->7-lines, missing scrollbar) now behave.

Separate from the floor bug — the auto-grow has no blur/focusout handler, so a typed-out 7-line note permanently holds ~150px of the sidebar even after the user moves on (it only shrinks while you're actively deleting text). Pre-PR the field was fixed at 2 rows, so its footprint was bounded regardless of content. Is the always-on expansion intended, or should it collapse back when it loses focus?

Where this is most likely to hurt: PDF mode stacks the most controls into the same sidebar column (pdfOptionsPanel — range radios + input, attach checkbox, size warning, distribute checkbox) against the 600–900px sidebar cap, so an idle expanded note there is the most likely to push controls below the fold. Selection mode (context-menu invoked) shares the same field with a bit more room.

One option: keep the 7-line expansion while focused, but collapse to ~2 lines (scrolled) on blur and re-expand on focus — preserves the editing benefit without the resting-state cost. A smaller or mode-aware cap would be a lighter alternative.