Using <WindowChrome.WindowChrome> on WPF Window turns floating hints background black

[mr-luiks]

Bug explanation

Using

<WindowChrome.WindowChrome>
    <WindowChrome />
</WindowChrome.WindowChrome>

tags on WPF Window turns floating hints background and border black

this issue started on 5.0.1-ci615

<Window 
    x:Class="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:WpfApp1"
    mc:Ignorable="d"
    xmlns:materialDesign="http://materialdesigninxaml.net/winfx/xaml/themes" 
    TextElement.Foreground="{DynamicResource MaterialDesign.Brush.Foreground}"
    Background="{DynamicResource MaterialDesign.Brush.Background}"
    FontFamily="{DynamicResource MaterialDesignFont}"
    WindowStartupLocation="CenterScreen" 
    Title="MainWindow" Height="125" Width="278"
    TextElement.FontWeight="Regular"
    TextElement.FontSize="13"
    TextOptions.TextFormattingMode="Ideal" 
    TextOptions.TextRenderingMode="Auto"        
    ShowInTaskbar="True" 
    ResizeMode="NoResize"
>

    <WindowChrome.WindowChrome>
        <WindowChrome />
    </WindowChrome.WindowChrome>

    <Grid>
        <TextBox
            Style="{StaticResource MaterialDesignFloatingHintTextBox}"
            materialDesign:HintAssist.Hint="Hint Hint Hint"
            VerticalAlignment="Center"
            HorizontalAlignment="Center"
            Text="Text Text Text Text Text"
        />
    </Grid>

</Window>

Version

5.0.1-ci633

[mr-luiks]

using DrawerHost fixes floating hint background issue tough.

but i also noticed that foreground is different from release version and pre-release version. on 5.0.0 floating hint foreground colour is muted version of a elements foreground colour. on pre-release it is a same colour. is this a new look or is a bug?

[nicolaihenriksen]

... but i also noticed that foreground is different from release version and pre-release version. on 5.0.0 floating hint foreground colour is muted version of a elements foreground colour. on pre-release it is a same colour. is this a new look or is a bug?

This was probably something that happened while aligning the "field" styles while incorporating the new SmartHint. Judging from the MD2 "spec" I would say it is a bug though. @Keboo thoughts?

[nicolaihenriksen]

@mr-luiks Have you tried setting the Style on the window explicitly: Style="{StaticResource MaterialDesignWindow}"

[mr-luiks]

@mr-luiks Have you tried setting the Style on the window explicitly: Style="{StaticResource MaterialDesignWindow}"

yes, this is how i apply window style for my program and result is same as previous examples.

[Keboo]

... but i also noticed that foreground is different from release version and pre-release version. on 5.0.0 floating hint foreground colour is muted version of a elements foreground colour. on pre-release it is a same colour. is this a new look or is a bug?

This was probably something that happened while aligning the "field" styles while incorporating the new SmartHint. Judging from the MD2 "spec" I would say it is a bug though. @Keboo thoughts?

Yea I am thinking it looks like a bug. From the spec I would expect the floating color to follow the primary color.

[nicolaihenriksen]

@Keboo I think what the OP is referring to here is not actually the floating color, but rather that the resting color should be a dimmed version of the TextElement.Foreground color.

The floating color I believe is correct, it follows the primary color when the control has focus, otherwise it falls back to TextElement.Foreground.

Also, it is obvious that there is a difference when looking at the SmartHint demo page. It seems the outlined style is correctly dimming the hint, whereas the other styles are not.

This is the same for all the input controls; I'll have a look at aligning that across the styles.

[Keboo]

@nicolaihenriksen ah thank you, yes i misread the original issue. And thank you for the PR

[nicolaihenriksen]

@mr-luiks @Keboo after digging a little, I can see that this is the PR that introduced the issue: #3544

Reverting that change fixes the chrome issue, but of course re-introduces the clipping issue which the PR was fixing.

I'll spend some time looking into a solution...