Skip to content

fix(view): accept list drag-and-drop over the whole group - #11126

Open
MichaelUray wants to merge 1 commit into
hcengineering:developfrom
MichaelUray:fix/list-dnd-empty-category
Open

MichaelUray wants to merge 1 commit into
hcengineering:developfrom
MichaelUray:fix/list-dnd-empty-category

Conversation

@MichaelUray

Copy link
Copy Markdown
Contributor

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).

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

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Drag-and-drop target area too narrow in list view, difficult to move issues to empty status blocks

1 participant