Open Bug 312094 Opened 19 years ago Updated 2 years ago

Add support for <select oninput>

Categories

(Core :: Layout: Form Controls, enhancement)

Product:
Core
Component:
Layout: Form Controls
Type:
enhancement

Tracking

()

People

(Reporter: jruderman, Unassigned)

References

Details

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

Previous discussion: around bug 126379 comment 57.
Blocks: 126379
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+
Here is a 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>
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.

http://www.w3.org/TR/html5/index.html#events-0
http://whatwg.org/html#the-select-element 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 http://whatwg.org/newbug or send feedback to whatwg@whatwg.org.
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:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22467

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.

Thanks!
(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 http://whatwg.org/newbug .)

(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.)
Incidentally, the WebKit folks appear to be moving on this:

https://bugs.webkit.org/show_bug.cgi?id=117526
For Web developers:
Since oninput support in browsers was largely incomplete 5 years ago, jQuery ticket #9121 was filed: https://bugs.jquery.com/ticket/9121
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 https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/oninput
This bug seems to be fixed in modern browsers. (I tested Firefox, Chrome, and Safari.)
I'm not sure it is.  As far as I can tell, "input" fires at the exact same time as "change" for <select> elements...
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.