22467 2013-06-25 21:31:44 +0000 <select> should have “oninput” 2016-04-25 22:49:42 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified PC All RESOLVED WORKSFORME https://bugzilla.mozilla.org/show_bug.cgi?id=1024350 whatwg-resolved P2 normal --- 1 felipe dave.null d mike mounir public-html-admin public-html-wg-issue-tracking stommepoes travil w3bugs public-html-bugzilla oldest_to_newest 89854 0 felipe 2013-06-25 21:31:44 +0000 It’s hugely unintuitive that <select> inputs don’t fire an “oninput” event. Anything that can affect the form’s submitted data should be firing “oninput” to simplify form validation etc. Test case: <!DOCTYPE html> <html> <head> <meta charset="utf-8"> </head> <body> <form action="javascript:void(0)" oninput="console.log(this)"> <label>Changing this doesn’t fire “oninput”: <select name="foo"><option>1</option><option>2</option></select> </label> <br> <br> <label>… but changing this does: <input type="text" name="bar"> </label> </form> </body> </html> 89920 1 stommepoes 2013-06-26 19:43:31 +0000 I don't understand how a select could fire an oninput event. This event doesn't fire upon a change. It fires when a visible/typeable character appears in the element from the input text but you don't input it. I'd rather the webkit version was fixed to match the others regarding textareas though. And I'd like IE to accept removing text as counting :) 89921 2 stommepoes 2013-06-26 19:47:27 +0000 Le sigh, looks like my trackpad grabbed a chunk of my text and overwrote it? It fires when a visible/typeable character appears in the element from the input device (keyboard), but this isn't what happens with a select input. No text is inputted. 89922 3 felipe 2013-06-26 19:49:09 +0000 Where are you reading anything about “visible/typeable character” … ? http://www.whatwg.org/specs/web-forms/current-work/#the-change “This event must be fired on a control whenever the value of the control changes due to input from the user …” Per the above, changing the value of a <select> makes perfect sense to fire “oninput”. IE 10 has fixed the “oninput” implementation, which was horribly broken in IE 9. 102560 4 felipe 2014-03-18 14:03:33 +0000 WebKit appears to be moving on this, FYI: https://bugs.webkit.org/show_bug.cgi?id=117526 123264 5 w3bugs 2015-09-21 21:37:00 +0000 <select>s do fire "input" events per the current spec, and Chrome & Safari implement this. Firefox and Edge don't yet implement this. "When the user agent is to send <select> update notifications, queue a task to first fire a simple event that bubbles named `input` at the <select> element, [...]" -- https://html.spec.whatwg.org/multipage/forms.html#send-select-update-notifications 123265 6 w3bugs 2015-09-21 21:39:47 +0000 MS Edge bug: https://connect.microsoft.com/IE/feedback/details/1816207 126136 7 travil 2016-04-25 22:49:42 +0000 HTML5.1 Bugzilla Bug Triage: Works for me! (Edge issue now tracked at: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/4660045/ seems like it's assigned to me...) If this resolution is not satisfactory, please copy the relevant bug details/proposal into a new issue at the W3C HTML5 Issue tracker: https://github.com/w3c/html/issues/new where it will be re-triaged. Thanks!