Skip to content
New issue

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

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Jump to bottom

CDK Virtual Scroll ViewDestroyed Error #13901

Closed
lujakob opened this issue Oct 31, 2018 · 3 comments · Fixed by #13916
Closed

CDK Virtual Scroll ViewDestroyed Error #13901

lujakob opened this issue Oct 31, 2018 · 3 comments · Fixed by #13916
Assignees
@crisbeto
Labels
P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent

Comments

@lujakob
Copy link

lujakob commented Oct 31, 2018

Bug, feature request, or proposal:

Bug

What is the expected behavior?

Scrolling of virtual-scroll list is possible during an updating process of the data without any errors.

What is the current behavior?

When a virtual scroll list of items is during an update process of the items, scrolling the list causes an "Attempt to use a destroyed view" error. In realworld use case an array of objects are being updated (property changes in the objects). In the stackblitz demo a setInterval updates the data. I suspect the error is caused through reassignment of the data during scrolling.

What are the steps to reproduce?

StackBlitz starter: https://stackblitz.com/edit/angular-cwrtae
Open console, press button to start updating the data and then scroll back and forth continuously.

What is the use-case or motivation for changing an existing behavior?

The virtual-scroll directive should be possible to use with a list of data that is being in an updating/changing process.

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

7.0.0

Is there anything else we should know?
@lujakob
Copy link
Author

lujakob commented Oct 31, 2018

The stack traces lead to _updateContext function. I suspect a view trying to be updated, when it's already been replaced.
https://github.com/angular/material2/blob/master/src/cdk/scrolling/virtual-for-of.ts#L279
There is a Todo for @mmalerba in the source, maybe this is a place to start.

@ireneguijarro
Copy link

Same problem here, 😢

@crisbeto crisbeto self-assigned this Oct 31, 2018
@crisbeto crisbeto added P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent has pr labels Oct 31, 2018
crisbeto added a commit to crisbeto/material2 that referenced this issue Oct 31, 2018
@crisbeto
fix(virtual-scroll): not removing view from container if it's outside…
b901e97 
… the template cache

Currently when detaching a view, we check whether it would fit in the cache, and if it doesn't, we destroy it. Since we destroy the view on it's own, the `ViewContainerRef` still has a reference to it, which means that we'll trigger change detection on it the next time the data changes. These changes switch to destroying the view through the view container.

Fixes angular#13901.
@crisbeto crisbeto mentioned this issue Oct 31, 2018
Merged
crisbeto added a commit to crisbeto/material2 that referenced this issue Oct 31, 2018
@crisbeto
fix(virtual-scroll): not removing view from container if it's outside…
a46887d 
… the template cache

Currently when detaching a view, we check whether it would fit in the cache, and if it doesn't, we destroy it. Since we destroy the view on it's own, the `ViewContainerRef` still has a reference to it, which means that we'll trigger change detection on it the next time the data changes. These changes switch to destroying the view through the view container.

Fixes angular#13901.
jelbourn pushed a commit that referenced this issue Nov 3, 2018
@crisbeto @jelbourn
fix(virtual-scroll): not removing view from container if it's outside…
8922100 
… the template cache (#13916)

Currently when detaching a view, we check whether it would fit in the cache, and if it doesn't, we destroy it. Since we destroy the view on it's own, the `ViewContainerRef` still has a reference to it, which means that we'll trigger change detection on it the next time the data changes. These changes switch to destroying the view through the view container.

Fixes #13901.
atscott pushed a commit to atscott/components that referenced this issue Nov 5, 2018
@crisbeto @atscott
fix(virtual-scroll): not removing view from container if it's outside…
53080e5 
… the template cache (angular#13916)

Currently when detaching a view, we check whether it would fit in the cache, and if it doesn't, we destroy it. Since we destroy the view on it's own, the `ViewContainerRef` still has a reference to it, which means that we'll trigger change detection on it the next time the data changes. These changes switch to destroying the view through the view container.

Fixes angular#13901.
jelbourn pushed a commit that referenced this issue Nov 6, 2018
@crisbeto @jelbourn
fix(virtual-scroll): not removing view from container if it's outside…
7c202ec 
… the template cache (#13916)

Currently when detaching a view, we check whether it would fit in the cache, and if it doesn't, we destroy it. Since we destroy the view on it's own, the `ViewContainerRef` still has a reference to it, which means that we'll trigger change detection on it the next time the data changes. These changes switch to destroying the view through the view container.

Fixes #13901.
@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 Sep 10, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@crisbeto crisbeto

Labels
P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent
Projects
None yet
Milestone
No milestone
3 participants
@lujakob @crisbeto @ireneguijarro