> Note that this is not asking for something that isn't inherently there it is there, in the form of mutation events.
and note that changing the value of a textarea does not change any attributes.
The last test case posted by Csaba works fine for me with Firefox 1.03. I recommend changing the status of this bug to "WORKSFORME".
I've just tested this out and can confirm that it is indeed bugged. Especially in a textarea, the produced values are completely upside-down, with multiple triggers for the same operation (e.g. cutting or pasting across lines). Additionally, pasting text onto an empty line in a textbox (e.g.: [text <== empty line text]) does not trigger DOMCharacterDataModified as it should. -Kalle.
Anyone care to confirm this bug, one way or the other? /be
So what is the use case and scope? Doing this in general for everything (base URIs, all tree-state-dependent properties, computed style, etc) really won't fly performance-wise...
Created attachment 204377 [details] Testing described in Comment 3 This attachment is for testing as described in Comment 3
(In reply to comment #8) > So what is the use case and scope? Doing this in general for everything (base > URIs, all tree-state-dependent properties, computed style, etc) really won't > fly performance-wise... May I suggest that we take Comment 3 as the statement of this bug report? In other words, this is a bug report about the DOMCharacterDataModified mutation event as it applies to text and textarea (and the use case for this has been made in Comment 1), and not something more general. On my FF, the same problems reported in Comment 3 are still there, and I have created an attachment to make it simple to test. The attachment has some minor modifications from the code listed in Comment 4 - namely, that the entire history of the DOMCharacterDataModified event is shown. Csaba
This bug is all over the place. It starts out as being an RFE to get watch or onpropertychange working, but then morphs into a bug about mutationevents. On top of this a lot of the claimed mutationevent bugs are in fact invalid[*]. Would anyone mind if we just closed this bug so that new, easier to follow, bugs can be filed. [*] When the text inside a <textarea> or <input type="text"> is changed the DOM is not mutated. No textnodes are ever added or removed or have their data changed, and thus no mutation events should be sent out. The only thing that changes is the .value property.
What sicking said. The fact that any mutation events fire while editing a textarea is a bug in our anonymous content and event retargeting code. There should be no such events at all during typing and copy/paste operations.
I don't mind if this is closed so a new, cleaner report can be filed. But in the interest of getting it right, what should I file it under - should I essentially refile the original report? To be specific, my immediate interest in all this is to have a way to detect when the text of a textbox or textarea changes. This is both reasonable and useful for web apps. From http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-textInput it seems I could wait around until the textInput event appears, but I'm betting that will be an awfully long time. Also, I'm somewhat confused about Sicking vs. Zbarsky's comment about DOMCharacterDataModified. If I understand it correctly, Sicking says that it should not fire at all due to changing the character data of a text element, whereas Zbarsky says it shouldn't fire upon the text being modified - presumably only after focus is lost(?). Which is more correct, and if it is the latter, what is the utility in waiting, as with onchange?
Sicking and I are saying the same thing. Typing in a textarea or pasting into it should not fire mutation events. Period. Note that there is already an oninput event (which may or may not fire on pastes; if it does not, there are existing bugs on that).
If all you're interested in is the user modifying the text then the oninput attribute should be enough for you. No need to file any bugs on that. Boris and I am saying the same thing about mutation events. The user modifying the text inside an <textarea> and <input type=text> should not cause any mutation events to fire at any time. The fact that some mutation events do fire is a bug. Feel free to file a bug on this unless one is already filed. I'm closing this bug as works-for-me since the oninput event is available.
Oh, and for checkboxes, radiobuttons, and selects you can use onchange