Repository navigation
feat(studio): add a preview seek bar - #6103
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Automations to automatically generate PRs for you. |
Edit accuracy: accurate 271 (base branch 271), smooth 140 of thoseThe gate passes. Quarantined, measured but not gated (0) |
![heygengenesis[bot]](https://avatars.githubusercontent.com/in/2913576?s=60&v=4){kind=small}
There was a problem hiding this comment.
Verdict: COMMENT (needs human): 1 blocker, 0 important, 0 nits, at e35b70325. I'm holding approval because the required check Studio: edit accuracy gate fails, and this PR causes the failure. ↓ inline
Scope
I read all 4 files end to end. I checked the seek path through useTimelinePlayer.seek: it pauses unless keepPlaying is set, which matches the docs. I also checked liveTime subscribe/unsubscribe cleanup. CI: every other required job passed. In the gate artifacts, the regressed case fails 3 of 3 runs (shard 5) with the same coordinates each time, so it is deterministic and not flaky.
There was a problem hiding this comment.
Verdict: APPROVE: 1 resolved, 0 open, 0 new blockers, 2 nits · e35b70325 → 14c968f09
The preview-height blocker is fixed: the transport is back to 40px (h-3 seek row plus h-7 controls), and the edit accuracy gate now passes at 271 vs 271 on base. All required checks are green on this head.
Nits (non-blocking)
PreviewSeekBar.tsx:43: the h-6 input inside an h-3 row overhangs the stage by about 6px. Because the controls wrapper is now z-20, that strip sits aboveDomEditOverlay(z-10). It is mostly inside the 8px stage inset, but it covers part of the bottom selection handles on elements that touch the composition's bottom edge, and at zoom above 100% clicks in that band seek instead of hitting the canvas.PlayerControls.tsx:225:relative z-20creates a stacking context, soSpeedMenu'sz-50popover is now effectively z-20. When it opens upward over the stage, it now paints underMotionPathOverlay(z-40). That's visual only.
Smoothness (not gated) reads 140 vs 161 on the earlier head. I'm noting it here without treating it as a finding.
What
Add a seek bar above the preview playback controls in OSS Studio. Click, drag, or use the keyboard to scrub without opening the timeline, including in fullscreen.
Why
The preview had playback controls but no seek bar. With the timeline hidden or the preview in fullscreen, users had no direct way to scrub through the video.
Related work
User request and fullscreen/hidden-timeline use case.
How
Use a native range input connected to the existing seek handler and live playback clock. The seek bar and buttons share the original 40-pixel transport height, preserving the preview stage size. The native input retains its full rendering height above the preview selection layer so the thumb is visible and clickable without clipping. Seeking retains the timeline's pause behavior. The control follows playback without per-frame React renders and stays disabled until the preview is ready and has a duration.
Test plan
seqab-none-center-r0-*-z100editing sequences passed locally against the rebuilt Studio. Browser measurements confirm the transport is 40px and the preview regained 24px. The original failing case also passes locally on macOS; Linux CI remains the regression confirmation. No baseline or harness changes.Validation passed: Studio typecheck, oxlint, oxfmt, Fallow audit, workspace build, and the updated Studio production build. The audit reports only an inherited complexity finding in PlayerControls.
Before
The preview has a timecode and playback buttons but no seek bar.
After
The preview seek bar stays synchronized with the timeline playhead.
Fullscreen and hidden-timeline checks: