Problem
Canvas Preview nodes currently behave like a two-layer interaction surface: dragging inside the preview pans/drags the preview's internal content by default, while moving the Preview node itself requires grabbing the border/frame area.
This makes Preview nodes harder to reposition than ordinary canvas nodes. Users often expect a drag on the node body to move the node in the parent canvas, especially when arranging a board. The current default instead captures the gesture inside the embedded preview, so the user must precisely target the border to move the Preview node.
Desired behavior
Reverse the default drag semantics for Canvas Preview nodes:
- Plain drag on a Preview node should move the Preview node itself on the parent canvas, matching ordinary node behavior.
- Dragging/panning the preview's internal content should require an explicit alternate gesture, such as Ctrl-drag / Cmd-drag, Space-drag, a dedicated interaction mode, or another discoverable modifier.
- The chosen alternate gesture should be consistent with Huabu's broader canvas interaction model and should not conflict with existing selection, multi-select, zoom, or browser gestures.
- The UI should make the alternate internal-pan gesture discoverable, for example via cursor/tooltip/help text or a visible affordance when appropriate.
Scope
Audit Canvas Preview node interactions introduced by #109 and update the interaction contract for nested preview canvases, including:
- Pointer/mouse drag handling on the Preview node body vs border.
- Interaction with canvas selection, node dragging, and nested preview pan/zoom.
- Modifier-key behavior across platforms, including Ctrl on Windows/Linux and Cmd on macOS where appropriate.
- Touch/trackpad behavior if Preview nodes support those interactions today.
Acceptance criteria
- Plain drag anywhere on the Preview node's main surface moves the Preview node in the parent canvas, unless the drag starts on an explicitly interactive child control.
- Internal preview panning remains possible through a clearly defined alternate gesture or mode.
- Existing Preview node click/zoom-through/read-only behavior is preserved unless intentionally changed and documented.
- The interaction is accessible/discoverable enough that users are not forced to guess that only the border moves the node.
- Add focused regression coverage for node movement vs internal-preview panning gesture routing.
- Update relevant architecture or interaction documentation if the Preview node interaction contract changes.
Related
Problem
Canvas Preview nodes currently behave like a two-layer interaction surface: dragging inside the preview pans/drags the preview's internal content by default, while moving the Preview node itself requires grabbing the border/frame area.
This makes Preview nodes harder to reposition than ordinary canvas nodes. Users often expect a drag on the node body to move the node in the parent canvas, especially when arranging a board. The current default instead captures the gesture inside the embedded preview, so the user must precisely target the border to move the Preview node.
Desired behavior
Reverse the default drag semantics for Canvas Preview nodes:
Scope
Audit Canvas Preview node interactions introduced by #109 and update the interaction contract for nested preview canvases, including:
Acceptance criteria
Related