ListCollectionView Refresh throws an ArgumentNullException

[felixhirt]

• .NET Core Version: 3.1.400-preview-015151
• Windows version: win10 2004
• Does the bug reproduce also in WPF for .NET Framework 4.8?: Yes

ListCollectionView.Refresh runs after CollectionView.DetachFromSourceCollection (or something else) set SourceCollection to null and throws an exception

Actual behavior:
For some reason (unfortunately, im unable to manufacture a simple repro, it only happens seemingly random at runtime on one specific view when it is discarded/goes out of scope), ListCollectionView.Refresh runs after a CollectionView.DetachFromSourceCollection and throws an argument null exception. Trace:
System.ArgumentNullException: Collection cannot be null.
Parameter name: c
at System.Collections.ArrayList..ctor(ICollection c)
at System.Windows.Data.ListCollectionView.b__1_0()
at MS.Internal.Data.SynchronizationInfo.AccessCollection(IEnumerable collection, Action accessMethod, Boolean writeAccess)
at System.Windows.Data.BindingOperations.AccessCollection(IEnumerable collection, Action accessMethod, Boolean writeAccess)
at System.Windows.Data.ListCollectionView.RefreshOverride()
at System.Windows.Data.CollectionView.RefreshInternal()
at System.Windows.Data.CollectionView.ProcessChangeLog(ArrayList changeLog, Boolean processAll)
at System.Windows.Data.CollectionView.ProcessInvoke(Object arg)
at MS.Internal.Data.DataBindEngine.ProcessCrossThreadRequests()
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

While im not 100% sure its CollectionView.DetachFromSourceCollection which sets the SourceCollection to null, it seems highly likely.

Expected behavior:
Do nothing if the source collection is gone (or clear the contents of the shadow collection? Is there a scenario where this happens legit, i.e. the view is still shown to the user? It does not seem so)

Minimal repro:
Unfortunately, the app is rather complex and i cannot pinpoint the exact point of failure. It happens on a view which has a CollectionViewSource with grouping in its resources which is used by a listview. But we have similar things in other places and it works.

Workaround:
We are able to work around it be creating the collectionviewsource in the viewmodel, and bind the listview itemssource to its CollectionView

[fabiant3]

Thanks for the report, an isolated repro would help.

[felixhirt]

@fabiant3 of course, if we figure out whats different/unique about this user control, i will try to provide a specific repro

[felixhirt]

Just a quick update with further information we found while investigating. This is the situation so far:

• We have an observablecollection which uses BindingOperations.EnableCollectionSynchronization to allow changes on a background thread. We display a wpf usercontrol with a viewmodel which uses this collection. This control and its viewmodel are regularly removed from the ui and consequentially garbage collected (A new instance is added again later on).
• It happens that we make changes to this collection at the same exact time when the ui components are about to disappear.
• Since the changes happened while the ui was still valid, the changes (from the background thread) are put in the collection view's change log for later processing
• When the ui thread gets around to process them, The collectionview is no longer valid (SourceCollection is null) and we get the exception

I think we should either check this for null to make sure the collectionview is actually still valid, or stop scheduling the processing of the changelog if the collectionview is no longer valid (if that would even be possible, since it is probably scheduled while the collectionview is still alive)

@fabiant3 Does this help?

[anjaligupta-dev]

@felixhirt A minimal repro along with a screen recording would help me understand the issue better.

[lindexi]

Reference #7389

But not the same issues

[felixhirt]

@anjali-wpf Unfortunately we were never able to pinpoint this issue. It happens in a very old legacy app with lots of other issues, so we simply ignored it with the workaround mentioned above. Since our new applications run on Blazer anyway, this is not very relevant to us anymore.

If you want, you can close the issue (or you can investigate it, but im afraid i wont be able to provide a repro)

[anjaligupta-dev]

@felixhirt :  Thanks for the info. In that case, we will close the current issue.