OnIdiom doesn't respect Desktop setting on Windows

[KeithBoynton]

Description

When using this for example:

TextColor="{OnIdiom Desktop='Red', Default='Black'}"

Running a solution on Windows the text is Black when I would expect it to be Red.

It works as expected when running on MacCatalyst, the text is Red. It works as expected when running on iOS, the text is Black. It works as expected when running on Android, the text is Black. It does not work as expected when running on Windows, the text is Black.

Steps to Reproduce

1. Clone the attached project
2. Run the solution on MacCatalyst
3. Observe the text Red (as expected)
4. Run the solution on iOS
5. Observe the text Black (as expected)
6. Run the solution on Android
7. Observe the text Black (as expected)
8. Run the solution on Windows
9. Observe the text Black (NOT expected, Red was expected)

Link to public reproduction project repository

https://bitbucket.org/KeithBoynton/on-idiom-desktop-issue/src/master/

Version with bug

8.0.21 SR4.1

Is this a regression from previous behavior?

Not sure, did not test other versions

Last version that worked well

Unknown/Other

Affected platforms

Windows

Affected platform versions

No response

Did you find any workaround?

No

Relevant log output

No response

[ninachen03]

Verified this issue with Visual Studio 17.10.0 Preview 5 ( 8.0.21).I can not repro this issue.

[KeithBoynton]

Not working for me on Visual Studio 17.10.0 Preview 5 ( 8.0.21)

What am I missing?

[ninachen03]

We have verified that this problem, does not recur on 5 machines. We are not sure why it still reoccurs. Does it occur in a specific environment setting? In order for us to investigate this further, could you provide the Msbuild Log and binLog?

[jfversluis]

Just tried this myself and same here, with your exact code, no changes, I see the text as red so I wonder what the difference is. Also tried a release build and same there.

Can you run dotnet --info and maybe add that info? Make sure you have installed the latest .NET 8 with the .NET MAUI workload?

[KeithBoynton]

Please find attached build output and also the dotnet info. FYI I did a dotnet workload update but it's still the same.

dotnet-info.txt OnIdiom-desktop-issue-build-output.txt

[jfversluis]

Very strange and I don't have a good explanation for it for now unfortunately. This one seems to might be related? #21799

So maybe when that gets merged, that might fix this too

[KeithBoynton]

Ok, I've subscribed to that issue.. however it's a draft and no activity on it for 3 weeks. What's blocking that being merged do we know?

[jonathanpeppers]

#21799 is a performance optimization, it would not fix this.

Looking at the code for Windows:

https://github.com/dotnet/maui/blob/ec3e44c6881d4fd97be3cc52cfc1e2050961c247/src/Essentials/src/DeviceInfo/DeviceInfo.uwp.cs#L68-L87

It will report Tablet if a Windows device is switched into tablet mode. Is that what is happening here?

I'm not sure if there is an actual problem here -- seems expected?

@KeithBoynton maybe you could try calling AnalyticsInfo.VersionInfo.DeviceFamily to debug further.

[daltzctr]

So the behavior in MAUI is definitely wrong, but no fault of MAUI. Windows makes it very problematic to detect when a device is tablet due to inconsistent standards from Windows 7, Windows 8 (mobile) and Windows 11 changing things as well.

Looking at how chromium determines tablet layout for Windows ( https://source.chromium.org/chromium/chromium/src/+/main:base/win/win_util.cc;l=537;drc=ac83a5a2d3c04763d86ce16d92f3904cc9566d3a;bpv=0;bpt=1) and using that as a reference. We come to code that looks like the following (used in a testing app)

        [DllImport("user32.dll", SetLastError = true, CharSet = CharSet.Auto)]
        static extern int GetSystemMetrics(int nIndex);

        [DllImport("Powrprof.dll", SetLastError = true, CharSet = CharSet.Auto)]
        static extern int PowerDeterminePlatformRoleEx(ulong Version);

        [DllImport("User32.dll", SetLastError = true, CharSet = CharSet.Auto)]
        static extern bool GetAutoRotationState(ref int pState);

        static readonly ulong PLATFORM_ROLE = 2;
        static readonly int SM_CONVERTIBLESLATEMODE = 0x2003;
        static readonly int SM_TABLETPC = 0x56;
        static readonly int SM_ISDOCKED = 0x2004;
        static readonly int SM_MAXIMUMTOUCHES = 95;


        public MainPage()
        {
            InitializeComponent();

            idiomText.Text = "Idiom: " + DeviceInfo.Idiom.ToString();
            supportsTabletText.Text = "Supports Tablet: " + (GetSystemMetrics(SM_TABLETPC) != 0).ToString();
            inTabletModeText.Text = "Tablet Mode: " + (GetSystemMetrics(SM_CONVERTIBLESLATEMODE) == 0).ToString();
            isDocked.Text = "Is Docked: " + (GetSystemMetrics(SM_ISDOCKED) == 1).ToString();
            platformRole.Text = "Platform Role: " + PowerDeterminePlatformRoleEx(PLATFORM_ROLE);
            maximumTouches.Text = "Maximum Touches: " + GetSystemMetrics(SM_MAXIMUMTOUCHES).ToString();

            int state = -1;
            bool success = GetAutoRotationState(ref state);

            rotationCheckSuccess.Text = "Rotation Check Success: " + success;
            rotationStateResult.Text = "Rotation Supported: " + ((state & 0xB0) == 0);

        }

On my XPS 15 (Windows 11) that MAUI incorrectly says is a tablet, we compare the diff between another laptop (not-tablet) and we see that the XPS 15 reports that everything is tablet-like (touch points, not-docked, etc) EXCEPT that rotation is not supported.

It also looks like there is a whole bunch of and/but/what-ifs for the different functions above which is why chromium's check is so elaborate.

[KeithBoynton]

#21799 is a performance optimization, it would not fix this.

Looking at the code for Windows:

https://github.com/dotnet/maui/blob/ec3e44c6881d4fd97be3cc52cfc1e2050961c247/src/Essentials/src/DeviceInfo/DeviceInfo.uwp.cs#L68-L87

It will report Tablet if a Windows device is switched into tablet mode. Is that what is happening here?

I'm not sure if there is an actual problem here -- seems expected?

@KeithBoynton maybe you could try calling AnalyticsInfo.VersionInfo.DeviceFamily to debug further.

Thanks @jonathanpeppers that returns Windows.Desktop for me, I've added a debug line and console output to the original repro project.

[jhariel8]

We are experiencing this problem on some Windows machines as well. When can we expect this fix to be released?