Add support for <select oninput>




Layout: Form Controls
12 years ago
4 months ago


(Reporter: Jesse Ruderman, Unassigned)


(Blocks: 1 bug)

Bug Flags:
wanted-next +
blocking1.9 -
wanted1.9 -

Firefox Tracking Flags

(Not tracked)




12 years ago
Add support for <select oninput> so dynamic forms can update immediately in
response to keyboard selection.

Previous discussion: around bug 126379 comment 57.


11 years ago
Blocks: 126379

Comment 1

11 years ago
Nominating because the lack of <select oninput> makes it hard to update other parts of the page immediately when a user selects an option with the keyboard.
Flags: blocking1.9a2?
Flags: blocking1.9a2? → blocking1.9-
Whiteboard: [wanted-1.9]
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Flags: wanted1.9-
Flags: wanted1.9+
Flags: wanted-next+

Comment 2

4 years ago
Here is a test case:

<!DOCTYPE html>
<meta charset="utf-8">
    <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>… but changing this does:
            <input type="text" name="bar">

Comment 3

4 years ago
This really is a bug, not an “enhancement”. There is nothing in the HTML 5 or DOM spec, AFAICT, that exempts <select> from firing oninput.

Note, too, that <form oninput> should fire when an associated <select oninput> does. doesn't specify any firing of the 'input' event in relation to the <select> element. I don't mind adding it if we want to implement that, though. If so, please file a bug at or send feedback to

Comment 5

4 years ago
Absence of oninput for <select> seems like a huge lacuna in the spec … it seems intuitive that a <form>’s “oninput” would fire whenever anything in the form is updated.

I went ahead and created:

Incidentally, it’s really confusing trying to figure out which document is authoritative about HTML 5. I’d love some reference for every event that an element can fire, every attribute that it can have, etc. FWIW.

(Every element can fire every event, if you call dispatchEvent() on it. :-) The HTML spec has some "Event summaries" in various places that try to make this clearer though. A broader one could make sense. If you want that, please file a bug on it at .)

(The W3C and the WHATWG disagree about which document is authoritative on HTML right now. The W3C stopped work on HTML in 2001 or so, in 2004 the WHATWG resumed the work, in 2007 the W3C and WHATWG worked together, then they slowly diverged and in 2012 the W3C formally forked the WHATWG work. Not they copy most of what the WHATWG does but change bits of it. Mail me if you'd like more details on this; it's off-topic for this bug.)

Comment 7

3 years ago
Incidentally, the WebKit folks appear to be moving on this:

Comment 8

a year ago
For Web developers:
Since oninput support in browsers was largely incomplete 5 years ago, jQuery ticket #9121 was filed:
Unfortunately, that ticket was marked as "wontfix", and since this very issue persists, developers still cannot blindly trust oninput to work on bleeding edge browsers, with or without jQuery.

I have linked this ticket from
You need to log in before you can comment on or make changes to this bug.