Repository navigation
fix(view): accept list drag-and-drop over the whole group - #11126
Open
MichaelUray wants to merge 1 commit into
Open
MichaelUray wants to merge 1 commit into
MichaelUray wants to merge 1 commit into
Conversation
When an issue was dragged into another group of the list view, the group only picked it up when the dragenter event happened within 5px of the top or bottom border of the element under the pointer. In addition, dragleave also fires when moving between child elements (header cells, rows), so the previewed item was removed again as soon as the pointer moved inside the group. The group then shrank and the pointer often ended up over the next group, which made the effective drop area very narrow and almost unusable for empty groups. A group now previews the dragged item as soon as the pointer enters any part of it (at the top when entering the upper half, otherwise at the bottom) and only drops the preview when the pointer really leaves its bounds. The per-row dragleave guard that tried to work around the child events is no longer needed. Collapsed groups are not expanded on hover, they still accept the drop on their header. Reordering inside a group is unchanged. The source row is now made invisible (keeping its space) instead of removed while it is dragged outside of its group, so dragend is still delivered and a cancelled drag restores it. Every group listens for dragend on the window and resets its drag state on any dragend, dropping its preview row when the drag was cancelled, e.g. by Escape while the pointer is still inside the hovered group. With sub-grouping only the leaf group shows the preview, parent groups no longer keep a stale preview that held them open. A drop on the group header or empty space now uses the same handler as a drop on a row, so the rank of the previewed position is persisted in manually ordered lists (previously the DOM event object was passed as the update). Fixes hcengineering#9536 Signed-off-by: Michael Uray <michaeluray@users.noreply.github.com>
This branch has not been deployed
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
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.
Fixes #9536
Problem and change
When an issue was dragged into another group of the list view, the group
only picked it up when the dragenter event happened within 5px of the top or
bottom border of the element under the pointer. In addition, dragleave also
fires when moving between child elements (header cells, rows), so the
previewed item was removed again as soon as the pointer moved inside the
group. The group then shrank and the pointer often ended up over the next
group, which made the effective drop area very narrow and almost unusable for
empty groups.
A group now previews the dragged item as soon as the pointer enters any part
of it (at the top when entering the upper half, otherwise at the bottom) and
only drops the preview when the pointer really leaves its bounds. The
per-row dragleave guard that tried to work around the child events is no
longer needed. Collapsed groups are not expanded on hover, they still accept
the drop on their header. Reordering inside a group is unchanged.
The source row is now made invisible (keeping its space) instead of removed
while it is dragged outside of its group, so dragend is still delivered and a
cancelled drag restores it. Every group listens for dragend on the window and
resets its drag state on any dragend, dropping its preview row when the drag
was cancelled, e.g. by Escape while the pointer is still inside the hovered
group. With sub-grouping only the leaf group shows the preview, parent groups
no longer keep a stale preview that held them open.
A drop on the group header or empty space now uses the same handler as a
drop on a row, so the rank of the previewed position is persisted in
manually ordered lists (previously the DOM event object was passed as the
update).
Tests
New unit tests
plugins/view-resources/src/__tests__/dragUtils.test.ts. Checked manually on a self-hosted instance in Chromium: drop on the header of an empty status group, drop into a non-empty group, drop outside the list (row comes back), Escape while hovering another group (no leftover preview), dragging the only row of a group, rows below the source not shifting, and the same with sub-grouping (Status, then Priority).