"Change" event fires unexpectedly when edit an input value with type="date"
Reported by
levdmit...@gmail.com,
Feb 21 2018
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Safari/537.36 Steps to reproduce the problem: 1. Run the example http://plnkr.co/edit/KpGnMgGtNFZKQoISEnnF?p=preview OR create an html-file with following markup <input type="date" onchange="changeHandler()"> <script> function changeHandler() { alert("The input value has changed"); } </script> 2. Enter a day and month value parts and start typing a year part What is the expected behavior? "Change" event must be fired when the "enter" key pressed or on focus out from the input What went wrong? "Change" event fires on every keypress Did this work before? N/A Chrome version: 64.0.3282.167 Channel: stable OS Version: 10.0 Flash Version: FireFox 58 works like expected
,
Feb 21 2018
,
Feb 22 2018
The current behavior is by design, and conforms to the HTML specification. However, this is an interoperability issue.
,
Mar 13 2018
Please could you provide a reference for the specification which this conforms to By my reading it seems to be nonconformant with DOM L2 Events: https://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-htmlevents
,
Mar 13 2018
> Please could you provide a reference for the specification which this conforms to https://html.spec.whatwg.org/multipage/input.html#common-input-element-events > The change event fires when the value is committed, if that makes sense for the control, or else when the control loses focus. "Commit" is up to browser implementations. > By my reading it seems to be nonconformant with DOM L2 Events: Please do not refer W3C DOM specifications. They are obsolete.
,
Mar 14 2018
It doesn't seem to be obsolete: https://www.w3.org/standards/techs/dom#w3c_all If Chrome no longer refers to those specs then that's a bit different - is that what you meant? It seems disingenuous to imply that this isn't a correctness issue on the basis that the WHATWG spec leaves the definition of "commit" up to the implementor. There is clearly a utility issue here and arguably also a correctness issue. 1. The behavior is inconsistent within Chrome itself. Chrome doesn't fire change on every keypress in a text input yet it does on a date input. 2. It also makes the change event not very useful; it's essentially the same as the input event. Chrome's current implementation "by design" appears to confuse the change event with the input event. 3. As you pointed out, it is also an interop issue. |
|||
►
Sign in to add a comment |
|||
Comment 1 by dtapu...@chromium.org
, Feb 21 2018