1912707 - datalist change event fires differently from Chrome/Edge

Status: NEW

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

Description

[Tom Doan]

Steps to reproduce:

1. Go to https://jsfiddle.net/thdoan/2rj8fvmq/ and display the jsfiddle console
2. Go into the input box and press Up/Down to select an option by pressing Enter or clicking with the mouse
3. Repeat steps 1-2 in Firefox and Chrome/Edge and observe the difference in behavior

Actual results:

In Firefox, the change doesn't fire until you click outside of the input (i.e., on blur event). In Chrome/Edge, the change event is fired as soon as you select an option.

Expected results:

I'm not sure what the spec stipulates, but the behavior in Chrome/Edge makes more sense IMHO.

Comment 1

[Tom Doan]

UPDATE: Added a dropdown menu to the jsfiddle to show that the Chrome/Edge event firing behavior is more consistent with <select> element that Firefox's implementation.

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

<datalist> definition does not mention about change event.
https://html.spec.whatwg.org/multipage/form-elements.html#the-datalist-element

So, it's not extended by the element definition. The change event behavior is defined here.

The change event fires when the value is committed, if that makes sense for the control, or else when the control loses focus

For input elements without a defined input activation behavior, but to which these events apply, any time the user causes the element's value to change without an explicit commit action, the user agent must queue an element task on the user interaction task source given the input element to fire an event named input at the input element, with the bubbles and composed attributes initialized to true. The corresponding change event, if any, will be fired when the control loses focus.

However, at last:

When the user agent is to change an input element's value on behalf of the user (e.g. as part of a form prefilling feature), the user agent must queue an element task on the user interaction task source given the input element to first update the value accordingly, then fire an event named input at the input element, with the bubbles and composed attributes initialized to true, then fire an event named change at the input element, with the bubbles attribute initialized to true.

So, dispatching change event seems reasonable if browsers set the <input>.value from <datalist>.

WDYT, smaug?

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

The spec is indeed vague here. Firing change sounds reasonable

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Thanks. Let's treat this as a valid bug.