.type dont work with datetime-local inputs

[cloud-walker]

• @testing-library/user-event version: 13.1.9

• Testing Framework and version: jest 27.0.5
• DOM Environment: jsdom (default jest version)

Relevant code or config

import '@testing-library/jest-dom/extend-expect'
import {render, screen} from '@testing-library/react'
import userEvent from '@testing-library/user-event'
import React from 'react'

const Input = () => {
  return <input type="datetime-local" data-testid="input" />
}

test('works properly', () => {
  render(<Input />)

  const value = '2000-01-01T00:00'
  const elInput = screen.getByTestId('input')

  expect(elInput).toBeVisible()
  expect(elInput).toBeEnabled()
  expect(elInput).toHaveValue('')

  userEvent.type(elInput, value)

  expect(elInput).toHaveValue(value)
})

What you did: tried to type a date to the datetime input

What happened: no date has been entered on the input

Reproduction repository: https://codesandbox.io/s/gifted-kapitsa-dfhst?file=/main.test.js

Problem description:

Suggested solution: I've seen previous similar issues (for date or time inputs), and I think it's just a matter to include a branch logic for datetime-local inputs.

[ph-fritsche]

This is what typing 2000-01-01T00:00 on <input type='datetime-local'/> produces for me in Chrome:

The element's value property is "".

[cloud-walker]

hi @ph-fritsche I dont undestand, what is the solution then? How should I test a datetime-local input?

[ph-fritsche]

datetime-local is very hard to test without a browser since its behavior depends on the browser implementation and the locale.
See the MDN example.
Chrome:

Firefox:

The control's UI varies in general from browser to browser; at the moment support is patchy, with Chrome/Opera/Edge and Safari 14.1 on desktop and most modern versions of mobile browsers having usable implementations. In other browsers, these degrade gracefully to simple controls.

Because of the limited browser support for datetime-local, and the variations in how the inputs work, it may currently still be best to use a framework or library to present these, or to use a custom input of your own. Another option is to use separate date and time inputs, each of which is more widely supported than datetime-local.

If you care about a consistent user experience you should not use datetime-local at all.
When working with React there are a couple of good solutions out there.

If you ditch users of Firefox (See this 8 year old issue) and some minor browsers, you can use datetime-local.
At the moment the way to go is to exclude the browser dependent part and trigger the input event with the desired value.

fireEvent.input(el, {target: {value}})

[Fox32]

Looks like Firefox has support nowadays (https://bugzilla.mozilla.org/show_bug.cgi?id=1283388) and behaves similar to Chrome. Can we have another look at this issue?

[ph-fritsche]

@Fox32 With consistent behavior across browsers we might consider an implementation.
An issue collecting information on the browser behavior and discussing possible implementations would be welcome.
The UI representation as used by the browser is not programmatically available. So an implementation would need to fill the gap between the (perceived) user interaction and the IDL properties.