http://www.w3.org/TR/html5/index.html#events-0 Per the above, changes to a <select> element should be firing “oninput”; however, WebKit seems simply to ignore these changes. No other browser appears to implement this as I’m describing, but per the spec, this still appears to be a bug that DEFINITELY should be fixed. I can’t check this on a WebKit nightly because I have Snow Leopard.
Could you please attach 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>
I also was able to confirm the bug in the latest nightly.
Created attachment 227032 [details] Patch Add a call to dispatch input event when listbox or menulist values are modified. These changes have been already applied for the same bug on Blink here http://crbug.com/349472
Comment on attachment 227032 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=227032&action=review My informal review. > LayoutTests/ChangeLog:3 > + "oninput" doesnât fire when changing a select elementâs value Encoding problem? > Source/WebCore/ChangeLog:3 > + "oninput" doesnât fire when changing a select elementâs value Ditto.
Created attachment 227038 [details] Patch Fixed encoding issue.
Comment on attachment 227038 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=227038&action=review Reading the spec it sounds like the intention is that input event only fires for <input> elements. "When the input and change events apply (which is the case for all input controls other than buttons and those with the type attribute in the Hidden state), the events are fired to indicate that the user has interacted with the control. The input event fires whenever the user has modified the data of the control. The change event fires when the value is committed, if that makes sense for the control, or else when the control loses focus. In all cases, the input event comes before the corresponding change event (if any)." > Source/WebCore/html/HTMLSelectElement.cpp:700 > + RefPtr<HTMLSelectElement> protector(this); This seems like a separate bug fix. Could you make a test case for it and land separately?
No I'm wrong. There is specific text for firing these: "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, and then fire a simple event that bubbles named change at the select element, using the user interaction task source as the task source." http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-select-element
Comment on attachment 227038 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=227038&action=review Ok. > LayoutTests/ChangeLog:3 > + "oninput" doesn't fire when changing a select element's value The event is called "input" no "oninput"
Please also point to the spec test in the ChangeLog
*text
Created attachment 227283 [details] "input" event is not fired when changing a select element's value Applied suggested corrections.
Comment on attachment 227283 [details] "input" event is not fired when changing a select element's value Clearing flags on attachment: 227283 Committed r165965: <http://trac.webkit.org/changeset/165965>