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

RESOLVED FIXED

Status

()

Core
DOM
RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: Chris Rebert, Unassigned)

Tracking

(Blocks: 1 bug, {html5, testcase})

42 Branch
html5, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox51 fixed)

Details

(Whiteboard: [parity-chrome][parity-safari][parity-webkit][parity-blink], URL)

(Reporter)

Description

2 years ago
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.
(Reporter)

Updated

2 years ago
Keywords: testcase

Updated

2 years ago
Component: Untriaged → DOM
Product: Firefox → Core
(Reporter)

Updated

2 years ago
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
(Reporter)

Comment 2

2 years ago
(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.
(Reporter)

Updated

2 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Updated

a year ago
Keywords: html5
Whiteboard: [parity-chrome][parity-safari][parity-webkit][parity-blink]

Comment 3

a year ago
This bug should be fixed now that bug 613019 just landed.
(Reporter)

Comment 4

a year ago
Indeed. Test passes in current Nightly.
Status: NEW → RESOLVED
Last Resolved: a year ago
status-firefox51: --- → fixed
Resolution: --- → FIXED
See Also: → bug 613019
Do we have tests for this?
Flags: needinfo?(wisniewskit)

Comment 6

a year ago
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)
You need to log in before you can comment on or make changes to this bug.