Solution 1 :

You can do this workaround to fix this behaivor:

First catch de event ‘keydow’ from the input date and prevent that the default action (open the popup)
At the same moment you can throw your own event to handle it as you like.

    $(document).on('keydown', "input[type='date']", function (e) {
        if (e.which == 13) {


Problem :

The input[type=”datetime-local”] behaviour have changed between chrome 81 and 83

on chrome <= 81, the datetime-local input calendar was enabled on click, and a keyup event was fired on enter key : see behaviour on saucelabs – chrome 81

on chrome 81

on chrome 83, this behaviour have changed : the enter key triggers the opening of the calendar, and no keyup event is fired see behaviour on saucelabs – chrome 83

The following code (also on

<input id="dt" type="datetime-local"/>
document.querySelector("#dt").addEventListener("keyup", (ev) => {

shows keyup 13 events on < 81, nothing on >= 83

I use this keyup 13 event to validate/submit data, but it is no more possible; I have not found many changelog / details on this update / feature / bug but this chromium change may be the one

moreover, even without any js, this disables the to submit a form using enter within a datetime input : see

<form id="frm">
  <label>This field cannot be used to submit the form using "enter" key</label>
  <input type="datetime-local" id="dt"/>
  <label>This field can be used to submit the form using "enter" key</label>
  <input type="text" id="txt"/>

so is it possible to keep the old behaviour ? and if not, how can i now validate a datetime-local form input using keyboard…

Edit: created an issue on chromium bugs


Comment posted by Zim84

Have you tried onchange?

Comment posted by jmbarbier

onchange works but the enter key is a way for the user to indicate that the date is ok and ready for submission / save; the onchange does not provide this UX

Comment posted by Robo Robok

Why would you want to only support keyboard-driven change?

Comment posted by jmbarbier

tab / edit / enter to save field cycle on a form is fast

Comment posted by this issue

There’s definitely work been done in this area recently where discussions were going on around specific behaviours such as this – see


Leave a Reply

Your email address will not be published. Required fields are marked *