Skip to content

Wait for the drop target's hover in the dragAndDropThought helper - #6163

Open
karunkop wants to merge 2 commits into
cybersemics:mainfrom
karunkop:fix/5879-drag-wait-drop-hover
Open

karunkop wants to merge 2 commits into
cybersemics:mainfrom
karunkop:fix/5879-drag-wait-drop-hover

Conversation

@karunkop

@karunkop karunkop commented Oct 27, 2026 •

Copy link
Copy Markdown
Collaborator

Fixes #5879

dragAndDropThought waited only for the drag alert. When a held drag moves on to a second drop target (skipMouseDown), that alert is already showing. The helper then returned before the second drop hover rendered, in 11 of 40 local runs before this change and 0 of 20 after.

  • Each drop target renders data-drop-over, from react-dnd's shallow isOver. It is true on a target that rejects the drop too, so a drop that shows no bar still passes.
  • The helper records that attribute turning true under the pointer, waits for it once the drag is in progress, and throws if it never does. It records rather than polls because a still pointer fires no dragover. A target that a hover moves under the pointer is never hovered, so polling for it would hang.
  • It does not wait on state.hoveringPath, which is only written when the pointer moves and can still name the previous target.
  • The own-position test no longer waits on .drop-hover itself, since the helper now does.
  • docs/drag-and-drop.md describes the attribute and corrects DropUncle's zone to SubthoughtsDrop. docs/testing.md lists window.__dropTargetHoverWatch among the sanctioned exceptions.

Replaces #5882.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Fd4vvqGUWV42TDr5CEEzGf

dragAndDropThought waited only for the drag alert, which a held drag that
moves on to a second drop target has already shown, so a snapshot could
be taken before the second drop hover rendered (cybersemics#5879). Tests should not
be responsible for drag-and-drop timing, so the helper now waits for the
hover itself.

- Each drop target element (thought rows, DropChild, DropEnd, DropUncle)
  renders data-drop-over, react-dnd's isOver({ shallow: true }). It names
  the target a drop lands on, is set in the same commit as the target's
  isHovering, and is true even on a target that rejects the drop.
- Before its final move, the helper records when the drop target under
  the pointer renders that hover, and waits for the record once the drag
  is in progress. It records rather than polls because a Puppeteer drag
  dispatches dragover only when the pointer moves, so a target that moves
  under the stationary pointer, e.g. after hover expansion, is never
  hovered. It throws if the target is never hovered.
- The own-position test no longer waits on .drop-hover itself.
- Docs: drag-and-drop.md describes data-drop-over and corrects
  DropUncle's zone; testing.md lists the helper's window global.

Fixes cybersemics#5879

Claude-Session: https://claude.ai/code/session_01Fd4vvqGUWV42TDr5CEEzGf
Co-Authored-By: Claude claude-opus-5-5 (xhigh) <noreply@anthropic.com>
@github-actions

github-actions Bot commented Oct 27, 2026 •

Copy link
Copy Markdown
Contributor
Preview Deployment · Oct 28, 2026, 8:21 AM UTC · 3a5eb16

Preview deployment

@karunkop
karunkop marked this pull request as draft October 27, 2026 16:05
@karunkop karunkop changed the title dragAndDropThought waits for its drop target's hover Wait for the drop target's hover in the dragAndDropThought helper Oct 28, 2026

This branch was successfully deployed

1 active deployment
Preview — 3a5eb163 Deployed Oct 28, 2026 by github-actions[bot]
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.

Flaky test: drag-and-drop.ts > pinned drop hovers cliff DropEnd and root sibling ThoughtDrop

1 participant