Event for change #52

Santas opened this Issue Apr 29, 2012 · 26 comments


None yet

Santas commented Apr 29, 2012

Is it possible to hook onto event that is fired when anything changes?

Current 'change' is fired after wysiwyg losing focus and that makes it impossible to build for example mentions upon it (like @ on FB or on GitHub).

Same here

iceton commented May 2, 2012

Why not just tie into keypress & click? I know what you're saying (I tried change the first time around too) but keeping the standard textarea event behavior makes sense to me.

heeton commented May 2, 2012

+1 Given the various buttons and manipulation people might do to the text, a global 'change' event would be nice.


tiff commented May 3, 2012

@Santas I think what you mean is an "input" event. The editor already fires a "change" event. It behaves almost the same as the native change event on form fields (it's only fired when the user blurs the input).

Santas commented May 3, 2012

Ok, I probably used the wrong name for this type of event. Is it possible to hook onto input event?

heeton commented May 3, 2012

Well, a better 'change' event would be good, that doesn't just fire on blur.
(We'd use it for autosave while someone is editing a large file)


tiff commented May 5, 2012

Having an "input" event would be a great idea! I'm considering this for v0.4.

nevf commented May 23, 2012

Having an event that fired whenever the content changed would be a most welcome addition. I'd use it for auto-save as well.

Is this getting any closer?

just encountered the same issue. put me on the waiting list.

@iceton did you successfully put the listener for keypress right on the editor instance? I can't get it to fire there.

Charuru commented Nov 15, 2012

Yes please. Any progress on keypress or similar?

cvrsor commented Dec 7, 2012

Any progress on the 'input' event?

I am now looking into wysihtml5-0.3.0.js code to see what modifications will achieve this.
ex. removing this if clause makes the newword:composer event fire on each keystroke but for some reason my event function does not run consistently on every keystroke...

I solved it by using setinterval onfocus, here's the code I used: https://gist.github.com/4239599

cvrsor commented Dec 8, 2012

Thanks @rubensayshi that did it..

mkolodny commented Jan 9, 2013

In anything but IE8 you can also use:

editor.composer.element.addEventListener('input', function() {
...(editor.getValue(), or whatever you need to do)....
}, false);

And in IE8:

editor.composer.element.attachEvent('onpropertychange', function() {
}, false);

nevf commented Jan 15, 2013

@mkolodny If I'm not mistaken this will only work when the editor host is an input element, whereas it is typically a textarea. I've tested it on my app which uses textarea's and the event is never triggered.

I've just had a quick look through the wysihtml5 code and it creates a hidden input element when the textarea is inside a form, which maybe what you are using.

I've struggled the last week to identify some of the events related to changes in the editor, for anyone who's looking, this gist may help:


luiges90 commented Feb 1, 2013


+1 This is badly needed.

shichan commented Apr 22, 2013

Waiting for this as well! 👍

bobbus commented Jul 10, 2013

Me too ! 👍


ghost commented Aug 24, 2013

I have a working 'keyup' handler integrated with angular here: http://plnkr.co/edit/gMEvvUoYkR3kSZxcZZ9M?p=preview

The relevant part is on line 61 of script.js. The way I'm attaching the handler may be brittle, since it doesn't use a documented API. But it works for now.

fenoria commented Aug 30, 2013


ajbraus commented Sep 5, 2013


mngsk commented Sep 17, 2013

I added the following to the 0.4.0pre javascript file in line 8545

// --------- input event ---------
dom.observe(element, "input", function(event) {

and then just declared it as a normal 'supported' event:

var editor = new wysihtml5.Editor("textarea-id");
// observe
function onInput() { alert("The content of the editor has changed"); };
editor.on("input", onInput);

and it seems to be working fine (at least with textarea).
Is anything wrong with that approach?

faeb187 commented Dec 6, 2013

After freestyle guessing I figured out it's 'change' not 'input'

CoffeeScript example:
editor.on "change", myFn

btw this event is fired 'onfocusout' not 'onchange' as supposed...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment