Depends onhttps://github.com/MudBlazor/Workflows/tree/main/.github/workflows

Depends onhttps://github.com/MudBlazor/Workflows/tree/main/.github/workflows

MudBlazor/Workflows#9

I thinkSetColorInput_InvalidNoChange is broken because of this changedotnet/aspnetcore#63254.
The color#8qb829ff is not a valid hex format, andMudColor will throw aSystem.FormatException: The input string '8q' was not in a correct format. This happens somewhere in the Blazor lifecycle when the invalid parameter value is accepted (probably inSetParametersAsync). Now, when an exception occurs,StateHasChanged is not automatically called, so we don't see the DOM refresh that picker defaulting the invalid input to#594ae2. You can see that in viewer if you openSimpleColorPickerTest and do it by hands, and then compare the behavior with the previous .NET version.

FYI I asked Gemini 3.0 Pro to fix the tests and it ran for over an hour on that single request and got pretty much nowhere. It's clearly missing the same knowledge that I don't have

We could try out upgrading to bunit2.x.x. It's a new major version that was released yesterday.However, there are some (or maybe a lot of) breaking changes.Here is the Migration Guide.

Edit 1: Yes, it's a lot 😅

Edit 2: I was able to reproduce the test failure ofNumericFieldTestCultureFormat in an extra project. Upgrading to the latest bunit version didn't solve the issue.

@copilot revert that last PR.

Reverted the test fixes in commitb74a3de. The 3 test files are back to their original state and the tests are failing again as before.

s broken because of this changedotnet/aspnetcore#63254.

Maybe, I was wrong about identifying the root cause. I tried to override theSetParametersAsync with the old behavior by copy-pasting the old MSFT code, and it didn't fix the issue.
For now I have no lock with the color picker, I tried to even get the reference ofMudTextField and force refresh it, and nothing.

@danielchalmers@versile2
When I replaced

<MudTextFieldT="string"Value="@GetColorTextValue(_valueState.Value)"ValueChanged="SetInputStringAsync"Class="mud-picker-color-inputfield"Variant="Variant.Outlined"MaxLength="@GetHexColorInputMaxLength()"HelperText="HEX"Required="@Required" />

To simple

<inputtype="text"@bind:get="@GetColorTextValue(_valueState.Value)"@bind:set="SetInputStringAsync" />

TheSetColorInput_InvalidNoChange test started to pass, so the problem is somewhere in our input components. It seems that the input component’s modifying of get/set and writing to parameters directly is starting to backfire.

Something related with:

The problem exist before and after the:#10357
So it's not a problem within the color picker, but the:

Something related with:

MudBlazor/src/MudBlazor/Components/Input/MudInput.razor.cs

Line 16 in01827d8

privatestring?_internalText;

When you set#8qb829ff it doesn't go back to#594ae2 even despite the:

MudBlazor/src/MudBlazor/Components/ColorPicker/MudColorPicker.razor

Line 237 in01827d8

Value="@GetColorTextValue(_valueState.Value)"

returning the#594ae2 so something is out of the sync.

The problem exist before and after the:#10357 So it's not a problem within the color picker, but the:

MudBlazor/src/MudBlazor/Components/TextField/MudTextField.razor

Line 26 in01827d8

<MudInputT="string"

Doesn't help those components are easily the most complicated

IMO I don't agree with that aspnetcore change, it seems poorly thought out and implemented (The comments in the file contradict themselves) but putting that aside, I believe what the intended solution should be is something like this

copilot/add-dotnet-10-target...timmac-qmc:MudBlazor:copilot/add-dotnet-10-target

Again, this is more just a proof of concept for consideration than a complete solution.

Just a small update. I think I’ve finally tracked down the root cause of the issue and what changed in .NET 10dotnet/aspnetcore#64203
While debugging, I noticed the same behaviorSetParametersAsync simply isn’t being called anymore in situations where it used to be. This happens because we’re setting parameters directly, and that leads to the new behavior. Javiercn goes into detail about why this is happening.

I actually started working on a fixing that
#12241#12244
The tricky part is that I can’t just fix Text and Value inMudInput/MudInputBase right away, since other components also write parameters directly. As I explained in#12241, our current parameter state handling doesn’t deal with that very well, so I need to address it from the top down.

My hope is that#12259 (and a similar PR forValue) will either solve the issue outright or at least make debugging much easier, since incorrect parameter behavior should no longer get in the way.

The colorColorPickerTests.SetColorInput_InvalidNoChange is not an issue anymore. For the numeric test, I know that settingTextUpdateSuppression fixes the problem. I feel like we should remove it at some point since it causes a lot of problems for the_internalText synchronization in MudBaseInput, the original problem why this was added for BSS should probably solved differently.

This PR#12272 + removal ofTextUpdateSuppression does fixes the problems. I have verified that all tests pass.