Make MeasureInvalidated event work correctly

[albyrock87]

Description of Change

MeasureInvalidated event was working fine on Xamarin, while on MAUI we basically forgot about bubbling up the event.

This causes the issues below where the system relays on this event to do something, like resizing the cell of a collection view.

This PR brings back the MeasureInvalidated event trigger on parents.

I've adjusted Xamarin components like Layout and Page to leverage the new internal method I put on VisualElement.

I've re-enabled the collection view testing gallery regarding dynamic sizing of elements in collection view.

I don't have much time available right now, so if you need to add more tests, feel free to do it.

Issues Fixed

Fixes #15177
Fixes #20181
Fixes #22978

[rmarinho]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[albyrock87]

@rmarinho are those failed test environment issues or are those caused by my chargers?
If it's the latter, where can I see some detail about the failures?

[rmarinho]

Hi @albyrock87 seems we might have a issue with this test failing ..

ChildPagesDoNotLeak

Reference to Microsoft.Maui.Controls.ContentPage (type Microsoft.Maui.Controls.ContentPage is still alive.\n\n---- Assertion timed out

[albyrock87]

@rmarinho thanks for the help, I've changed the code to account for the fact that usually child elements don't get removed: I mean, the dev pops the page from the stack and that's it.

So basically I'm manually bubbling up the event from the child element to the parent.
I've ran the device tests locally and they're now passing.

[PureWeen]

Things to review before merging

• can we achieve this through handlers vs events. Measure invalidated fires through command mapper so we could propagate that way which would be more core compliant

• should we remove all the superview.setneedslayout calls from the iOS core code, with these changes that code shouldn't be needed.

[albyrock87]

@PureWeen I wanted to have a minimal impact with these changes to simply fix the bugs, but if that's the direction to take, I can refactor this to make it happen (also removing the SetNeedsLayout chain).

[albyrock87]

After a bit of research this is what I can tell:

1. MeasureInvalidated event is needed (also within Shell) to tell whether an immediate descendant has potentially changed its measure
2. Native component tree does not necessary map 1:1 to MAUI components (i.e. CollectionView)
3. MeasureInvalidated is something we (almost) ported from Xamarin: I say almost because it is not being propagated to parents
4. MeasureInvalidated is only triggered by InvalidateMeasureInternal
5. InvalidateMeasureInternal is used by a lot of non-native consumers (i.e. Grid.RowSpacing, or ImageElement.ImageSourceChanged)
6. We cannot get rid of MeasureInvalidated event because
   1. It is used to detect measure changes for logical descendants (see for example Shell : flyoutHeader.MeasureInvalidated) which has potentially (almost) nothing to share with the native tree of components
   2. It is part of a widely used API from third party libraries
7. We are indeed doing SetNeedsLayout on iOS recursively on the platform-tree but that fails in case a non-platform view maps to a complex native
8. Android and WinUI don't need such recursive layout invalidation

That said, our goals (IMHO) should be:

1. Support MeasureInvalidated event propagation
2. Reduce as minimum as possible the MeasureInvalidated?.Invoke effective calls (aka MeasureInvalidated = null)
   1. Which means do NOT rely on MeasureInvalidated event to propagate the information
3. Platform-Level code should NOT be the one navigating a non-platform hierarchy

For the above mentioned reasons I think that the approach of my PR is correct, and it's probably the only achievable choice for a SR release where we don't want to change public APIs.

For .NET9, we could:

1. Add a IView.RequestLayout(RequestLayoutReason) command, which will be invoked from OnChildMeasureInvalidatedInternal
2. the IView.RequestLayout command mapper will invoke SetNeedsLayout on iOS and do nothing on other platforms

This also gives us the possibility to be smart (i.e. on ScrollView) and avoid propagating events and SetNeedsLayout above.

[PureWeen]

/rebase

[PureWeen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[danN59]

Hi, when will this be merge ?

[PureWeen]

/azp run

[albyrock87]

@billylo1 the fix will be available in SR9