1613280 - It's possible to type a date that exceeds the value of the max attribute (input type date min max)

Status: RESOLVED FIXED

(Core :: DOM: Forms, defect, P3)

Description

[kraig.tri125]

Attachment: firefox_yVdu9yQlEY.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

In a date input field:
1- Set the max attribute to "9999-12-31".
2- Select the year and type "1" until that part of the input is completely filled.

Actual results:

The year grows to 6 digit.

Expected results:

I expected the input to only allow 4 digits to be entered as the mask is displayed to be "yyyy-mm-dd" with 4 digits for the year.

I expected the selection to move to the month after entering 4 digits for the year.

Comment 1

[Daniel Holbert [:dholbert]]

This sounds like the same issue described in bug 1363660 comment 3 (though it probably does deserve its own bug, i.e. this bug here).

Note that the field ordering here depends on locale. For me in my en-US Firefox build, input type="date" renders with MM-DD-YYYY, by default at least (or YYYYYY if I keep typing :) ). But I can see how this would be an issue if you had YYYY as the first part of the field.

RE step 1 of the STR -- I'm actually not sure whether the "max" attribute is supposed to have any effect on what happens when you are typing inside the field -- my recollection is that the browser is only supposed to validate the input after you've left the field, and again when you submit the form. But, I can see how on-the-fly validation (and value-constraining) would be useful from a UX perspective.

Also: according to bug 1363660 comment 3, the requested behavior here apparently is what Chrome already does. So, this is a chrome-parity UX concern, even if it's not explicitly required per spec (which I don't know for sure). Hence, marking as a confirmed bug and calling this P3 (backlog).

Comment 2

[Mats Palmgren (inactive)]

(adding a few words to the subject to hopefully make it easier to find)

Comment 5

[Mats Palmgren (inactive)]

Note that we also have bug 1501987 open on a related issue - namely that the UI isn't restricted to the min/max interval.

Comment 7

[julianvolodia]

Hey, what about that? Is there any PR I could continue or review to help?

This is not actually chromiuX :) this is just the way You written it explicitly DD/MM/YYYY if I have YYYY I require to have 4 digits.
More over - date input is not for archeologic purpose and only support modern period called AD...

So, how could we fix that?
Cheers.

Comment 8

[julianvolodia]

...last but not least - consolidated bug ( https://bugzilla.mozilla.org/show_bug.cgi?id=1502390 ) is not looking for this bugfix imho but for feature (so there is feature request not a bug ) to better selector (UX?).

This is simply and actually very plain to fix year input & display. As YYYY is there only 4 digits should be allowed. We have time to latter refactor Guys....

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to julianvolodia from comment #7)

Hey, what about that? Is there any PR I could continue or review to help?

Thanks for the offer. There's no in-progress work here that could be continued, no. This needs someone to dive into the code that runs every time a character is typed into the field, and figure out how to add the logic required for this bug. That code would probably need to live in HTMLInputElement::BeforeSetAttr / HTMLInputElement::AfterSetAttr perhaps, though I'm not really sure.

https://searchfox.org/mozilla-central/rev/fa48ebee58d59fa846919c3e2c3122b08db57c9c/dom/html/HTMLInputElement.cpp#1135
https://searchfox.org/mozilla-central/rev/fa48ebee58d59fa846919c3e2c3122b08db57c9c/dom/html/HTMLInputElement.cpp#1169

Also, this actually belongs in DOM:Forms, since that component/code is responsible for managing validity/content in form fields, whereas this layout subcomponent is more about "how big is the component and where do its pieces go". --> Reclassifying.

Comment 10

[Szobonya Csaba]

Attachment: Bug 1613280 - Change mMaxYear to 9999 (ISO 8601)

Comment 11

[Tim Giles [:tgiles]]

After discussion with :emilio, :zcorpan, and :ayeddi, we've decided to only allow four digits when typing in a value for year in the datetime-local date picker. We are still able to display years greater than 9999 with the proposed changes, and one is still able to select a year greater than 9999 when using the date picker (as long as the max attribute doesn't prevent a user from selecting a year greater than 9999). The constraint validation of invalid dates and dates outside of the min and max ranges are unaffected by this change.

Additionally, Chrome and Safari both allow 6 digits to be entered in to the year part of the datetime-local input so removing the parity-chrome keyword.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/51eeece91171
Change mMaxYear to 9999 (ISO 8601) r=reusable-components-reviewers,tgiles

Comment 13

[Serban Stanca [:SerbanS]]

Backed out for causing mochitest-plain failures in test_input_date_key_events.html.

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | dom/html/test/forms/test_input_date_key_events.html | Test with 0101275769, result should be 275760-01-01 - got "0069-01-01", expected "275760-01-01"

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f14117e2fa1e
Change mMaxYear to 9999 (ISO 8601) r=reusable-components-reviewers,tgiles

Comment 15

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/f14117e2fa1e