fix(dockview-core): tab group can't be moved after its first move (#1410)#1500
Merged
Conversation
…-group move (#1410) Committing a group-chip move calls `disposeChipDrag`, which disposes the chip's HTML5 + pointer drag sources to release the transfer payload and iframe shield synchronously. A cross-group move dissolves the source chip entirely, so this is harmless — but a within-group reorder keeps the same chip element. Because `_ensureChipForGroup` early-returns when a renderer entry already exists, the disposed sources were never rebuilt, so after its first move a chip kept `draggable=true` (firing a native `dragstart`) but no longer set a transfer payload — leaving the tab group undraggable. Extract the drag-source wiring into `_createChipDragSources` and re-arm it from `_ensureChipForGroup` when a surviving entry has no live sources. `disposeChipDrag` now clears the source references so the following `update()` re-wires them. The context-menu long-press cancel resolves the pointer source from the entry so it targets the current (re-armed) source. Adds a regression test that drives two consecutive chip drags across a within-group move and asserts the transfer payload is set both times. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Heh7Wst7u9Vu6QbYE5uGAK
Drive the real production commit path (`Tabs._commitGroupMove`) instead of simulating `disposeChipDrag` + `moveTabGroup`, cover repeated within-group moves, assert both the HTML5 and pointer drag sources are re-armed, and add a smooth-mode variant matching the reported example's config (the FLIP branch of `_commitGroupMove`). All fail against the pre-fix source. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Heh7Wst7u9Vu6QbYE5uGAK
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Fixes #1410 — a tab group could not be dragged again after being moved once (the issue surfaced as "tab groups can't be moved if a tab is in focus", but focus was incidental).
Root cause: Committing a group-chip move calls
TabGroupManager.disposeChipDrag, which disposes the chip's HTML5 + pointer drag sources to release the transfer payload and iframe shield synchronously. A cross-group move dissolves the source chip entirely, so this is harmless. But a within-group reorder keeps the same chip element, and_ensureChipForGroupearly-returns when a renderer entry already exists — so the disposed drag sources were never rebuilt. After its first move the chip keptdraggable=true(a nativedragstartstill fired) but no longer set a transfer payload, so no drop overlay appeared and the group could not be moved.Fix: Extract the chip drag-source wiring into
_createChipDragSourcesand re-arm it from_ensureChipForGroupwhen a surviving entry has no live sources.disposeChipDragnow clears the source references so the followingupdateTabGroups()re-wires them. The context-menu long-press cancel resolves the pointer source from the entry so it targets the current (re-armed) source rather than a stale captured one.Type of change
Affected packages
dockview-coredockview(vanilla JS)dockview-reactdockview-vuedockview-angulardocsHow to test
Using the Tab Groups example: drag the "Feature" group by its chip to relocate it, then try to drag it again. On
masterthe second drag does nothing; with this change it keeps working on every subsequent drag.Automated:
within-group chip stays draggable after a move (#1410)indockviewComponent.spec.tsdrives two consecutive chip drags across a within-groupmoveTabGroupand asserts the transfer payload (getPanelData().tabGroupId) is set both times. It fails onmaster(second read isundefined) and passes with the fix.This was also verified end-to-end by driving the built bundle in a real Chromium via native drag: before the fix the drop overlay appeared only on the first move; after the fix it appears on every move.
Checklist
yarn lint:fixpasses (no new errors)yarn formatpassesnpm run genhas been run and generated files are up to dateyarn testpasses (1080 dockview-core tests)🤖 Generated with Claude Code
https://claude.ai/code/session_01Heh7Wst7u9Vu6QbYE5uGAK
Generated by Claude Code