fix: force the validation to check for bad user input #4268
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
vursen
force-pushed
the
fix/number-field/validate-for-bad-user-input
branch
from
0b459dc
to
69acea9
Compare
vursen
changed the title
vursen
commented
Jul 22, 2022
| }); | ||
|
|
||
| it('should be valid when committing a valid number', async () => { | ||
| await sendKeys({ type: '1' }); |
There was a problem hiding this comment.
I had no choice other than to use sendKeys here because programmatically setting an invalid value on number inputs is prevented by the browser.
|
Kudos, SonarCloud Quality Gate passed!
|
web-padawan
approved these changes
Jul 22, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
The PR overrides
checkValidityfornumber-fieldto force it to check for bad user input before anything else.Earlier,
number-fieldcould stay valid after you have entered something bad in the case of no constraints. This behavior was coming fromInputConstraintsMixinwhich doesn't check native validity when no constraints. This is generally correct behavior. The exception isinput[type=number]fields where the nativecheckValidityalso checks for bad input.Fixes #4258
Type of change
Checklist