Setting ThemeMode on a window causes a button to be positioned differently

[adegeo]

Description

Setting ThemeMode on a window causes a button to be completely repositioned.

Reproduction Steps

1. Brand new WPF project.
2. Add a button to the grid and set the width/height to something small.
3. Set the ThemeMode property on the window to anything other than None.

<Window x:Class="Names.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:local="clr-namespace:Names"
        mc:Ignorable="d"
        Title="MainWindow" Height="300" Width="400" ThemeMode="System">
    <Grid>
        <Button Width="200" Height="30" />
    </Grid>
</Window>

Before ThemeMode is set:

After ThemeMode is set:

Expected behavior

Don't alter the layout.

Actual behavior

Layout is altered.

Regression?

No response

Known Workarounds

No response

Impact

No response

Configuration

• Visual Studio 2022 17.12 GA
• .NET 9 GA

Other information

No response

[lindexi]

@adegeo

The style define is in \src\Themes\PresentationFramework.Fluent\Styles\Button.xaml

wpf/src/Microsoft.DotNet.Wpf/src/Themes/PresentationFramework.Fluent/Styles/Button.xaml

Line 25 in d4bb347

<Setter Property="HorizontalAlignment" Value="Left" />

See #8870

And in WinUI, the default button style is also left-aligned, so I think this style is appropriate here. What do you think?

[h3xds1nz]

And in WinUI, the default button style is also left-aligned, so I think this style is appropriate here. What do you think?

@lindexi I for one think that's wrong, because this means that simply migrating your existing WPF app, you will have to do a full sweep for the GUI and add the alignment properties (sure, there's padding, font size, etc. but this is an additional step). That essentially "breaks" everyone's GUI after opting-in. I've seen it yesterday in the XAML and when testing the access keys, before this issue got posted and well, made me sad.

Fun fact is though, you can't realistically fix this now this has been shipped.

• Fixing it in a servicing release means you adjust the default behaviour on the fly, that's unacceptable.
• Fixing it in next major release, oh well, let's have fun resetting alignment once again for developers that went through the migration — then again, given the amount of missing controls, styles, and functionality, and theme marked as experimental, I'd hope people will accept the theme only for evaluation and it can be adjusted to behave same as rest of the WPF themes in .NET 10.

[miloush]

Any of the theme stuff can certainly be fixed, it's all experimental. No one should be using it in production.

[lindexi]

That essentially "breaks" everyone's GUI after opting-in.

@h3xds1nz Yeah, I think you have a very convincing case.

And I add the PR here #10082

And maybe we need to review the layout of all other controls