fix(cdk/testing): unable to assign value to number inputs using sendKeys #22395
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
crisbeto
added
P3
google-cla
bot
added
the
cla: yes
Currently the `UnitTestElement` simulates typing into an input by assigning the value character-by-character and dispatching fake events along the way. The problem is that for input types that require the value to be in a particular format (e.g. `number`, `color`, `date`) doing so will temporarily assign an invalid value which will be rejected by the browser with a warning like `The specified value "12." cannot be parsed, or is out of range.`. This can become a problem for some common use cases like the `ReactiveFormsModule` where a directive might be keeping track of the value by looking at the DOM inside of an `input` event (e.g. the `FormControl` directive does this). These changes resolve the issue by looking at the type of the input, and if it's a type that requires a specific format, we assign the value immediately. Fixes angular#22129.
crisbeto
force-pushed
the
22129/input-type-keys
branch
from
28b04dd
to
2ddcf34
Compare
mmalerba
pushed a commit
that referenced
this pull request
Apr 13, 2021
…eys (#22395) Currently the `UnitTestElement` simulates typing into an input by assigning the value character-by-character and dispatching fake events along the way. The problem is that for input types that require the value to be in a particular format (e.g. `number`, `color`, `date`) doing so will temporarily assign an invalid value which will be rejected by the browser with a warning like `The specified value "12." cannot be parsed, or is out of range.`. This can become a problem for some common use cases like the `ReactiveFormsModule` where a directive might be keeping track of the value by looking at the DOM inside of an `input` event (e.g. the `FormControl` directive does this). These changes resolve the issue by looking at the type of the input, and if it's a type that requires a specific format, we assign the value immediately. Fixes #22129. (cherry picked from commit 2f177b6)
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently the
UnitTestElementsimulates typing into an input by assigning the value character-by-character and dispatching fake events along the way. The problem is that for input types that require the value to be in a particular format (e.g.number,color,date) doing so will temporarily assign an invalid value which will be rejected by the browser with a warning likeThe specified value "12." cannot be parsed, or is out of range..This can become a problem for some common use cases like the
ReactiveFormsModulewhere a directive might be keeping track of the value by looking at the DOM inside of aninputevent (e.g. theFormControldirective does this).These changes resolve the issue by looking at the type of the input, and if it's a type that requires a specific format, we assign the value immediately.
Fixes #22129.