FluidMoveBehavior memory leak

[tibel]

As described in https://social.msdn.microsoft.com/Forums/lync/en-US/f14d1486-24ba-447b-9712-e16f5457a08b/fluidmovebehavior-memory-leak-bug there is a memory leak with the static TagDictionary.

I write this as a reminder/question, as I think this issue is still existing in the current code base.

[brianlagunas]

Per our issue requirements. A sample must be provided in order for the Behaviors team to evaluate the issue. Please submit an app that can reproduce the issue, and it will be reopened.

[brianlagunas]

Actually, I found one here: https://github.com/microsoft/XamlBehaviorsWpf/tree/master/samples/XAMLBehaviorsSample

[brianlagunas]

This is absolutely a memory leak! There is some code that uses a timer to remove objects from the static dictionary to help limit the number of objects in the TagDictionary when the layout updates.

I'm worried about that static TagDictionary. I didn't write this behavior, and I am unaware of it's usage when dealing with many FluidMoveBehaviors. I was first thinking that we could clear the TagDictionary on Detaching or Unloading, but that might impact other FluidMoveBehavior instances in other areas of the app.

@DVaughan @branh do you have any knowledge with this behavior?

[jogibear9988]

How about using WeakReferences instead of the UI Elements.
And the Timer could remove the entry if one of WeakReferences is invalid

[tibel]

Might a ConditionalWeakTable work here?

Would be the simplest change:
https://github.com/tibel/XamlBehaviorsWpf/tree/behavior_leak

[BrannonKing]

@tibel , I like your approach. You should put in a pull request.

[tibel]

I can create a pull request if the change is accepted as-is (no tests)?

[brianlagunas]

Hey @tibel was there a specific reason you closed your PR? Did you determine that your approach does not solve the problem?

[tibel]

I've moved on as I haven't done WPF development in the last few years.