Keep HUD interactive on Linux so the drag handle can receive pointer events#17
Merged
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthrough
ChangesLinux HUD Mouse Event Handling
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
1 task
EtienneLescot
added a commit
that referenced
this pull request
Jul 1, 2026
Bugs from the spine test pass: #4 - clips display as 60s instead of the real video length. Root cause: insertClipAt falls back to PLACEHOLDER_DURATION_SEC (60s) when asset.durationSec is undefined, and the loadedmetadata auto-correct (handleLoadedMetadata) didn't fire reliably (in the browser-shim the preview path is unreliable; in the real Electron window the preview <video> remounts only when the activeSource swaps, so a freshly-added asset's metadata never reaches the auto-correct). Fix: probe the file directly via a throwaway <video> (src/lib/ai-edition/timeline/duration.ts, 5 unit tests) and insert the clip at the real duration synchronously. Persist the probed duration back onto the asset so subsequent inserts don't re-probe. Falls back to PLACEHOLDER on probe failure. #17 - dragging a skip's left/right chevron appeared to move the whole skip instead of just one edge. Root cause: clipSegments() was called once with the source skipRanges, then the cut segment was patched with dragPreview.startSec/endSec - but the surrounding keep segments weren't regenerated, so their flex widths didn't shrink to make room and the cut's visual position drifted. Fix: build a virtual skipRanges with the dragPreview'd bounds and re-run clipSegments() end-to-end so keep+cut stay consistent. #18 - clicking the trash button on a skip didn't remove it. Root cause: startClipReorder calls setPointerCapture on the clip block, so the subsequent pointerup is captured on the block (not the trash button) and the click event fires on the block (not the button). Fix: stop pointerdown propagation on the trash button so the clip block never captures the pointer. #5/#19 - clips were overlapping by 1px (the join-border overlap from T09). User: this is NOT wanted for clips - only for skip strips inside a clip. Fix: remove the JS left/width shift on hasJoinedPrev. CSS .joinedPrev/.joinedNext still zero the adjacent border-radius + border-width so corners blend. #6 - the reorder marker wasn't visible. Root cause: z-index 11, but the moving clip has z-index 20, and the marker's soft box-shadow was only 8px so it disappeared against dark backgrounds. Fix: bump width to 4px, z-index to 30 (above the moving clip), and stronger box-shadow. Verified: tsc clean, biome clean, 412 tests pass.
EtienneLescot
added a commit
that referenced
this pull request
Jul 2, 2026
Bugs from the spine test pass: #4 - clips display as 60s instead of the real video length. Root cause: insertClipAt falls back to PLACEHOLDER_DURATION_SEC (60s) when asset.durationSec is undefined, and the loadedmetadata auto-correct (handleLoadedMetadata) didn't fire reliably (in the browser-shim the preview path is unreliable; in the real Electron window the preview <video> remounts only when the activeSource swaps, so a freshly-added asset's metadata never reaches the auto-correct). Fix: probe the file directly via a throwaway <video> (src/lib/ai-edition/timeline/duration.ts, 5 unit tests) and insert the clip at the real duration synchronously. Persist the probed duration back onto the asset so subsequent inserts don't re-probe. Falls back to PLACEHOLDER on probe failure. #17 - dragging a skip's left/right chevron appeared to move the whole skip instead of just one edge. Root cause: clipSegments() was called once with the source skipRanges, then the cut segment was patched with dragPreview.startSec/endSec - but the surrounding keep segments weren't regenerated, so their flex widths didn't shrink to make room and the cut's visual position drifted. Fix: build a virtual skipRanges with the dragPreview'd bounds and re-run clipSegments() end-to-end so keep+cut stay consistent. #18 - clicking the trash button on a skip didn't remove it. Root cause: startClipReorder calls setPointerCapture on the clip block, so the subsequent pointerup is captured on the block (not the trash button) and the click event fires on the block (not the button). Fix: stop pointerdown propagation on the trash button so the clip block never captures the pointer. #5/#19 - clips were overlapping by 1px (the join-border overlap from T09). User: this is NOT wanted for clips - only for skip strips inside a clip. Fix: remove the JS left/width shift on hasJoinedPrev. CSS .joinedPrev/.joinedNext still zero the adjacent border-radius + border-width so corners blend. #6 - the reorder marker wasn't visible. Root cause: z-index 11, but the moving clip has z-index 20, and the marker's soft box-shadow was only 8px so it disappeared against dark backgrounds. Fix: bump width to 4px, z-index to 30 (above the moving clip), and stronger box-shadow. Verified: tsc clean, biome clean, 412 tests pass.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #12
Problem
On Linux (Manjaro KDE Wayland), the HUD launch widget shows a drag handle but cannot be moved: clicks on the handle have no effect and the window stays stuck in place. macOS and Windows are unaffected.
Root cause
LaunchWindowtoggles the HUD overlay intosetIgnoreMouseEvents(true)whenever the pointer leaves interactive regions. On macOS/Windows this is fine becausesetIgnoreMouseEventsonly affects regions marked as "transparent" — but on Linux/Wayland the whole window stops receiving pointer events, so the drag handle never sees thepointerdownthat starts a drag.Fix
In
src/components/launch/LaunchWindow.tsx, treat the HUD as always interactive on Linux:getPlatform()and keep anisLinuxHudflag.shouldIgnoreMouseEvents = falseon Linux.Test
Added a unit test in
src/components/launch/LaunchWindow.test.tsx:getPlatformto returnlinux.LaunchWindowand assertssetHudOverlayIgnoreMouseEventsis called withfalse, so the HUD stays clickable.Validation
npx vitest --run src/components/launch/LaunchWindow.test.tsxpasses.npm run build-vitepasses.Summary by CodeRabbit
Release Notes