Fix exclusive-access crash in WindowDragHandleView hitTest

[harukitosa]

Summary

• Fix a crash caused by Swift exclusive-access violation in WindowDragHandleView.DraggableView.hitTest
• During mouseMoved events, SwiftUI's internal layout pass calls hitTest, which re-enters SwiftUI view state via windowDragHandleShouldCaptureHit, triggering a fatal access conflict
• Added early return for non-leftMouseDown events before calling the heavyweight function, avoiding SwiftUI re-entry entirely

Fixes #723

Root Cause

Simultaneous accesses to 0x6000029cc2a0, but modification requires exclusive access.
Fatal access conflict detected.

The crash occurs when:

1. A mouseMoved event triggers SwiftUI's internal state modification
2. SwiftUI calls hitTest on DraggableView during that modification
3. windowDragHandleShouldCaptureHit accesses SwiftUI-managed view properties before reaching the existing leftMouseDown guard, causing re-entry

Test plan

• Downloaded v0.61.0 release and reproduced the crash by moving the mouse over the titlebar area
• Built debug app with the fix and confirmed the crash no longer reproduces with the same steps

Summary by CodeRabbit

• Bug Fixes
  • Improved drag event handling to prevent interface issues that could occur during certain interactions. The application now properly restricts event processing, preventing unwanted behavior and stability issues during layout updates.

[vercel]

@harukitosa is attempting to deploy a commit to the Manaflow Team on Vercel.

A member of the Team first needs to authorize it.

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds a guard in DraggableView.hitTest to process only left mouse down events. This restricts hit-testing to left-click events exclusively, preventing re-entry into SwiftUI view state during layout passes and avoiding related crashes.

Changes

Cohort / File(s)	Summary
Hit-test Event Filtering Sources/WindowDragHandleView.swift	Added guard clause in DraggableView.hitTest to skip processing unless the current event is a left mouse down, preventing unintended state re-entry during layout passes.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Possibly related issues

• Issue #723: Directly addresses the reentrant hitTest/WindowDragHandleView crash on hover by filtering to left-mouse events only.

Possibly related PRs

• PR #620: Both modify DraggableView.hitTest hit-testing logic in WindowDragHandleView to restrict handling to left mouse down events with additional event validation checks.

Poem

🐰 A click from the left, not from the right,
Guards the drag with all of its might,
No more layout tangled in state,
The mouse moves free—oh, how it's great!

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title directly and specifically describes the main change: fixing an exclusive-access crash in WindowDragHandleView hitTest, which matches the primary objective of preventing SwiftUI re-entry during mouseMoved events.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[greptile-apps]

Greptile Summary

Fixes a Swift exclusive-access crash in WindowDragHandleView.DraggableView.hitTest by adding an early return for non-leftMouseDown events before calling functions that access view properties.

• Prevents re-entry into SwiftUI view state during layout passes triggered by mouseMoved, mouseEntered, and similar passive events
• The existing windowDragHandleShouldResolveActiveHitCapture guard was reached too late, after view properties had already been accessed
• Moving the event-type check to the very beginning of hitTest eliminates the crash while preserving all intended drag-handle behavior
• The fix was validated by reproducing the crash in v0.61.0 and confirming it no longer occurs with this change

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The fix is minimal, well-tested, and directly addresses a reproducible crash. It adds a simple guard clause that prevents re-entry into SwiftUI view state during layout passes, while preserving all intended functionality for leftMouseDown events.
• No files require special attention

Important Files Changed

Filename	Overview
Sources/WindowDragHandleView.swift	Adds early return in hitTest for non-leftMouseDown events, preventing exclusive-access crash during SwiftUI layout passes

_{Last reviewed commit: e95e6d5}