1531652 - Invalid date caused by using arrow keys on <input type="date">

Status: NEW

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

Description

[Cheng-You Bai [:cybai] UTC+9]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

1. Visit https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date
2. Use keyboard to change month of the date input to February
3. Use keyboard to change day of the date input to 31

Actual results:

I can use arrow keys (Up / Down) from keyboard to change date to invalid dates (e.g, 2/30, 2/31, 4/31 ... and so on)

Expected results:

When I use up arrow to add date from 2019/2/28, I'd expect the next date is 2019/3/1.

Comment 1

[Cheng-You Bai [:cybai] UTC+9]

I can also reproduce this on Chrome so I filed https://crbug.com/937192

Comment 2

[Paul_B]

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

Hi reporter and thank you for taking the time to report this.
I was able to reproduce this issue on all the latest Firefox version builds across platforms (Win 10, Mac OS 10.14 and Ubuntu 18.04).

I'm going to add this to Core: Layout: Form Control for an advised input. If this is not the proper component, and something like DOM: Core & HTML or any other component may be more appropriate, please feel free to change it.

Comment 3

[Cheng-You Bai [:cybai] UTC+9]

As mentioned in the spec of Bookkeeping details section, stepDown() and stepUp() methods apply to <input type=date>.

Not sure if it's possible to define the behavior of using arrow keys via these two methods in the spec? Up arrow does stepUp() and Down arrow does stepDown().

Comment 4

[Cameron McCormack (:heycam)]

I'm not sure if this is something that should be fixed. I can imagine some people who are using arrow keys to enter the date could think about setting DD to the target value first, then MM, then YYYY (assuming the date is shown in DD-MM-YYYY order). If we don't allow invalid intermediate states then it could force them to tab back and forth between the three fields in an awkward way.

Comment 5

[Sean Voisen (:svoisen)]

I'm going to move this to DOM since that team will be better suited to handle the internal workings of controls (which this is about, rather than the layout of the control).