Fix resize handles overlapping the note scrollbar buttons #17

Merged

Lemarkis merged 1 commit from fix/resize-handle-scrollbar-overlap into main

2026-09-18 11:22:22 +00:00

Lemarkis commented

2026-09-18 11:18:36 +00:00

Owner

Summary

Found while testing PR #11 on Windows: a note's own scroll buttons (the up/down/left/right arrows at the ends of its scrollbar) could be unclickable, most often near the bottom corners.

A scrollbar always sits flush with its element's own border edge - CSS padding doesn't move it, only the content next to it. .body's border was flush with .note's own edges, so its scrollbar (and a nested horizontally-scrolling <pre>'s, once its own padding is added on top) rendered directly under the invisible resize-e/w/s/se/sw handles, swallowing clicks meant for the scrollbar itself.

Fix

Gives .body a small margin clear of the resize handles.
Shrinks the corner handles from 8px down to 4px (matching the edge handles), so the margin - and the resulting border visible around the note's content - stays unobtrusive, after iterating down from an initial 8px based on feedback during testing.

Testing

Automated: npm run check (0 errors), npm run test (150 passing) - unaffected, this is a CSS-only change.
Manually confirmed on Windows/x86_64: scroll buttons are clickable again, both with only a vertical scrollbar and with vertical+horizontal scrollbars together (a note with a wide code block and enough text to also need vertical scroll).
Linux/ARM64: pending - tracked in PENDING_CROSS_PLATFORM_TESTS.md.

🤖 Generated with Claude Code

## Summary Found while testing PR #11 on Windows: a note's own scroll buttons (the up/down/left/right arrows at the ends of its scrollbar) could be unclickable, most often near the bottom corners. A scrollbar always sits flush with its element's own border edge - CSS padding doesn't move it, only the content next to it. `.body`'s border was flush with `.note`'s own edges, so its scrollbar (and a nested horizontally-scrolling `<pre>`'s, once its own padding is added on top) rendered directly under the invisible resize-e/w/s/se/sw handles, swallowing clicks meant for the scrollbar itself. ## Fix - Gives `.body` a small margin clear of the resize handles. - Shrinks the corner handles from 8px down to 4px (matching the edge handles), so the margin - and the resulting border visible around the note's content - stays unobtrusive, after iterating down from an initial 8px based on feedback during testing. ## Testing - Automated: `npm run check` (0 errors), `npm run test` (150 passing) - unaffected, this is a CSS-only change. - Manually confirmed on Windows/x86_64: scroll buttons are clickable again, both with only a vertical scrollbar and with vertical+horizontal scrollbars together (a note with a wide code block and enough text to also need vertical scroll). - Linux/ARM64: pending - tracked in `PENDING_CROSS_PLATFORM_TESTS.md`. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

Lemarkis added 1 commit

2026-09-18 11:18:36 +00:00

Fix resize handles overlapping the note's own scrollbar buttons

CI / frontend (pull_request) Successful in 25s

Details

CI / backend (pull_request) Successful in 2m40s

Details

5e6ceb0f36

Found while testing PR #11 on Windows: a note's scroll buttons (the
up/down/left/right arrows at the ends of its scrollbar) could be
unclickable, most often near the bottom corners.

A scrollbar always sits flush with its element's own border edge - CSS
padding doesn't move it, only the content next to it. .body's border
was flush with .note's own edges, so its scrollbar (and a nested
horizontally-scrolling <pre>'s, once its own padding is added on top)
rendered directly under the invisible resize-e/w/s/se/sw handles,
swallowing clicks meant for the scrollbar itself.

Gives .body a small margin clear of the handles, and shrinks the
handles themselves (8px corners down to 4px, matching the edges) so
the margin - and the resulting border around the note's content -
stays unobtrusive.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>