Implement dragging to reorder Properties panel node sections - #4299
Conversation
There was a problem hiding this comment.
Code Review
This pull request introduces interactive drag-and-drop reordering for Properties panel sections, allowing users to rearrange pinned nodes or nodes within a selected layer's chain. The changes span the frontend Svelte components, WASM wrapper, and backend Rust message handlers and network interfaces. Feedback on the changes highlights two key issues in the frontend drag implementation: a usability bug where aborted drags incorrectly swallow the subsequent legitimate left click, and a missing defensive check for when a dragged section is no longer found in the DOM (i.e., fromIndex is -1).
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
There was a problem hiding this comment.
6 issues found across 9 files
Confidence score: 3/5
- In
frontend/src/components/panels/Properties.svelte, the drag-start button filter is too strict, so valid drags can be blocked when the reorder handle is not a<button>, which can make section reordering appear broken to users — broaden the guard to recognize the actual drag handle instead of button-only starts before merging. - In
frontend/src/components/panels/Properties.svelte, drag state/index handling has edge-case regressions (justFinishedDragon Escape and missingfromIndex !== -1guard) that can swallow the next real click or run reorder logic with an invalid index during concurrent UI updates — only set the click-suppression flag on completed drags and add an explicitfromIndexvalidity check. - In
editor/src/messages/portfolio/document/document_message_handler.rs, mixed selections can still enter the single-layer reorder path and trigger chain-node reordering incorrectly, risking unintended document edits — require that no non-layer selections are present before taking that path. - In
editor/src/messages/portfolio/document/utility_types/network_interface.rs, pinned-order pruning uses attempted deletions rather than successful deletions, so a failed delete can silently corrupt pinned display order for remaining nodes; the related recoverable path also logs at error level, which can hide real failures in noise — prune only on confirmed deletions and downgrade that log to warn/debug.
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
Recording.2026-07-01.030232.mp4