Auto-expand Note field up to 7 lines; floor manual resize at 1 line

[dconger-microsoft]

What

The Note field in the clipper now auto-expands as you type, up to a maximum of 7 lines; past that it scrolls.

Behavior

• Grows to fit content on each keystroke, capped at 7 lines (then overflow-y: auto).
• Manual drag-resize is preserved and remembered as a floor, so the field won't auto-shrink below a height you chose.
• If you collapse the field and then type more, it re-expands to fit the text (up to 7 lines).
• Manual resize can no longer shrink the field below a single line (min-height).
• Field size resets on sign-out.

Existing Behavior

Revised Behavior:

Changes

• src/renderer.html - note-field textarea starts at rows="1".
• src/styles/renderer.less - #note-field { min-height: 30px; }.
• src/scripts/renderer.ts - auto-grow logic (input / mousedown / mouseup listeners) + reset on sign-out.

Testing

Built locally with npm run build (tsc + eslint) - passes. The repo has no automated test suite (V3 validation = build); verified the bundle in the loaded unpacked extension.
Tested locally including cases of adding text, removing text, resizing the notes fielding, adding more text, etc.

[Copilot]

Pull request overview

This PR updates the Web Clipper renderer UI so the “Note” textarea auto-expands while typing (up to 7 lines) and enforces a 1-line minimum height, while still honoring a user’s manual resize as a remembered floor (reset on sign-out).

Changes:

• Set the Note textarea default to rows="1" so it starts at a single line.
• Add a CSS min-height to prevent manual resize below one line.
• Implement note auto-grow behavior in renderer.ts, including remembering manual resize as a floor and resetting size on sign-out.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
src/styles/renderer.less	Adds a 1-line minimum height for #note-field.
src/scripts/renderer.ts	Adds auto-grow logic, manual-resize floor tracking, and resets sizing on sign-out.
src/renderer.html	Changes Note textarea default rows from 2 to 1.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

[wikirby]

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.

[dconger-microsoft]

Great catch @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.

[wikirby]

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.