ScrollView content needs layout when ScrollView.InvalidateMeasure is called

[spadapet]

Description of Change

When ScrollView.Content changes its alignment (like HorizontalOptions change from Start to End), then the ScrollView's layout needs to properly update. It worked on Android and Mac/iOS, but Windows would not update layout until the window was resized.

After HorizontalOptions changed on the content, Windows would call InvalidateMeasure on the WinUI ScrollView, but the child content didn't get updated. This change makes sure that the content also gets measured.

This fix is helpful for XAML Hot Reload, so the layout will update as HorizontalOptions changes.

Issues Fixed

Fixes #14377

[spadapet]

Ah! Deleted the wrong branch by accident. Good thing I could restore it and reopen this PR.

[spadapet]

Ping @PureWeen, @hartez for review

[hartez]

@spadapet I think you're on the right track, but the re-mapping of the InvalidateMeasure command could cause problems for users who've modified the base mapping. @PureWeen and @mattleibow and I are working out how we can handle this sort of Core-level remapping to avoid that problem (#17918).

In the meantime, I dropped the TestContentHorizontalOptionsChanged test into the main branch and ran it on Windows without the other code changes, and it passes. The bug seems to be real - if I put the same structure in an app, the horizontal options definitely aren't updating. Maybe the test is giving a false positive?

[spadapet]

@spadapet I think you're on the right track, but the re-mapping of the InvalidateMeasure command could cause problems for users who've modified the base mapping. @PureWeen and @mattleibow and I are working out how we can handle this sort of Core-level remapping to avoid that problem (#17918).

In the meantime, I dropped the TestContentHorizontalOptionsChanged test into the main branch and ran it on Windows without the other code changes, and it passes. The bug seems to be real - if I put the same structure in an app, the horizontal options definitely aren't updating. Maybe the test is giving a false positive?

@hartez thanks for looking, I'll re-check the scenario with and without the fix. I'm pretty sure the test used to fail on Windows without the fix.

And this fix can wait for #17918 if necessary.

[spadapet]

In the meantime, I dropped the TestContentHorizontalOptionsChanged test into the main branch and ran it on Windows without the other code changes, and it passes. The bug seems to be real - if I put the same structure in an app, the horizontal options definitely aren't updating. Maybe the test is giving a false positive?

@hartez I found out that if I added a delay in the test, then the bug does repro. Without the delay, it's too fast for the UI to render and the bug doesn't repro. Since that doesn't quite make sense to me yet, I'll push new changes once I understand that a little more.

[spadapet]

@hartez, @PureWeen, my latest pushed changes are ready for review. Although I know the pending draft PR #17918 might affect my fix. If I have to wait for that other PR, let me know.

I feel weird adding an await Task.Delay into the test, but without that, the UI doesn't render and the bug doesn't repro. I'm probably missing some other better method call that allows rendering to happen. Suggestions?

[spadapet]

@hartez, @PureWeen, any more comments?

[hartez]

@hartez, @PureWeen, any more comments?

Sorry, this week was overwhelmed by launch stuff, travel, and upcoming holidays.

@mattleibow and @PureWeen - any reason we can't take this as-is, and then update it ourselves pending the outcome of #17918?

[PureWeen]

/rebase