[Bug] VisualTreeChangeEventArgs, Parent is null when element is removed and VisualTreeChangeType is Add instead of Remove and ChildIndex is -1

[chabiss]

Description

Steps to Reproduce

1. Launch the attached application
   XamarinTest.zip
2. Clear you debug output to see the VisualTreeChangeEventArgs
3. Pressed the Removed Button which is going to remove the first label at 25:10 from the stack panel
4. Pay attention to the debug output

Expected Behavior

VisualTreeChangeEventArgs Remove:
Parent:Xamarin.Forms.StackLayout: MainPage.xaml;assembly=XamarinTest:23:6-->
ChildIndex: 0: Child:Xamarin.Forms.Label: MainPage.xaml;assembly=XamarinTest:25:10

Actual Behavior

VisualTreeChangeEventArgs Add:
Parent:null: ::-->
ChildIndex: -1: Child:Xamarin.Forms.Label: MainPage.xaml;assembly=XamarinTest:25:10

Basic Information

The parent is null, this is not good. Also, the ChildIndex is -1 which is also not good.

• Version with issue:
• Last known good version:
• IDE:
• Platform Target Frameworks:
  • iOS:
  • Android:
  • UWP:
• Android Support Library Version:
• Nuget Packages:
• Affected Devices:

Screenshots

Reproduction Link

Workaround

VS bug #1152707, VS bug #1152813

[maxbrister]

@StephaneDelcroix Here's a description of what we expect. Please let me know if I'm missing anything.

Goal: VS needs to maintain and display a tree representing the application's visible[1] UI elements. VS uses VisualTreeChangeEvents to update its internal representation of the visual tree.

• VisualTreeChangeEventArgs.Parent - Determines the node in the Visual Tree that has changed. Each node contains an ordered array of children. If Parent is null then this is a "root" element.
• VisualTreeChangeEventArgs.Child - The node being inserted or removed. Should be specified for both add and remove, because VS will check the underlying data structure for consistency.
• VisualTreeChangeEventArgs.ChangeType - Indicates the operation is either an Insert or Remove. (VisualTreeChangeType.Add was an unfortunate naming choice - really it's an insert)

Pseudo code for how VS interprets ChangeType == VisualTreeChangeType.Add

var parent = GetNode(args.Parent);
var child = GetNode(args.Child);
parent.Children.Insert(args.ChildIndex, child);

Pseudo code for how VS interprets ChangeType == VisualTreeChangeType.Remove

var parent = GetNode(args.Parent);
parent.Children.RemoveAt(args.ChildIndex);

Wpf and Uwp treat initial registration for VisualTreeChangeEvents differently. Either way is acceptable.

• Uwp Model - On registration a flood of VisualTreeChangeEvents with ChangeType == Add is sent to describe the current tree. If a UI element is removed from the Visual Tree a single Remove event is sent. If a new element is added to the Visual Tree a flood of events is sent describing the new element an all of its children are sent.
• Wpf Model - No events are automatically sent on attach. VisualTreeHelper is used to discover the initial tree. When a new element is added to the visual tree a single VisualTreeEvent with VisualTreeChangeType.Add is sent. VisualTreeHelper is used again to discover the shape of the new subtree. This approach relies on being able to accurately determine the VisualTree outside of VisualTreeChangeEvents, which we don't know how to do in Xamarin. This is what the Xamarin tap is currently based on.

[1] Both Wpf and Uwp include elements with Visiblity==Collapsed if they would otherwise be visible