fix(studio): support drag on FlatSlider, not just click-to-set#2186
fix(studio): support drag on FlatSlider, not just click-to-set#2186vanceingalls wants to merge 1 commit into
Conversation
miga-heygen
left a comment
miga-heygen
left a comment
There was a problem hiding this comment.
Reviewed as part of the 15-PR edit-panel redesign stack. Full stack review posted on #2120. No blockers on this PR. — Miga
Only onPointerDown was wired, so dragging the knob/track only ever committed the initial click position — nothing tracked the pointer after that. Uses the Pointer Capture API (setPointerCapture on pointerdown, onPointerMove while captured, release on pointerup) so the value follows the cursor continuously during a drag, matching how the legacy native <input type="range"> control behaves for free. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
miguel-heygen
left a comment
miguel-heygen
left a comment
There was a problem hiding this comment.
Final current-head pass: ad36891. Reviewed the stack boundaries and current diff against the flat-inspector contracts; required checks have no failures/pending checks and no unresolved review threads remain. No new drift found; residual notes are non-blocking.
vanceingalls
force-pushed
the
studio-flat-12-slider-hit-area
branch
from
a88b530 to
fd1fb17
Compare
vanceingalls
force-pushed
the
studio-flat-13-slider-drag
branch
from
ad36891 to
102c503
Compare
miguel-heygen
left a comment
miguel-heygen
left a comment
There was a problem hiding this comment.
Superseding earlier approval: the latest max-review pass found confirmed correctness issues in this flat-inspector stack (identity/selector-index state, hide-all write races, timing inference, slider pointer/keyboard/reset semantics, and duplicate React keys). Hold merge and require fixes plus re-review on the current stack head.
3 participants
What
Thirteenth PR in the flat inspector stack (see #2120 for the foundation and full stack list). Adds real drag support to
FlatSlider— dragging the track/knob now moves the value continuously with the cursor, matching how a native<input type="range">behaves.Stack: #2120 → ... → #2142 → #2186 (this).
Why
Reported directly after using the redesigned inspector live — only
onPointerDownwas ever wired on the slider's track, so a click set the value once but dragging did nothing further; the value stayed pinned to wherever the mouse first went down.How
onPointerMove/onPointerUpalongside the existingonPointerDown, using the standard Pointer Capture API:setPointerCaptureon pointerdown so the element keeps receiving move events even if the cursor leaves its bounds mid-drag,onPointerMoverecomputes and commits the value from the currentclientXwhile capture is held, andonPointerUpreleases capture.SliderControluses a native<input type="range">, which gets drag for free from the browser;FlatSlideris a custom-drawn track/knob div with no such built-in behavior, so this needed explicit wiring.Test plan
setPointerCapturefor untrusted/script-dispatched pointer events, which is worth knowing if this needs re-testing later): drove an actual mouse-down + mouse-move sequence via CDP-level input and confirmed the slider's value tracked the drag's live position, not just the initial click.oxlint/oxfmt/fallowclean.