Closes #47. Adds onDragStart, onDragEnd, onResizeStart and onResizeEnd, completing the set that Mantine core FloatingWindow exposes: start, change and end for both gestures. Window had only the two change callbacks, and those fire on every frame — so persisting a layout meant debouncing by hand, and there was no moment to pause an expensive child, show a snap guide, or record one undo entry per gesture. Additive: four optional props, no default or behaviour change. WindowProps extends BoxProps and WindowBaseProps but NOT ElementProps<'div'>, so the DOM event names onDragStart/onDragEnd were never part of the public type and nothing is being shadowed. Both are destructured out of the props spread, which is what keeps them off the root element. Two things the implementation had to get right: - The global mouseup/touchend listener calls handleDragEnd() AND handleResizeEnd() whenever either gesture is active, so a naive end callback would emit an unpaired onDragEnd during a plain resize. Each hook now checks its own in-flight ref before firing. A regression test covers it, and removing the guard makes that test fail with "Expected 0, Received 1". - onDragStart is emitted only past the existing bail-outs: a press on a resize handle, on an interactive child, or on a data-no-window-drag region does not open a gesture that would never close. Unmounting mid-gesture fires the matching end, so a consumer that paused something on start is never left paused. There is no keyboard drag or resize in this component, so core's caveat about its resize callbacks not firing for keyboard resize has no equivalent here. Verified with real pointer events in Chrome, not only jsdom: across one drag and one resize the continuous callbacks fired 20 times and the lifecycle ones twice, with state going idle → dragging → idle → resizing → idle and no unpaired end.

Uh oh!

Commits

Commits on Sep 1, 2026

feat: drag and resize lifecycle callbacks