Merge master into v8-branch (brings #1410 tab-group chip re-drag fix)#1501
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
fix(dockview-core): tab group can't be moved after its first move (#1410)
…-into-v8-branch-1410 # Conflicts: # packages/dockview-core/src/dockview/components/titlebar/tabGroups.ts
Add a Playwright regression test that drags a tab-group chip past another group and then back, asserting the chip stays draggable across both moves — the real-browser pointer-drag path the jsdom unit tests can't exercise. Fails against the pre-fix bundle (the second drag is a no-op) and passes with the re-arm fix. Adds a `setupTwoTabGroupChips` fixture helper (two chips in one group) and a `chipLabels` reader. 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
Merges current
masterintov8-branch. The notable change master carries thatv8-branchwas missing is the #1410 fix — a tab group could not be dragged again after being moved once, because committing a within-group chip move disposed the chip's drag sources and_ensureChipForGroupnever re-armed them.Merge details:
tabGroups.ts— a doc comment ondisposeChipDragthat both sides edited (v8 had a punctuation cleanup; master rewrote it to describe the new re-arm behavior). Resolved in favor of master's version, since the old "the subsequentupdate()will also dispose the sources" wording is no longer accurate.Fix verified in v8's structure: v8 moved the commit orchestration into
tabReorderController.commitGroupMove, which still callsdisposeChipDragon a within-groupmoveTabGroup, so the merged fix (re-arming the sources in_ensureChipForGroup) applies unchanged. The #1410 unit tests fail against v8's pre-fixtabGroups.tsand pass after the merge.Type of change
Affected packages
dockview-coredockview(vanilla JS)dockview-reactdockview-vuedockview-angulardocsHow to test
within-group chip stays draggable across repeated moves (#1410)and the smooth-mode variant indockviewComponent.spec.ts— both drive the realTabs._commitGroupMovepath and assert the chip re-drags. Full dockview-core suite: 1271 passing.tab-group chip repeated moves (#1410)ine2e/tests/tab-group-chips.spec.tsdrags a chip past another group and back in a real browser (pointer backend), asserting the chip stays draggable across both moves. Verified it fails against a pre-fix bundle and passes after the merge.Both the unit and e2e #1410 tests were confirmed red on the pre-fix source and green after.
Checklist
yarn testpasses (dockview-core: 1271)npm run gen— n/a to this changeNote: the pre-existing
multi-row-tabs"vertical header" andvue-keep-alivee2e specs fail in my sandbox for environmental reasons (headless geometry / the dockview-vue UMD bundle not built locally); they fail identically without this change and are unrelated to it.🤖 Generated with Claude Code
https://claude.ai/code/session_01Heh7Wst7u9Vu6QbYE5uGAK
Generated by Claude Code