Skip to content

bug(drag-and-drop): disconnecting drop list is really slow after version 19.1.5 #30737

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
1 task done
rubiesonthesky opened this issue Mar 28, 2025 · 1 comment · Fixed by #30751
Closed
1 task done
Assignees
Labels
area: cdk/drag-drop P2 The issue is important to a large percentage of users, with a workaround

Comments

@rubiesonthesky
Copy link

rubiesonthesky commented Mar 28, 2025

Is this a regression?

  • Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

19.1.3

Description

After #30514 , disconnecting long list of drag items slows down browser so much that it freezes. Locally reverting that change fixes the issue and you get the earlier behavior.

The use case may be little bit unconventional, but we have separate list for "items to buy" and then items for being in "shopping basket" (using one of the examples in website). They are in different components and connected by one parent component. Everything works greatly until the "product selection" component is destroyed. It works when there are sane number of items ,say 500. But when there are over 4000 items, the browser becomes unusable.

I'm able to repro this same behavior in Stackblitz. Though, it needs a lot more items before it starts to break: 40000.

Our actual code is years old, so it may be that it would be instructed to write it another way.

Is there a way that this._syncItemsWithRef(); would not be called for every item in a row if it happens really quickly? Or is there a better way to disconnect the drop lists before the component is destroyed? Or could there be a setting to opt into the old behavior?

Reproduction

StackBlitz link: https://1owdqzmq.stackblitz.io
Steps to reproduce:

  1. Change array size to be 40 000 for example
  2. Click "Hide source" in template
  3. Notice how slow everything becomes

With smaller array, it's not noticeable at all.

Expected Behavior

It should not be so taxing operation that it basically crashes browser tab

Actual Behavior

Crashes browser tab :/

Environment

  • Angular: 19.2.7
  • CDK/Material: ^19.2.0
  • Browser(s): chrome, firefox
  • Operating System (e.g. Windows, macOS, Ubuntu):
@rubiesonthesky rubiesonthesky added the needs triage This issue needs to be triaged by the team label Mar 28, 2025
@crisbeto crisbeto added P2 The issue is important to a large percentage of users, with a workaround area: cdk/drag-drop and removed needs triage This issue needs to be triaged by the team labels Mar 28, 2025
@crisbeto crisbeto self-assigned this Mar 28, 2025
crisbeto added a commit to crisbeto/material2 that referenced this issue Mar 31, 2025
angular#30514 changed the logic that syncs destroyed items to apply to non-dragged items as well. This led to a performance regression where swapping out a large list of items can lock up the entire browser. The problem is that the items need to be re-sorted each time an item is destroyed which is expensive.

These changes resolve the issue by keeping track of the last set of items and dropping the item from it without re-sorting.

Fixes angular#30737.
crisbeto added a commit that referenced this issue Mar 31, 2025
…#30751)

#30514 changed the logic that syncs destroyed items to apply to non-dragged items as well. This led to a performance regression where swapping out a large list of items can lock up the entire browser. The problem is that the items need to be re-sorted each time an item is destroyed which is expensive.

These changes resolve the issue by keeping track of the last set of items and dropping the item from it without re-sorting.

Fixes #30737.
crisbeto added a commit that referenced this issue Mar 31, 2025
…#30751)

#30514 changed the logic that syncs destroyed items to apply to non-dragged items as well. This led to a performance regression where swapping out a large list of items can lock up the entire browser. The problem is that the items need to be re-sorted each time an item is destroyed which is expensive.

These changes resolve the issue by keeping track of the last set of items and dropping the item from it without re-sorting.

Fixes #30737.

(cherry picked from commit 1372f52)
szoboszlaypali pushed a commit to szoboszlaypali/components that referenced this issue Apr 1, 2025
…angular#30751)

angular#30514 changed the logic that syncs destroyed items to apply to non-dragged items as well. This led to a performance regression where swapping out a large list of items can lock up the entire browser. The problem is that the items need to be re-sorted each time an item is destroyed which is expensive.

These changes resolve the issue by keeping track of the last set of items and dropping the item from it without re-sorting.

Fixes angular#30737.
mistrykaran91 pushed a commit to mistrykaran91/components that referenced this issue Apr 7, 2025
…angular#30751)

angular#30514 changed the logic that syncs destroyed items to apply to non-dragged items as well. This led to a performance regression where swapping out a large list of items can lock up the entire browser. The problem is that the items need to be re-sorted each time an item is destroyed which is expensive.

These changes resolve the issue by keeping track of the last set of items and dropping the item from it without re-sorting.

Fixes angular#30737.
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators May 3, 2025
# for free to subscribe to this conversation on GitHub. Already have an account? #.
Labels
area: cdk/drag-drop P2 The issue is important to a large percentage of users, with a workaround
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants