Two issues with the block-handle grip the user just hit:
1. Same flicker pattern the inserter had before its fix: the
handle's listener was on `[data-words-content]`, and the grip
sits OUTSIDE that box in the gutter. The moment the cursor
moved toward the grip, `mouseleave` fired on content → grip
vanished → cursor back inside content → grip reappeared → loop.
2. The 24×24 hit area sitting in a 28-px-wide gutter was hard to
land, especially when the gutter also got the flicker treatment.
Fixes:
- **Document-level mousemove** (was: content-level). Bounds are
checked manually against the content rect with an EXPANDED buffer
on the side where the grip lives (56 px) and a tight 8 px on the
opposite. Drawer side is read from the DOM so the bounds flip
automatically with `<Words.Drawer side="left">`.
- **Early-return when the cursor is over the handle or its menu**
(`target.closest('[data-words-block-handle]' | '...-menu')`) so
hovering the grip itself never recomputes/hides the state.
- **Geometric fallback** when the cursor is in the gutter and
`findBlockElement(e.target)` would return null: walk the top-level
blocks and pick the one whose vertical band contains `e.clientY`.
Keeps the grip pinned to the right block while the user is
moving toward it.
- **Mouseleave listener removed entirely** — the bounds check above
handles the "cursor truly left the editor area" case without the
flicker-prone per-element leave events.
- **Hit area bumped to 28×28** (`1.75rem`) so it's comfortably above
WCAG 2.5.5's 24×24 minimum and easier to grab in the narrow
gutter. Visible icon stays at `size="sm"`. Centering math updated
(-14 instead of -12); horizontal offset bumped from `-28` to
`-32` to keep a small gap between grip and text descenders.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
active-uix
parent
4cd54e2111
commit
2bf6aef035
Loading…
Reference in new issue