Add support for <select oninput>

NEW
Unassigned

Status

()

Core
Layout: Form Controls
--
enhancement
12 years ago
4 months ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

(Blocks: 1 bug)

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

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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.
(Reporter)

Updated

11 years ago
Blocks: 126379
(Reporter)

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>
<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 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.

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.

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:
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.)

Comment 7

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

https://bugs.webkit.org/show_bug.cgi?id=117526

Comment 8

a year ago
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
You need to log in before you can comment on or make changes to this bug.