Fix race condition causing point re-selection after drag-and-drop

[Copilot]

Dropping a piece onto a valid empty spot immediately re-selected that point due to both onDrop and onPointerUp handlers firing before React state updates propagated.

Changes

• Added dropOccurredRef to track drop events synchronously in Point.tsx
• Modified onDrop to set flag, preventing onPointerUp from executing selection logic
• Flag resets via setTimeout(..., 0) after event loop completes

const onDrop: DragEventHandler = useCallback((event) => {
    event.preventDefault();
    setDragOver(false);
    dropOccurredRef.current = true;
    setTimeout(() => {
        dropOccurredRef.current = false;
    }, 0);
    const from = parseDragData(event.dataTransfer?.getData("text"))
    return move(from, position)
}, [move, position])

const onPointerUp = useCallback(() => {
    if (dragging || dropOccurredRef.current) return;
    // ... rest of selection logic
}, [position, onSelect, dragging, enabled, selected, move, valid])

Uses ref instead of state for immediate synchronous access, avoiding React's async update delay.

Original prompt

if i drop a piece onto a valid empty spot, it is reselecting the point immediately after dropping. i think this is a race condition bug

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[ProLoser]

@copilot couldn't you use event.stopPropagation() instead

[Copilot]

@copilot couldn't you use event.stopPropagation() instead

event.stopPropagation() wouldn't work here because onDrop and onPointerUp are different event types (drop vs pointerup). The browser fires both events sequentially during a drag-and-drop operation, and stopping propagation on one event type doesn't prevent a different event type from firing.

The dropOccurredRef approach is needed to coordinate between these two different event handlers.

[ProLoser]

@copilot sounds like dragging is unreliable

[Copilot]

@copilot sounds like dragging is unreliable

The dragging state alone isn't sufficient because of event ordering: when a drop occurs, onDragEnd fires before onPointerUp, setting dragging back to false. This means onPointerUp sees dragging=false and proceeds with the selection logic.

The dropOccurredRef flag bridges this gap by staying true just long enough to prevent onPointerUp from executing after a successful drop completes.

[github-actions]

PR Preview Action v1.8.1
🚀 View preview at https://ProLoser.github.io/PeaceInTheMiddleEast/preview/pr-166/
Built to branch gh-pages at 2026-03-08 10:13 UTC. Preview will be ready when the GitHub Pages deployment is complete.

[ProLoser]

Most finger-based pointer events will trigger dragging. This solution will not work for us. Instead of keeping track of a dragging flag, it seems the best practice is to keep track of the starting coordinates and check for a certain threshold of drift to determine if we were dragging at the end as some accidental dragging may be excusable.