Error in KernelBase.dll when using nested ItemsRepeater

[marcelwgn]

Describe the bug

When scrolling nested repeaters, scrolling them for a certain amount will result in the following error:

Exception thrown at 0x00007FF84D16361C in ItemsRepeaterExperiments.exe: 
Microsoft C++ exception: winrt::hresult_error at memory location 0x000000CF37E7A960.

Steps to reproduce the bug

Steps to reproduce the behavior:

1. Open the project in ItemContainer / Behaviors discussion and improvements #2284
2. Visit the second tab ("Nested selection demo"
3. Scroll down using mousewheel or clicking on the inside and pressing page down key

Expected behavior

Not to crash

[JohnnyWestlake]

I think this is a symptom of the fact that it does not properly recycle / handle virtualisation when nested. You'll see in the live visual tree the visual count always goes up and up, even if you scroll up and down to the same range.

[ranjeshj]

Recycling is done by the DataTemplate instance, so if the DataTemplate instance is shared across the repeaters, it should be recycling. If we are doing that and still see the count not settling down, that is a bug. Can you resolve symbols, enable native debugging and see if you can get a callstack ? Is this a layout cycle crash ?

[marcelwgn]

Here is the stack trace:

https://gist.github.com/chingucoding/099a42851fd3b4c687d47f2519b65ae0

This seems to be an layout cycle issue:

[ranjeshj]

Did a little bit of digging and it looks like this is a bug in the element clearing path. We set the data context on elements during ElementPrepared, but do not seem to clear it on ElementClearing. As a quick test to verify if this was the case, I added an ElementClearing event handler to the repeaters in the page and added this line in the handler which seemed to fix this problem.

(args.Element as FrameworkElement).DataContext = null;

The fix would be to do this in this method. We must ensure that we are doing this only if we set the DataContext in this method.

[marcelwgn]

Awesome that you found the root of this issue. Would you like me to look fix this @ranjeshj?

Also is there a way we could add an automatic test for this? The crash itsself can't be reproduced in a reliable fashion. @StephenLPeters FYI.

[ranjeshj]

@chingucoding If you can make a fix that would be great. I think you can emulate the issue in a test using a single repeater by making the data context be set in that method (I think if you have a Binding in your template it will do that) and after the container gets recycled, you can check to see if the DataContext property of the container is null. The bug is that it is not null.

[marcelwgn]

From what I can see, the problem with the test is the following:

• The event gets raised first, then we run our custom recycle logic
• If we try to wait x milliseconds and then look at the item that got cleared again, the datacontext will already have changed. since elements only mostly only get cleared if we need a new on (from what I can understand)
• Running the clear datacontext logic before raising the event might cause side effects or break existing logic

What would be the best way to write a good test for this? The crash option is not viable as it's unreliable and lookin in the ElementClearing eventhandler only works if that gets pushed behind in the list of steps we run when clearing an element.

[ranjeshj]

Yes, we should not set it to null before ElementClearing because you are correct, app might be looking at the data context in the ElementClearing handler.

You could use your own object instead of DataTemplate as the ItemTemplate and intercept the element in RecycleElement method. That will give you access to the recycled element after the logic has run. You could possibly reuse this mock type.

[marcelwgn]

Alright, I see. That sounds like a good approach, I will take a look at this tomorrow.