Bug 22135
Summary: | oninput doesn't work on divs | ||
---|---|---|---|
Product: | WebKit | Reporter: | Ojan Vafai <ojan> |
Component: | DOM | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | Normal | CC: | ap, arv, ian, shadow2531 |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | PC | ||
OS: | OS X 10.5 |
Ojan Vafai
The following HTML works in FF3 but not in webkit (as in, it alerts when you type in the input.
<div oninput=alert(1)><input></div>
On the otherhand, listening to input events on the div via addEventListener does work.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Alexey Proskuryakov
Confirmed with r38232.
Eric Seidel (no email)
According to HTML5, all of these on* are defined for all HTML elements:
http://www.whatwg.org/specs/web-apps/current-work/#event-handler-attributes
However, HTML5 does not mention "oninput" in its list. We could pick on hixie to add it (or better yet, ask on the whatwg list).
Eric Seidel (no email)
To quote HTML5: "The following are the event handler attributes that must be supported by all HTML elements, as both content attributes and DOM attributes, and on Window objects, as DOM attributes:"
and then proceeds to list a bunch (not including oninput).
Michael A. Puls II
For the input element, there's a table showing for what @type of input element fires 'input': <http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#the-input-element> (scroll down a bit to see the table)
input event:
<http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#event-input-input>
Under the textarea section, look for "fire a simple event called input"
<http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#the-textarea-element>
With that said, @oninput doesn't seem to be in the spec anywhere *yet*. But, I was under the assumption that 'input' should only work for text fields (and maybe other elements in contentEditable mode).
I had no idea that
<div oninput="alert(event.target)"><input></div>
and
<div><input oninput="alert(event.target)"></div>
did the exact same thing.
That's weird. But, it seems to work in Opera too.
It seems like this would complicate things though as doing:
<div oninput="alert(event.target)"><input><input><input><textarea></textarea></div>
would work like setting an 'input' capture listener.
Michael A. Puls II
(In reply to comment #3)
> To quote HTML5: "The following are the event handler attributes that must be
> supported by all HTML elements, as both content attributes and DOM attributes,
> and on Window objects, as DOM attributes:"
> and then proceeds to list a bunch (not including oninput).
>
Sorry, I guess it's just like you said. Works for the 'change' event too. You can do window.oniput = func, document.oninput = func and element.oninput = func (or use the addEventListener way or oninput= if the object is an element) and they'll be triggered by all descendants of that object that happen to fire 'input' (like input elements and textareas etc).
Only thing is, window.addEventListener('input' function(e){alert(e.currentTarget);}, false); will alert a window object in Firefox and a document object in Safari and Opera. That's for another bug though.
Erik Arvidsson
I fixed this with http://trac.webkit.org/changeset/44811
Michael A. Puls II
Yep. Works fine now in WebKit-r44837.
Alexey Proskuryakov
Marking as fixed per the above.
Ian 'Hixie' Hickson
oninput="" shouldn't work in the example given above, because the 'input' event doesn't bubble per spec.
Should I change the spec to make 'input' bubble? I'm pretty sure 'change' doesn't bubble either, though.
Ojan Vafai
This bug was really about supporting it via addEventListener, but not via oninput.
Filed Bug 27176 about bubbling oninput.