Fixing up event handlers to break some cycles that can cause leaks
Summary of the pull request
Addressing an issue where a couple of events are contributing to the WidgetViewModel and the dashboard leaking through the cycles that get formed when non static event handlers are added. Note that even with this change, the WidgetViewModel is leaking which is being investigated but this reduces the sources contributing to it leaking.
References and relevant issues
Contributes to ADO#44532978
Detailed description of the pull request / Additional comments
When instance level event handlers are added to an event, the instance that the event is from is kept alive for the lifetime of the event handler. In the WidgetViewModel, we were holding onto an instance of the Widget model and setting up an event handler from it to subscribe to widget notifications. This meant we had a cycle where the Widget model is holding onto a CCW for an event handler belonging to the WidgetViewModel while at the same time the WidgetViewModel is keeping the Widget alive. The .NET GC cannot detect such cycles especially for non XAML scenarios and thereby it contributes to the view model leaking. Addressed by introducing another class which is used to achieve weak event handlers.
On the dashboard page, we also had a couple of instance event handlers we were adding to events on static objects. This meant the event handlers were keeping the first dashboard instance alive for the lifetime of the static object which is forever.
Validation steps performed
Validated scenarios continue to work, but note we still do have other things still causing the leak to happen.
PR checklist
- [ ] Closes #xxx
- [ ] Tests added/passed
- [ ] Documentation updated
/azp run
Azure Pipelines successfully started running 1 pipeline(s).
@manodasanW this has a merge conflict now
@manodasanW this has a merge conflict now
I plan on taking a look soon. I might have another change to add here which is why I held off.
Closed and reopened to trigger new PR validation.
@manodasanW I rebased this onto the current main. Not sure if there was still more you wanted to do here.
@manodasanW do you think we could get this in, once the merge conflicts are fixed?