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

Categories

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

42 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
firefox51 --- fixed

People

(Reporter: mozilla, Unassigned)

References

()

Details

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

Relevant portion of the HTML spec:
https://html.spec.whatwg.org/multipage/forms.html#attr-fe-maxlength

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.

Testcase: http://output.jsbin.com/xutife/1
Source code: http://jsbin.com/xutife/1/edit?html,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 https://html.spec.whatwg.org/multipage/forms.html#dom-validitystate-toolong )

(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 https://html.spec.whatwg.org/multipage/forms.html#concept-input-value-dirty-flag ).
(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.

Agreed.
Status: UNCONFIRMED → NEW
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.
Status: NEW → RESOLVED
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 https://hg.mozilla.org/mozilla-central/file/e2bb8f329f10/dom/html/test/test_bug613019.html
Flags: needinfo?(wisniewskit)
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.