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.

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).

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

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

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.

...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....

(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.