Closed Bug 1203844 Opened 9 years ago Closed 8 years ago

ValidityState.tooLong isn't true after user deletes some chars but not enough to comply with maxlength


(Core :: DOM: Core & HTML, defect)

42 Branch
Not set



Tracking Status
firefox51 --- fixed


(Reporter: mozilla, Unassigned)




(Keywords: html5, testcase, Whiteboard: [parity-chrome][parity-safari][parity-webkit][parity-blink])

Relevant portion of the HTML spec:

If I have a text <input> whose initial value exceeds the <input>'s maxlength, and the user then deletes one or more characters from the <input>'s value, but not enough characters to bring it into compliance with the maxlength, then I believe the spec requires HTMLInputElement.validity.tooLong (aka ValidityState.tooLong) to be `true` in this case. Firefox currently gives `false` in this case.

Source code:,js,output

Quoting from the spec (numbering added by me):
> Constraint validation: If an element
> (1) has a maximum allowed value length,
> (2) its dirty value flag is true,
> (3) its value was last changed by a user edit (as opposed to a change made by a script),
> and (4) the code-unit length of the element's value is greater than the element's maximum allowed value length,
> then the element is suffering from being too long.

("suffering from being too long" = "ValidityState.tooLong is true"; see )

(1) is true since the <input> has a `maxlength` attribute with a valid value (namely: "5").
(2) is true since the user has edited the value of the <input> by deleting a character from it (see ).
(3) is true for the same reason as (2) and since there's no JavaScript on the page that messes with the <input>'s value.
(4) is true since the new value ("123456789") has a length of 9, and 9 > 5.
And since all 4 conditions are true, their conjunction is thus also true.
Component: Untriaged → DOM
Product: Firefox → Core
Blocks: 344614
We basically don't implement the "tooLong" validity state thing at all.  There's a TODO comment in the code pointing to bug 613016 and bug 613019.

The latter seems like a prerequisite for the behavior this bug is asking for.
Depends on: 613019
(In reply to Boris Zbarsky [:bz] from comment #1)
> We basically don't implement the "tooLong" validity state thing at all. 

Well, you do implement it insofar as the property exists (with a constant value of `false`) rather than being `undefined`, which makes trying to feature-detect proper support for `.tooLong` more trouble than it's worth.

> The latter [bug 613019] seems like a prerequisite for the behavior this bug is asking for.

Ever confirmed: true
Keywords: html5
Whiteboard: [parity-chrome][parity-safari][parity-webkit][parity-blink]
This bug should be fixed now that bug 613019 just landed.
Indeed. Test passes in current Nightly.
Closed: 8 years ago
Resolution: --- → FIXED
See Also: → 613019
Do we have tests for this?
Flags: needinfo?(wisniewskit)
Yes, a test for this was added as part of bug 613019. See
Flags: needinfo?(wisniewskit)
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.