Fix: OnIdiom Default Value Handling for ValueType Properties

[bhavanesh2001]

Description of Change

This PR fixes an issue, where OnIdiom without a default value incorrectly assigns 0 instead of the expected default.

Root Cause

• OnIdiom relies on Activator.CreateInstance(propertyType) when value is null.
• For value types like double Activator.CreateInstance() returns 0.0 , instead of the expected default value (-1) from BindableProperty.GetDefaultValue().

Issues Fixed

Fixes #9978

[jsuarezruiz]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[jsuarezruiz]

/rebase

[StephaneDelcroix]

I wonder if OnIdiom without a default value shouldn't just crash, or at least warn...

[StephaneDelcroix]

I'd need this test in Xaml.UnitTest so we test for all xaml inflators

[StephaneDelcroix]

fix test

[bhavanesh2001]

I wonder if OnIdiom without a default value shouldn't just crash, or at least warn...

I don't think it's crashing. But it assigns 0 instead of -1, (for example HeightRequest) . Which makes the view not appear since height is 0

[StephaneDelcroix]

I don't think it's crashing. But it assigns 0 instead of -1, (for example HeightRequest) . Which makes the view not appear since height is 0

y, it's not crashing. but I wonder if it shouldn't instead of behaving in an unexpected way

[bhavanesh2001]

y, it's not crashing. but I wonder if it shouldn't instead of behaving in an unexpected way

This suggests that defining one platform without a default is allowed — same behavior as OnPlatform.

But yeah, I agree with you — probably shouldn’t behave this way.

maui/src/Controls/src/Xaml/MarkupExtensions/OnIdiomExtension.cs

Lines 34 to 41 in 4f0b3a4

	{
	if (Default == null
	&& Phone == null
	&& Tablet == null
	&& Desktop == null
	&& TV == null
	&& Watch == null)
	throw new XamlParseException("OnIdiomExtension requires a non-null value to be specified for at least one idiom or Default.", serviceProvider);

[bhavanesh2001]

/rebase

[bhavanesh2001]

@StephaneDelcroix I added a unit test. Please take a look. I kept the UItest, let me know if you want it removed.

[StephaneDelcroix]

look at what other tests are doing, in the Issues folder. it needs a xaml and a xaml.cs file. this doesn't test XamlC inflation

[bhavanesh2001]

Yeah, sorry about that — I hadn’t opened Xaml.UnitTests until a few hours ago. :)

[StephaneDelcroix]

thanks. quite there, but not yet. see comment

[kubaflo]

Could you please apply ai's suggestions?

[kubaflo]

/review -b feature/refactor-copilot-yml

[kubaflo]

/review -b feature/refactor-copilot-yml

[kubaflo]

/review -b feature/enhanced-reviewer -p ios

[MauiBot]

⚠️ Merge Conflict Detected — This PR has merge conflicts with its target branch. Please rebase onto the target branch and resolve the conflicts.

[kubaflo]

Can you please resolve conflicts?

[kubaflo]

Thanks for this contribution, @bhavanesh2001! 🙏

Unfortunately this fix is no longer needed — the same root cause was already resolved on main by #29028 (commit 830b8de), which fixed the duplicate issue #13243 ("[Android] FlyoutWidth with OnIdiom shows no flyout").

Both issues share the identical root cause: OnIdiomExtension returned Activator.CreateInstance(propertyType) (i.e. 0) instead of the bindable property's real default (e.g. -1) when no value was supplied for the current idiom. The merged fix applies the same bp.GetDefaultValue(...) approach used here, and is actually slightly broader (it also covers reference-type properties, not just value types). That overlap is what's now producing the merge conflict in OnIdiomExtension.cs.

You can confirm on main:
https://github.com/dotnet/maui/blob/main/src/Controls/src/Xaml/MarkupExtensions/OnIdiomExtension.cs

Because the source fix is already in place, I'd suggest closing this PR. The one piece not covered on main is a XAML-level unit test (#29028 only added UI tests), so if you'd like to keep contributing here, a focused Xaml.UnitTests test asserting the bindable default for unspecified idioms would be a welcome follow-up.

Thanks again for digging into this! 🚀