OrientationStateTrigger seems to be setting the wrong Orientation?

[joshuacookdev]

Description

Part of me thinks that I might be mistaken here, but when testing these orientations directly as attributes on the StackLayout, they are arranged as I would expect. When using OrientationStateTriggers to fire Setters on the StackLayout's orientation, the Orientation being set appears to be backwards even when other settings are correct for the OrientationState that should be triggered.

It's hard to explain without saying Orientation a dozen times, so I took screenshots and have a sample repo here.

In this image, I have the device set to portrait orientation. Given the XAML in the VisualStateGroup, I expect the screen to be red and vertically aligned. Instead, it is horizontal (while still red).

The alternative orientation should be a blue background with a horizontal_ orientation for the stack layout, but instead has a vertical orientation (still blue, though).

I apologize if this isn't a bug and I've just done something incorrectly - I'm willing to answer any questions necessary to troubleshoot as well.

Notes on versioning: dotnet version: 6.0.400-preview.22330.6 maui-android workload manifest version 6.0.486/6.0.400 VS version: 17.3.32728.150 (updated prior to testing this)

Steps to Reproduce

1. Clone the sample repo
2. Start the project on an Android emulator (I tried the default Pixel 5)
3. You may have to turn on auto-rotate in the emulator device settings.
4. If the orientation seem fine, change the orientation once or twice via the emulator controls - the state trigger updates are causing the issue it seems.

Version with bug

6.0.400

Last version that worked well

Unknown/Other

Affected platforms

Android, I was not able test on other platforms

Affected platform versions

Android 12.0 - API 31 (default Pixel 5)

Did you find any workaround?

No response

Relevant log output

No response

[joshuacookdev]

I'm on a personal device but can test this further on physical Android hardware and on iOS emulators/hardware on Wednesday if need be.

[ghost]

Hi @joshuacookdev. We have added the "s/needs-repro" label to this issue, which indicates that we require steps and sample code to reproduce the issue before we can take further action. Please try to create a minimal sample project/solution or code samples which reproduce the issue, ideally as a GitHub repo that we can clone. See more details about creating repros here: https://github.com/dotnet/maui/blob/main/.github/repro.md

This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[joshuacookdev]

@jsuarezruiz I created a repro project and originally linked it in the description - but I'll add it again here. I'm not entirely sure if the behavior still exists as stated - I've moved over to Kotlin work full-time recently. I'll check when it again when I get some time to play with MAUI development again (maybe this weekend?).

Sample repo: https://github.com/joshuacookdev/MauiIssue9227

[FedericoNembrini]

Probably related https://github.com/dotnet/maui/issues/7134

[mattleibow]

I noticed it started working when I wrapped the stack in another stack. So I am wondering if the fact is really the root container needs to be a layout otherwise the re-layout calls do nothing.

This hierarchy worked for me:

<ScrollView>
    <Grid>
        <StackLayout>

I also got it to work removing the ScrollView as well, so this may be an issue with that control rather than the layout. Or both together.

[ghost]

We've added this issue to our backlog, and we will work to address it as time and resources allow. If you have any additional information or questions about this issue, please leave a comment. For additional info about issue management, please read our Triage Process.

[jinxinjuan]

Verified this issue with Visual Studio Enterprise 17.7.0 Preview 2.0. Can repro on Android platform with sample project. MauiIssue9227