Fix InputSelect not handling null for nullable bool

[m-e-lloyd]

Fix nullable bool parsing on InputSelect component

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.

Summary

This PR fixes an issue in InputSelect where setting the value to null for a nullable boolean (bool?) would fail to correctly parse a null value.

The root cause was that InputSelect did not handle null values correctly. This fix adds a null check in InputSelect to allow CurrentValue to be set to null.

Description

When binding a bool? to a InputSelect compoenent, the current implementation of FormatValueAsString(TValue value) does not handle null values and always returns true or false.

Changes:

• Added null handling in InputSelect for bool?.
• Updated ParsesNullWhenUsingNullableBool test to confirm null is correctly handled.
• Minor test model adjustment (NullableBool)

Fixes #54565

[m-e-lloyd]

@dotnet-policy-service agree

[ilonatommy]

Let's add symmetric test to int/guid coverage:

• ParsesCurrentValueWhenUsingNullableBool
• ParsesCurrentValueWhenUsingNotNullableBool

[ilonatommy]

This change should be done as a part of more complex fix that contains also improving #41222.

[m-e-lloyd]

This change should be done as a part of more complex fix that contains also improving #41222.

Potentially although it would depend on the approach taken to fix that issue. If the fix were to try and mirror the state of the HTML (i.e. when the select element automatically is displaying the first option, update the bound value to reflect the first option) then these two cases would be unlikely to intersect. I personally think this is probably a good approach as it is more reflective of the actual behaviour of a select element and so more intuitive for someone with little or no blazor experience.

It is also possible other approaches don't intersect with this particular issue, and from the discussion it doesn't seem there is an agreed upon way to approach this yet.

[m-e-lloyd]

This change should be done as a part of more complex fix that contains also improving #41222.

Potentially although it would depend on the approach taken to fix that issue. If the fix were to try and mirror the state of the HTML (i.e. when the select element automatically is displaying the first option, update the bound value to reflect the first option) then these two cases would be unlikely to intersect. I personally think this is probably a good approach as it is more reflective of the actual behaviour of a select element and so more intuitive for someone with little or no blazor experience.

It is also possible other approaches don't intersect with this particular issue, and from the discussion it doesn't seem there is an agreed upon way to approach this yet.

I've had more of a look at this today. To do what I thought would be a good idea, seems like it would probably involve JS interop and so may not be a great candidate. Alternatively, a solution could involve inspecting the ChildContent render fragment and contionally adding a RenderFragment with something like <option value=""></option> at the start if there is not already one with an empty string value. In either of these cases, It seems like this modification would still be neccesary.

Apologies for going off topic on this a little bit, this is just something that pops up more in my own projects.

[javiercn]

@m-e-lloyd thanks for the additional details.

Mostly we want to avoid doing a set of "local" fixes (that might conflict with each other) and take a more complete look to better define how everything should work. There are several issues that came up with null support, we did fixes and more issues popped up afterwards, so we want to make sure we do "fix it for good" the next time around.

I think we are going to hold off on the current change until we get some cycles to figure that out.

[robinwilson16]

As this has been broken since .NET 8 would it not be better to fix this specific issue with Bool? not being correctly handled in a SelectList, otherwise if merged with other bugs and issues I feel this might just delay the fix further.
This is a shame when a working code fix was provided back in March 2024 to stop it converting a NULL to a FALSE yet the change has never been implemented into any subsequent versions of .NET.
It was working correctly in older .NET versions, and forms with mandatory yes/no questions are quite a common requirement and it's easy to reproduce this specific issue.