feat!: refuse text values the browser physically prevents in TextFieldTester and TextAreaTester - #252
Merged
Conversation
`TextFieldTester.setValue` and `TextAreaTester.setValue` used to accept a value no user could have typed. `maxLength` truncates the characters over the limit in the browser and `allowedCharPattern` filters out the keystrokes it does not match, so both testers now refuse such a value with an `IllegalArgumentException` instead of committing it and leaving the field invalid. `TextAreaTester.setValue(null)` gets the same guard `TextFieldTester` has, so it fails with that message rather than an opaque reflection wrapper around Flow's `NullPointerException`. The validation-only constraints are untouched: `minLength`, `pattern` and required still commit the value and leave the field invalid, which is the state a validation test needs to reach. Fixes #248
The `getEmptyValue()` guard now lives in `TextInputConstraints` next to the typing restrictions, so both text testers call it instead of keeping their own copy, and the code point lookup uses `Character.toString`. Three cases the tests left open are pinned: a `maxLength` of zero is a limit of zero rather than an unset limit, emptying the field stays possible under any limit, and an `allowedCharPattern` that is not a regular expression restricts nothing, as the browser only warns about it. The two validation tests now also assert the field is left invalid, which is the half of the contract they claim to cover.
Contributor
Test Results1 537 tests 1 537 ✅ 45s ⏱️ Results for commit 9dc8290. ♻️ This comment has been updated with latest results. |
mcollovati
approved these changes
Sep 19, 2026
mcollovati
pushed a commit
that referenced
this pull request
Sep 21, 2026
…dTester and TextAreaTester (#252) (CP: 25.3) (#256) This PR cherry-picks changes from the original PR #252 to branch 25.3. --- #### Original PR description > ## Summary > > `TextFieldTester.setValue` and `TextAreaTester.setValue` used to accept values a real user could never type, such as text longer than `maxLength` or characters that `allowedCharPattern` blocks. They now refuse those values with an `IllegalArgumentException`, so a test cannot reach a state the browser would never produce. > > Fixes #248 > > ## What changed > > **Breaking:** `setValue` on `TextFieldTester` and `TextAreaTester` now throws `IllegalArgumentException` instead of committing the value when: > > - the value is longer than `maxLength` (the browser truncates the extra characters), or > - the value contains a character that `allowedCharPattern` does not match (the browser filters out that keystroke). > > This affects only tests that set such impossible values. Those tests used to pass with the value committed and the field left invalid; they now fail with an explanatory message. Note that a `maxLength` of `0` is treated as a real limit of zero, not as "no limit". > > `TextAreaTester.setValue(null)` now fails with the same clear "Field doesn't allow null values" message that `TextFieldTester` already gave, instead of an opaque reflection wrapper around Flow's `NullPointerException`. Use `clear()` to empty a field. > > Validation-only constraints are unchanged: `minLength`, `pattern` and required still commit the value and leave the field invalid, because that is what the browser does and what a validation test needs. > > Internally, the shared checks moved into a new package-private `TextInputConstraints` class, so both testers use one copy. There are no public or protected API signature changes. Conventions and tester guidelines are updated to describe where the line falls. > > Fixes #248 > > ## Test summary > > - Values longer than `maxLength` and values containing characters blocked by `allowedCharPattern` are refused, and the field keeps its previous value. > - Values at the `maxLength` limit, and allowed characters, are still accepted. > - A `maxLength` of zero blocks any text, while emptying the field stays possible under any limit. > - An `allowedCharPattern` that is not a valid regular expression restricts nothing, matching the browser, which only logs a warning. > - Validation-only constraints (`pattern`, `minLength`, required) still commit the value and leave the field invalid. > - `setValue(null)` on a text area is refused. Co-authored-by: totally-not-ai[bot] <290682512+totally-not-ai[bot]@users.noreply.github.com>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary
TextFieldTester.setValueandTextAreaTester.setValueused to accept values a real user could never type, such as text longer thanmaxLengthor characters thatallowedCharPatternblocks. They now refuse those values with anIllegalArgumentException, so a test cannot reach a state the browser would never produce.Fixes #248
What changed
Breaking:
setValueonTextFieldTesterandTextAreaTesternow throwsIllegalArgumentExceptioninstead of committing the value when:maxLength(the browser truncates the extra characters), orallowedCharPatterndoes not match (the browser filters out that keystroke).This affects only tests that set such impossible values. Those tests used to pass with the value committed and the field left invalid; they now fail with an explanatory message. Note that a
maxLengthof0is treated as a real limit of zero, not as "no limit".TextAreaTester.setValue(null)now fails with the same clear "Field doesn't allow null values" message thatTextFieldTesteralready gave, instead of an opaque reflection wrapper around Flow'sNullPointerException. Useclear()to empty a field.Validation-only constraints are unchanged:
minLength,patternand required still commit the value and leave the field invalid, because that is what the browser does and what a validation test needs.Internally, the shared checks moved into a new package-private
TextInputConstraintsclass, so both testers use one copy. There are no public or protected API signature changes. Conventions and tester guidelines are updated to describe where the line falls.Fixes #248
Test summary
maxLengthand values containing characters blocked byallowedCharPatternare refused, and the field keeps its previous value.maxLengthlimit, and allowed characters, are still accepted.maxLengthof zero blocks any text, while emptying the field stays possible under any limit.allowedCharPatternthat is not a valid regular expression restricts nothing, matching the browser, which only logs a warning.pattern,minLength, required) still commit the value and leave the field invalid.setValue(null)on a text area is refused.