Thanks to visit codestin.com
Credit goes to github.com

Skip to content

MudNumericField: Don't reformat text while typing with Immediate#13311

Merged
danielchalmers merged 1 commit into
MudBlazor:devfrom
danielchalmers:claude/vigilant-hodgkin-aab4b6
Jun 18, 2026
Merged

MudNumericField: Don't reformat text while typing with Immediate#13311
danielchalmers merged 1 commit into
MudBlazor:devfrom
danielchalmers:claude/vigilant-hodgkin-aab4b6

Conversation

@danielchalmers

@danielchalmers danielchalmers commented Jun 18, 2026

Copy link
Copy Markdown
Member

Fixes #13266
Fixes #13250
Related to #13002

Problem

When Immediate="true" and a managed format (Format, Pattern, or an explicit Culture) is set, MudNumericField reformatted the input text on every keystroke. This rewrote the box and moved the caret to the end after the first character, making multi-digit and decimal entry impossible:

This is a regression from v8.x, which only applied the format on blur. It was introduced in #12766 (v9.1.0), which added a reformat block to OnInputValueChanged to fix a .NET 10 blur-timing issue (#12677) — but that block also runs on oninput (every keystroke) when Immediate=true.

Fix

OnInputValueChanged is wired to the inner MudInput.ValueChanged, which fires on oninput when Immediate=true and on onchange (a commit) when Immediate=false. The reformat now skips the live oninput path:

- if (UsesManagedFormatting && DebounceInterval <= 0 && !ConversionError)
+ if (!Immediate && UsesManagedFormatting && DebounceInterval <= 0 && !ConversionError)

So the raw text is preserved while typing and the value is reformatted on blur (OnBlurredAsync, unchanged) — restoring the v8.x / Immediate="false" behavior. The value still tracks every keystroke. The non-Immediate commit reformat that fixed #12677 is untouched, and the debounce path (DebounceInterval > 0, which already short-circuits this block) is unchanged.

Repro (before this PR)

  1. <MudNumericField Immediate="true" Format="F3" T="double?" />
  2. Type 1234 one digit at a time → field snaps to 1.000 after the first key and you can never enter the rest.
  3. Same in the DataGrid numeric filter (it always renders Immediate="true" with the column Culture bound): typing 1.008 produces 1008.

After this PR the text stays raw while typing (1234, 1.008) and is formatted on blur.

Tests

Checklist:

  • I've read the contribution guidelines
  • My code follows the style of this project
  • I've added or updated relevant unit tests

When Immediate=true and a managed format (Format, Pattern, or an explicit
Culture) is set, MudNumericField reformatted the input text on every
keystroke, jumping the caret to the end and making multi-digit/decimal entry
impossible. Typing "1234" with Format="F3" collapsed to "1.000", and the
DataGrid numeric filter dropped the "." and the "0" when typing "1.008".

OnInputValueChanged is wired to the inner MudInput.ValueChanged, which fires
on oninput (every keystroke) when Immediate=true and on onchange (commit)
when Immediate=false. The reformat block now skips the live oninput path via
!Immediate, so the raw text is preserved while typing and the value is
formatted on blur instead (OnBlurredAsync), matching the non-Immediate
behavior and the pre-v9.1 formatting. The non-Immediate commit reformat that
fixed MudBlazor#12677 is unchanged.

Fixes MudBlazor#13266
Fixes MudBlazor#13250
@danielchalmers

danielchalmers commented Jun 18, 2026

Copy link
Copy Markdown
Member Author

This PR fixes the Immediate + managed-format regression at its source (MudNumericField.OnInputValueChanged). While investigating, two secondary symptoms were found in the linked threads that this PR does not address, because they come from a different mechanism:

  1. DebounceInterval cursor-jump — #13266 (comment): with DebounceInterval + Format, once the interval elapses mid-typing the text reformats and the caret jumps to the end. "Unworkable with Format="F3"."
  2. MudTextField + @bind-Value + Format — the #13002 snippet actually uses MudTextField<decimal?>, not the numeric field, and reports the same "formats while I type" behavior ("I get 1.00234").

The suspected shared root cause is the value→text resync running while the input is focused — MudBaseInput.OnValueParameterChangedAsync calls UpdateTextPropertyAsync(false) on a parent-driven value change with no _isFocused guard, whereas MudBaseInput.SetParametersAsync does guard the analogous path (if (_isFocused && !valueChanged && !_forceTextUpdate) return;). That asymmetry looks like the lead.

Neither secondary case could be reproduced in bUnit. bUnit renders synchronously, so the @bind-Value round-trip completes within the same dispatch and the SetParametersAsync _isFocused guard catches it — a standalone and a two-way-bound MudTextField<decimal?>/MudNumericField<double?> both keep the raw text (1234) while typing in tests. The real reports are Server/Hybrid and timing-sensitive ("if I type too slow"), which points to an async re-render landing between keystrokes — something bUnit's model doesn't exercise. Pinning it down likely needs a real Server/Hybrid repro or a targeted test that injects an async re-render mid-type.

Also distinct: #11818. The v8.11 "filter doesn't allow decimals / not a valid number" report predates the v9.1 reformat regression and is a separate culture/parsing issue. Not related to this PR.

@mudbot mudbot Bot added bug Unexpected behavior or functionality not working as intended regression Previously worked and now doesn't labels Jun 18, 2026
@danielchalmers danielchalmers merged commit 20ac7ce into MudBlazor:dev Jun 18, 2026
11 checks passed
@danielchalmers danielchalmers deleted the claude/vigilant-hodgkin-aab4b6 branch June 18, 2026 23:07
This was referenced Jul 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Unexpected behavior or functionality not working as intended regression Previously worked and now doesn't

Projects

None yet

1 participant