This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22467 - <select> should have “oninput”
Summary: <select> should have “oninput”
Status: RESOLVED WORKSFORME
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard: whatwg-resolved
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-25 21:31 UTC by Felipe
Modified: 2016-04-25 22:49 UTC (History)
8 users (show)

See Also:


Attachments

Description Felipe 2013-06-25 21:31:44 UTC
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>
Comment 1 Mallory 2013-06-26 19:43:31 UTC
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 :)
Comment 2 Mallory 2013-06-26 19:47:27 UTC
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.
Comment 3 Felipe 2013-06-26 19:49:09 UTC
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.
Comment 4 Felipe 2014-03-18 14:03:33 UTC
WebKit appears to be moving on this, FYI:

https://bugs.webkit.org/show_bug.cgi?id=117526
Comment 5 Chris Rebert 2015-09-21 21:37:00 UTC
<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
Comment 6 Chris Rebert 2015-09-21 21:39:47 UTC
MS Edge bug: https://connect.microsoft.com/IE/feedback/details/1816207
Comment 7 Travis Leithead [MSFT] 2016-04-25 22:49:42 UTC
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!