Force Light theme makes certain controls not change colour

[Spinks90]

Description

Picker has a hover of white text when forcing the light theme.

I've set the background so you can see the text colour.

Loaded page up, selected "This" from the picker:

If you hover over the item it'll turn white:

Since the light theme has a white background you can't read the text.

Steps to Reproduce

1. Create new .NET MAUI app
2. Add a Picker such as

<Picker>
   <Picker.Items>
       <x:String>This</x:String>
       <x:String>is</x:String>
       <x:String>a</x:String>
       <x:String>test</x:String>
   </Picker.Items>
</Picker>

3. Go to App.xaml.cs and set Current.UserAppTheme = AppTheme.Light;
4. Set the background to something easier to see the difference e.g. BackgroundColor="Green" on the ContentPage
5. If you go select item from the picker then go to hover over it. The text will go from black to white and it's not readable.

Link to public reproduction project repository

https://github.com/Spinks90/MauiLightBug

Version with bug

Unknown/Other (please specify)

Last version that worked well

Unknown/Other

Affected platforms

Windows

Affected platform versions

maui-windows 6.0.536/6.0.400

Did you find any workaround?

No response

Relevant log output

No response

Depends on

• Proposal: Support setting/changing Application.Current.RequestedTheme after app constructor (rather than throw exception) microsoft/microsoft-ui-xaml#4474

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[pierre01]

I have the same issue
if I set:

Application.Current.UserAppTheme = AppTheme.Light;

Most controls work well except Radio Buttons and entry when not selected , calendar selected date... and a few others...

[nebula2]

What helped me:

Put AppCompatDelegate.DefaultNightMode = AppCompatDelegate.ModeNightNo; into MainApplication.

[Application]
public class MainApplication : MauiApplication
{
    public MainApplication(IntPtr handle, JniHandleOwnership ownership)
        : base(handle, ownership)
    {
        AppCompatDelegate.DefaultNightMode = AppCompatDelegate.ModeNightNo;
    }

    protected override MauiApp CreateMauiApp() => MauiProgram.CreateMauiApp();
}

found the info on that here: https://stackoverflow.com/questions/69115751/how-to-use-only-light-mode-in-aplication-android-studio

[jinxinjuan]

Verified this issue with Visual Studio 17.7.0 Preview 1.0. Can repro on windows platform with sample project.
MauiLightBug

[Brosten]

I'm also facing this issue.
Works correct if each platform forces the theme by itself, but by using UserAppTheme in the shared app.cs/xaml some controls will render incorrect.

[MartyIX]

Tl:dr:

1. UserAppTheme.Unspecified mostly works and colors of your MAUI elements and native controls will change as you expect.
2. Setting UserAppTheme.Light or UserAppTheme.Dark in your app works for MAUI elements and their properties that specify {AppThemeBinding}s. However, it does not work for native elements because WinUI does not support that at the moment (as of Windows App SDK 1.5).

---

I noticed (as others in this thread) that on Windows:

1. When UserAppTheme is Unspecified and I change theme in Windows (using win key -> Themes and related settings), my controls change properly (in most cases that is)
2. When I set a custom UserAppTheme, then changes are not OK.

So I checked code and when I change the theme in the Windows settings dialog window, then I can see

1. OnActiveWindowThemeChanged method is invoked here

   maui/src/Essentials/src/AppInfo/AppInfo.uwp.cs

   Lines 88 to 92 in cfc5482

   	void OnActiveWindowThemeChanged()
   	{
   	if (Application.Current is Application app)
   	_applicationTheme = app.RequestedTheme;
   	}

2. However, when I set a custom UserAppTheme this method is not called.

So I thought that perhaps Microsoft.UI.Xaml.Application.RequestedTheme was not set correctly when a theme is to be changed by setting UserAppTheme. So I created a simple demo in the sandbox project which sets WinUI's Application.RequestedTheme: https://github.com/MartyIX/maui/tree/feature/2024-05-23-ChangingTheme (MartyIX@c8dd5e3)

... but it crashes. It crashes by design because WinUI's Application.RequestedTheme cannot be set during runtime only when an app starts:

The theme can only be set when the app is started, not while it's running. Attempting to set RequestedTheme while the app is running throws an exception (NotSupportedException for Microsoft .NET code). If you give the user an option to pick a theme that's part of app UI, you must save the setting in the app data and apply it when the app is restarted. (For more info about app settings, see Store and retrieve settings and other app data).

So this is not good. There is also an open issue microsoft/microsoft-ui-xaml#4474 to allow changing RequestedTheme at runtime but at the moment it's not supported.

The only thing that is supported now is:

You can change specific theme values at run-time after Application.RequestedTheme is applied, if you use the FrameworkElement.RequestedTheme property and set values on specific elements in the UI.

But honestly you would have to traverse your app's elements and change them one at a time ... sounds slow and error prone.

I hope this is an accurate report with regarding to changing app theme at runtime for the Windows platform. If you can spot an error, please let me know.

[samhouts]

Thanks @MartyIX !!

It looks like this issue has workarounds and dependencies. We'll continue working with the Windows team on this one.

[MartyIX]

For Windows, one can use this workaround: microsoft/microsoft-ui-xaml#4474 (comment). However, its use is quite limited because it works only on visible elements. Any help in improving it is welcome.

[MartyIX]

I just wrote a comment here #21042 (comment) which feels relevant for this issue as well (for WinUI, that is). It's a workaround but for some people it might be "good enough".