fix(hud): restore click-through at original bar position after drag#542
fix(hud): restore click-through at original bar position after drag#542Reedaaz wants to merge 1 commit into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe HUD bar wrapper structure in ChangesHUD wrapper pointer-events handling
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~15 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint skipped: no ESLint configuration detected in root package.json. To enable, add 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 |
Fixes #535
Problem
The HUD overlay wrapper kept
pointer-events: autoat its layout-original position. When the floating bar is dragged, only the innerhudBarTransformRefdiv shifts visually via CSStranslate3d— the outer wrapper stays put. Anymouseenteron that stale area still triggershandleHudMouseEnter→setIgnoreMouseEvents(false)on the full-screen HUD window, which then swallows clicks intended for the underlying app (Excel, browser, etc.).Fix
Move
pointer-events: autoand the mouse enter/leave handlers from the static wrapper onto the transformedhudBarTransformRefdiv, so the interactive hit area follows the bar's actual rendered position.Test plan
Summary by CodeRabbit