fix(forms): preserve intermediate keystrokes in signal formField - #70391
fix(forms): preserve intermediate keystrokes in signal formField#70391shoemoney wants to merge 2 commits into
Conversation
Fix verified RED->GREEN. Signal Forms number [formField] overwrites intermediate keystrokes, dropping - and trailing zeros at control_native.ts:124
| const isFocused = typeof document !== 'undefined' && document.activeElement === input; | ||
| if (!(isFocused && isIntermediate(input.value, controlValue))) { | ||
| setNativeControlValue(input, controlValue); | ||
| } |
There was a problem hiding this comment.
We would need a set of unit tests to illustrate the change.
|
I've run the unit tests added in PR #69637 against this branch to check if they all pass. It seems the current fix in this PR does not fully handle all the edge cases covered by those tests. Specifically, the following 3 tests are failing:
For context, PR #69637 resolved these issues by introducing a custom |
Use strict decimal parsing (Number and parseFloat must agree) instead of Number() alone when reading a numeric text input, so non-decimal literals like 0b0101 and 0x22 are rejected as parse errors instead of silently accepted. Reuse the same strict parser in isIntermediate so a typed -0 is kept on screen instead of being normalized to 0 on the next update pass. Adds unit test coverage for both cases.
|
Added unit tests and switched to a strict decimal parser (Number and parseFloat must agree) shared between isIntermediate and the text-input numeric read path. This fixes the -0 normalization and stops 0b0101/0x22 from being accepted as numbers. Pushed in e3553b8. |
|
|
||
| if (controlValueChanged || radioValueChanged) { | ||
| setNativeControlValue(input, controlValue); | ||
| const isFocused = typeof document !== 'undefined' && document.activeElement === input; |
There was a problem hiding this comment.
I'm not sure if this might cause any problems with SSR because we're calling document. Could I possibly use DOCUMENT to be safer, or is there a reason not to?
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
When a user types an intermediate value into a signal FormField number input (such as
-,1., or1.0), the native control is normalized via valueAsNumber on every keystroke, discarding the raw input. This causes the display to jump and intermediate input to be lost, making it impossible to type decimal numbers naturally.Fixes #69635.
What is the new behavior?
The fix guards the native value write-back when the input is focused and contains an intermediate value. The
isIntermediate()function detects incomplete decimal input (leading-, trailing., strings like1.0that parse to the same numeric value but differ in representation). While intermediate, the raw string is preserved in the DOM until the user blurs the field.Parsing now also goes through a strict decimal parser shared by
isIntermediate()and the text-input numeric read path:Number()andparseFloat()must agree on the same value. This closes two edge cases raised in review:-0is preserved instead of being normalized to0on the next update pass.0b0101and0x22are rejected as parse errors instead of being silently accepted byNumber().Does this PR introduce a breaking change?
Other information
Unit tests cover: preserving
-,.,-., trailing., decimal strings whose numeric values match controlValue but whose string representation differs (e.g.1.0vs1,1.00vs1), preserving a typed-0and-0.5on both a number input and a text input with a numeric model, and rejecting0b0101/0x22as parse errors.