Skip to content

fix(appkit): map synthetic drags with the current window frame - #2

Merged
Kyle-Ye merged 1 commit into
mainfrom
feature/drag_gesture
Oct 17, 2026
Merged

Kyle-Ye merged 1 commit into
mainfrom
feature/drag_gesture

Conversation

@Kyle-Ye

@Kyle-Ye Kyle-Ye commented Oct 16, 2026

Copy link
Copy Markdown
Member

Dragged mouse events carry deltas, so mouseMove(to:) sets them on the event's CGEvent and rebuilds the event with NSEvent(cgEvent:). That initializer maps the global location back with the window server's geometry instead of NSWindow.frame, and AppKit updates that geometry asynchronously. The first drag after a window was created or moved could land far outside the window, for example at (-200, -1964) instead of (100, 100), so drag gestures started before reaching their minimum distance.

Keep HammerWindow at a fixed off-screen position while it is hidden, as WebKitTestRunner does for its test window: origin changes are ignored and only size changes apply. On macOS, isWindowReady also requires a probe event to round-trip through NSEvent(cgEvent:) unchanged, so waitUntilWindowIsReady() waits until a new window maps locations correctly. Dragged events keep their deltas.

Validation: all 18 AppKit tests pass on macOS 26.6.2, and strict SwiftLint passes. SwiftUI and OpenSwiftUI drag gesture integration tests, including a minimum-distance case that failed before, pass on macOS 26.6.2.

@Kyle-Ye
Kyle-Ye merged commit 2c0b007 into main Oct 17, 2026
5 checks passed
@Kyle-Ye
Kyle-Ye deleted the feature/drag_gesture branch October 17, 2026 05:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant