Bug 15189 – REGRESSION (Safari 2->3?): should support oninput event

• Status: RESOLVED
• Resolution: FIXED
• Component: Forms

[Michael A. Puls II]

Every element that supports onchange should support the input event.

The input event should be fired whenever the value of the control is *changed* to a *different* value by *any* *user-initiated* action.

User-initiated actions would be for example: cut, paste, delete, clear, undo, redo, drag-n-drop (as-in anything you can drag and drop into a textarea) or any other user action that changes the value with the keyboard or mouse or whatever input device the user is using.

You should be able to use the input event with element.addEventListener("input", function, false), element.oninput = function and the oninput attribute.

See "4.2. The change and input events" at < http://www.whatwg.org/specs/web-forms/current-work/#the-click > for more info.

Opera and Firefox have partially supported it for a while and IE supports onpropertychange (which works kind of like input). This means that other browsers have a way to use one event to listen for all user-initiated changes.

Notes:

[Firefox bugs]
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=oninput

[Opera 9.5a bugs]
Fires the event twice for each change. Firefox doesn't. This has been filed for Opera.

Fires the event even when the value doesn't change (like hitting the del key in an empty textarea). This has been filed also.

Dragging and dropping doesn't work for all things yet and sometimes you have to click outside the textarea (like onchange) to get the event to fire. Also filed.

Even with those quirks, having oninput is essential and very useful today (at least with textareas) and will be in HTML5 once the form stuff is merged in.

Hixie's live DOM viewer makes use of it for a textarea. < http://software.hixie.ch/utilities/js/live-dom-viewer/ >.

My JS URI creator makes use of it for a textarea. < http://shadow2531.com/js/jsuri.html >. I make a crappy workaround for Safari by turning on paste, change, keydown, keyup, keypress and textInput events, but it's not the same. See < http://shadow2531.com/js/jsuri.js >.

Although oninput should work for any control that supports onchange, textareas are the most important here so authors don't have to use workarounds for webkit.

You can test some very basic demos at < http://shadow2531.com/opera/testcases/oninput/ > in Firefox and Opera.

[David Kilzer (:ddkilzer)]

Confirmed with a local debug build of WebKit r25505 with Safari 3 Public Beta v. 3.0.3 (522.12.1) on Mac OS X 10.4.10 (8R218).

[Michael A. Puls II]

aside/fyi:

addEventListener("DOMControlValueChanged" will catch not only user-initiated changes, but all changes including changes a script makes. See < http://www.whatwg.org/specs/web-forms/current-work/#the-domcontrolvaluechanged >. Opera is the only one that supports this so far though.

Since oninput is kind of like a user-initiated-filtered version of DOMControlValueChanged, it *might* make sense to add DOMControlValueChanged and oninput support at the same time.

[Dave Hyatt]

We used to support oninput.  If that no longer works it would be a regression (perhaps it broke going from Safari 2 to 3 when we rewrote the form controls).

[Erik Arvidsson]

It works fine on input[type=text] but it never worked on textarea as far as I know.

[Erik Arvidsson]

Created attachment 19099 [details]
Test case

[Adele Peterson]

If my Safari 2.0.4 version isn't totally horked, I don't see the input event working for text fields or textareas in that version.

[Adele Peterson]

Created attachment 19101 [details]
tentative patch

needs more testing, but here's a tentative patch

[Michael A. Puls II]

(In reply to comment #7)
> Created an attachment (id=19101) [edit]
> tentative patch
> 
> needs more testing, but here's a tentative patch

That works and makes the input event fire on textareas. However,

1. It doesn't work if you use the oninput attribute on the textarea. (only .oninput and addEventListener("input", func, false) work. oninput="" works for the input element though.)

2. Hitting Del in an empty textarea still fires the event. It should not because the value didn't change. (This is a problem for input elements also.)

3. It doesn't fix the input event firing for the select element and possibly other controls.

[Michael A. Puls II]

(In reply to comment #8)
> (In reply to comment #7)
> > Created an attachment (id=19101) [edit]
> > tentative patch
> > 
> > needs more testing, but here's a tentative patch
> 
> That works and makes the input event fire on textareas. However,

Actually, if the patch is O.K., I think it'd be good to put it in now so at least oninput works on textareas via addEventListener. (The part about firing when pressing del in an empty textarea is a minor issue.)

[Michael A. Puls II]

(In reply to comment #8)
> 3. It doesn't fix the input event firing for the select element and possibly
> other controls.

Since part of WebForms was merged into HTML5 and HTML5 defines the event only for text field controls, no need to worry about this part.

[Erik Arvidsson]

I got a fix for this that does oninput attribute as well. Patch coming...

[Erik Arvidsson]

Created attachment 31192 [details]
incomplete patch

 4 files changed, 30 insertions(+), 0 deletions(-)

[Erik Arvidsson]

Comment on attachment 31192 [details]
incomplete patch

I'll retry this with the SVN version for now

[Erik Arvidsson]

Created attachment 31249 [details]
Adds support for oninput attribute as well as dispatching of the event.

[Adam Barth]

Comment on attachment 31249 [details]
Adds support for oninput attribute as well as dispatching of the event.

LGTM

[Alexey Proskuryakov]

Comment on attachment 31249 [details]
Adds support for oninput attribute as well as dispatching of the event.

I don't think that it's appropriate to land this without better test coverage. The discussion above suggests many tests that we could add:
- test other input types (e.g. single line inputs, radio buttons);
- test the event's behavior with SELECT elements;
- test that programmatic manipulation doesn't fire the event;
- test that keypresses that don't change the value (such as hitting the "delete" key in an empty text field, or replacing some text in the field with text from the clipboard that happens to be exactly the same text) don't fire the event;
- test that the event is not dispatched too often, as in Opera.

Furthermore, HTML5 says that the event should be dispatched asynchronously, not synchronously - and it even says that multiple events should be coalesced.

[Michael A. Puls II]

About the "no change happened" scenario, pressing del or backspace in an empty textarea shouldn't fire the event. Firefox and Opera honor this on pressing del.

However, Opera doesn't follow this for backspace yet (I assume they will) and Firefox has problems following this for backspace. For example, if a textarea is blank on load, pressing backspace in it won't fire 'input' in Firefox. However, after inserting a character and then clearing the textarea by deleting the last character in it, pressing backspace in the then empty textarea will fire 'input' in Firefox. You have to (ctrl +a) and delete in Firefox to totally clear the textarea (there's a hidden character or something internally). Then backspace won't fire 'input' in the empty textarea again. I don't think FF's quirk should be followed.

As for selecting all text in the textarea and replacing it with the same exact value, that fires 'input' in both Firefox and Opera. I assume this is because the value is technically cleared (behind the scenes) before pasting, so there is indeed a change *technically*. However, it seems like it really shouldn't fire, but that's just my opinion and it might be safer to just do as FF and Opera.

As for <select> elements, Opera basically fires 'input' for any form element that can fire 'change'. However, that's from Web Forms 2 and HTML5 currently is only covering textareas and certain types of input elements. The HTML5 spec has a list of what types of input elements fire 'input'. 

It looks like HTML5 says that only the following input element types should fire 'input':

type="text", type="url", type="search", type="tel", type="email", type="password", type="datetime", type="date", type="month", type="week", type="time", type="datetime-local", type="number", type="range", type="color", type="checkbox", type="radio"

, which, according to the table at <http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#the-input-element>  (scroll down a little to see the @type/event table), is the same for the 'change' event except 'change' also fires for type="file" while 'input' should not.

As for firing 'input' on contentEditable stuff, I don't think HTML5 has mentioned anything on that yet. But, it seems like it should the same way it would for a textarea. It would seem useful anyway.

As for firing twice like Opera does. That's just a bug. The extra 'input' event gets triggered by Opera's 'change' event processing somehow. I don't think this will be a problem with Webkit's code. But, I guess it's best to test. Opera should fix this eventually.

As for coalescing, I don't know if Firefox or Opera do this and I don't know of the exact rules that should be followed for doing this. I think it's up to the implementation. For example, while changes are happening in less than N milliseconds of each other, don't fire the event until changes are farther then N apart. I just don't know if you'd be able to type fast enough or trigger a change in one of the other controls fast enough to trigger coalescing unless N is really high. And, I don't think not doing coalescing will affect performance, but it might in some cases.

Also, HTML5 still has yet to totally clear up what 'change' means, but it should mean "to a *different* value" by any user-initiated action like drag-n-drop, undo, redo, cut and paste, clear, delete, moving selected text around in the textarea etc.

Best to read through <http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#the-input-element> and <http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#the-textarea-element> though.

With all that said though, just turning on 'input' firing for textarea would be good enough for me right now, personally, and then bugs could be filed for the other stuff. But, that's up to you if you want to wait till it's 100% perfect.

Hope that helps.

[Erik Arvidsson]

Let me give you some background to this.

This is the code that Gmail and almost all other Google Apps use.

http://code.google.com/p/doctype/source/browse/trunk/goog/events/inputhandler.js

It uses the input event for all non IE browsers except in the case of WebKit and textareas where it only uses keypress. This behavior is far from correct but it is better than nothing and it was decided by the Google Apps teams that it was not worth the extra cost of polling to cover all bases for WebKit since it is clearly a bug in WebKit anyway.

Back to this bug. I think it makes sense to fix textarea to at least get basic support. Just because it is not 100% correct it does not make sense to prevent it from being fixed. Should we remove input events from input[type='text'] since it does not correctly handle delete? I don't think anyone is suggesting that?

I agree that I can do more in this patch and I suggest the following things to be done in here and then we can open new bugs for the remaining issues.

1. Make oninput a global attribute: http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#global-attributes
2. Make sure that the input event is fired by textareas
3. Improve the tests to
3.1 Cover the non focused case
3.2 Make sure the event bubbles and can be caught by a <div oninput="...">
3.3 Make sure that programmatic changes do not fire the event.

Then we should file these new bugs:

1. Make sure that subtreeModified is not called when the subtree is not really modified. This should catch issues with delete and backspace as well as pasting the same content etc.
2. Dispatch oninput for the following input elements:

type="text", type="url", type="search", type="tel", type="email",
type="password", type="datetime", type="date", type="month", type="week",
type="time", type="datetime-local", type="number", type="range", type="color",
type="checkbox", type="radio"

3. Implement oninput for contentEditable.


Does that sound reasonable?

[Michael A. Puls II]

(In reply to comment #18)
> I think it makes sense to fix textarea to at least get basic
> support.

FWIW, I 100% agree. Just making it fire for textareas would be a huge help. All the fine details and technicalities are not even interoperable between FF and Opera yet, so, it seems there'd be no harm in just making it fire (which is all you can really count on in other browsers atm anyway)

For <http://shadow2531.com/js/jsuri.html>, all I need is for 'input' to fire on the textarea. It is not dependent on whether the other stuff is implemented correctly or not. I believe Hixie's live DOM viewer could benefit in the same way.

I want things to be perfect, but 'input' has been broken for so long on textareas in Webkit that just getting it working seems like an important step.

Alexey, what do you think? Think the other things could be handled separately?

[Erik Arvidsson]

Created attachment 31296 [details]
Makes oninput attribute work on all elements and epands the layout test.

[Alexey Proskuryakov]

(In reply to comment #18)
> Does that sound reasonable?

Yes, this plan sounds good to me.

[Erik Arvidsson]

Alexey, is this patch enough or is there anything else you want me to do in this iteration?

[Alexey Proskuryakov]

My concerns are fully resolved - just waiting for Adam (as the original reviewer) or someone else familiar with forms code to mark r+.

[Adam Barth]

(In reply to comment #23)
> My concerns are fully resolved - just waiting for Adam (as the original
> reviewer) or someone else familiar with forms code to mark r+.

I'd prefer that someone else review this patch.  (Once burned, twice careful?)

[Adele Peterson]

Comment on attachment 31296 [details]
Makes oninput attribute work on all elements and epands the layout test.

typo in one of the tests: programmitcally

[Erik Arvidsson]

Created attachment 31324 [details]
Fixes typos.

[Eric Seidel (no email)]

Sigh.  My script (bug 26283) can't land this because it would land the wrong patch.  Or, if I marked the last patch r+, then the script would land the patch as though I was the reviewer. :(

[Erik Arvidsson]

I obsoleted the old patch and marked the new patch as r? Hopefully Adele can r+ it again.

[Ojan Vafai]

http://trac.webkit.org/changeset/44811

[Michael A. Puls II]

Woo hoo! It's working on textareas in WebKit-r44837. Thank you. Thank you!

[Alexey Proskuryakov]

(In reply to comment #18)
> Then we should file these new bugs:

Could you please post bug numbers here for reference, once you file them?

[Michael A. Puls II]

Here are the ones I know of fwiw:

Bug 26519: oninput fires too often

Bug 26526: Add support for input events (oninput) to contentEditable elements

Bug 26550: Implement input events for checkboxes and radio buttons

Bug 26576: oninput event doesn't fire on first drag from address field

Bug 22135: oninput doesn't work on divs (fixed)

Bug 26578: event.currentTarget for listener registered on window should point to the window object like in Firefox (affects window.oninput)