Setting Background to null will update rendering on Android and iOS

[spadapet]

Description of Change

When Background was set to null for some ViewElements, the Background of the platform element wasn't updated at all for Android and iOS. I just removed the "if" check that skipped setting Background to null.

Issues Fixed

Fixes #24725
Fixes #22914

(maybe more if you look at similar bugs linked in those bugs)

[PureWeen]

Yea, this is somewhat intentional, but we didn't really stay consistent here with WinUI unfortunately which makes this confusing.

The one problem with null is that it's somewhat undefined. Like, when you set the xplat background to null what does that mean?

For WinUI when you set it to null it basically reverts the style back to the templated style. This choice is a bit random because in WinUI land setting a background to "null" actually has a different meaning then reverting it or setting it to transparent. I wish we never would have done this on WinUI because now it's just confusing.

So, in theory for Android and iOS if we were to stay consistent,setting to null would mean revert to platform defaults (I haven't quite looked here if that's what you're doing)

It becomes really, really hard to define what "null" means across the spectrum of all properties you can possibly set and then trying to extract those from the platform.

Realistically if you want to "Clear" a property what you should do is call "ClearValue" on the property at which point it will revert back to whatever your style is for that property.

We haven't really seen a lot of movement on this being a problem for users that "null" is essentially a noop, so we haven't really made an effort to make "null" do anything.

[spadapet]

Yea, this is somewhat intentional, but we didn't really stay consistent here with WinUI unfortunately which makes this confusing.

@PureWeen thanks for looking, I understand more now.

I think in the code I'm changing, the final computed Background brush is being used. So it's not just what the Label has directly set on it, but it takes applied styles into account.

My change is just expanding a previous PR from @rmarinho :

• [Android,iOS] Fix Selection on CollectionView and VSM color changes for Layouts #7689

That PR limited the fix to Layout, I made it include everything.

I started looking into this based on customer feedback. A customer showed me a bug where he was using XAML Hot Reload, typed Background="Yellow" on a Label, then deleted it. But the Label stayed yellow. The same bug applies to ContentPage, Border, etc.

Plus my bug is a dupe of another customer's bug:

• Setting BackgroundColor to null does not actually changes BackgroundColor #22914

So there are some customers hitting the bug. I just don't know all of the little details of background=null. If this PR doesn't get in, then I could add a workaround in XAML Hot Reload, but that is not ideal since it involves rebuilding the element from scratch.

[PureWeen]

Plus my bug is a dupe of another customer's bug:

Yea, this is somewhat the same point. The fact that this works on Windows I think was a huge mistake on our part. Making sure to define "null" for every platform color property starts to gets a bit complicated.

Like, let's say that the user has set the background to "yellow" in styles on initial load and then they change it to purple and then set it to null. What should we do here?

The idea with MAUI is that all color-based properties would have a default color. That's why we include a style.xaml with MAUI templates. Then whenever the user calls "ClearValue" that would just reset to the defined style color.

I started looking into this based on customer feedback. A customer showed me a bug where he was using XAML Hot Reload, typed Background="Yellow" on a Label, then deleted it. But the Label stayed yellow. The same bug applies to ContentPage, Border, etc.

I would be curious in XAML Hot reload what is happening when you set "Background" to "Yellow" and then you delete it. Is it setting "Background" to null? Or is it calling "ClearValue" with some level of setter specificity on "Background"

That PR limited the fix to Layout, I made it include everything.

Yea, @rmarinho's change was specific to layouts because we know what the default backgroundcolor for those controls are since they are just custom views. I don't know if we can generally apply this to every control. For example, have we confirmed that the default color for the Android Switch control is null? And a Button? And a slider?

[spadapet]

@PureWeen,

The fact that this works on Windows I think was a huge mistake on our part. Making sure to define "null" for every platform color property starts to gets a bit complicated.

Like, let's say that the user has set the background to "yellow" in styles on initial load and then they change it to purple and then set it to null. What should we do here?

In WPF that would be clear: a null brush is transparent and not hit-testable. Maybe MAUI can't get that behavior on every platform. But in this bug, Background is never actually set to null, it's just that there is no style applied to the Label, so it ends up with the Brush.Default value (which is a null color). Normally Label's have a style with a default Background, so this bug only affects people that specifically remove default styles.

The idea with MAUI is that all color-based properties would have a default color. That's why we include a style.xaml with MAUI templates. Then whenever the user calls "ClearValue" that would just reset to the defined style color.

I would be curious in XAML Hot reload what is happening when you set "Background" to "Yellow" and then you delete it. Is it setting "Background" to null? Or is it calling "ClearValue" with some level of setter specificity on "Background"

BindableObject.ClearValue is called when XAML Hot Reload removes the Background property. I mentioned this above, but Background is never actually set to null.

That PR limited the fix to Layout, I made it include everything.

Yea, @rmarinho's change was specific to layouts because we know what the default backgroundcolor for those controls are since they are just custom views. I don't know if we can generally apply this to every control. For example, have we confirmed that the default color for the Android Switch control is null? And a Button? And a slider?

I see. If the multi-platform complexities make this difficult to fix in MAUI, I can look into having XAML Hot Reload rebuild the whole control when Background is removed, or just live with the bug since the behavior is undefined anyway.

[spadapet]

Closing this, based on the discussion. This PR shouldn't break an intentional design with platform defaults.