GeezerVison

Summary

getNodeAbsolutePosition added the container's header and padding to a child's position. Those are already in the position — React Flow places a child at its parent's origin plus its own coordinates, and clampPositionToContainer is what holds it clear of the chrome, flooring it at LEFT_PADDING and HEADER_HEIGHT + TOP_PADDING. Counting them twice reported every nested node 16px right and 66px below where it actually renders.

What that looks like:

• A block drops down-right the moment it is dragged out of a Loop.
• A block dragged into a Loop from the canvas lands off-target.
• Container hit-testing during a drag, and the bounds fitView focuses on, are both skewed for nested nodes.

Two callers already knew something was wrong: each subtracted the same three constants straight back off to recover a relative position. They now take the difference of two absolutes, which is what a relative position is.

A third place had its own copy — React Flow's child extent, with a fourth distinct header height (42, against the 40 the card renders and the 50 this helper used). It now reads the same constants as the clamp, so a drag stops where a drop would put it.

And positionAbsolute ?? getNodeAbsolutePosition(...) in the fit-view path stops disagreeing with itself: React Flow's own answer carries no offset, so its two branches returned points 66px apart for the same node.

Type of Change

• Bug fix

Testing

New unit tests on the hook pinning the convention — a child sits at parent-plus-position, a root node is untouched, and popping a child out round-trips to exactly where it was. Two fail on the old helper, with the double-count visible in the diff:

expected { x: 32, y: 132 } to deeply equal { x: 16, y: 66 }

That is the pop-out case: the block landed 16px right and 66px down instead of staying put.

Blast radius is bounded by the helper's own early return — a node with no parent returns its position unchanged, so nothing about top-level blocks changes. Only nested nodes move, and only onto the position they were already being drawn at.

Full [workflowId] and lib/workflows suites green (1756 tests), type-check and lint clean across all 23 packages.

Not verified on a running canvas. Worth dragging a block out of a Loop and back in before merging — that is the exact interaction this changes.

Notes

• The extent change tightens the drag floor from 42 to HEADER_HEIGHT + TOP_PADDING. Programmatic placement already used the larger floor, so this makes dragging agree with dropping rather than loosening anything.
• Remaining follow-ups from the subflow work, deliberately not bundled here: the mcp-dynamic-args row estimate, and writing a container's derived size back so the first painted frame is not the stored default.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)