Description
While working on #22270 I noticed we are hitting a scenario that's causing an infinite layout loop.
When you look at the following stack trace we can see there's a path where
Platform Arrange happens => Sets the Frame on VisualElement => this triggers a propertychanged event on Width => propagates to handler => RequestLayout fires.
Because RequestLayout on Android fires up the whole tree this can sometimes cause weird layout loops or excessive measure/layout paths.
My current thinking is that we just need to short circuit the "Handler.Updatevalue" call inside Element if the property change is related to the readonly height/width/x/y properties and we are inside a "BatchCommitted" path.
I also noticed there's a rounding issue that's causing ping ponging when we update the Frame upstream so we should probably account for that as well
Description
While working on #22270 I noticed we are hitting a scenario that's causing an infinite layout loop.
When you look at the following stack trace we can see there's a path where
Platform Arrange happens => Sets the Frame on VisualElement => this triggers a propertychanged event on Width => propagates to handler => RequestLayout fires.
Because RequestLayout on Android fires up the whole tree this can sometimes cause weird layout loops or excessive measure/layout paths.
My current thinking is that we just need to short circuit the "Handler.Updatevalue" call inside Element if the property change is related to the readonly height/width/x/y properties and we are inside a "BatchCommitted" path.
I also noticed there's a rounding issue that's causing ping ponging when we update the Frame upstream so we should probably account for that as well