Question

I’m trying to find a way to write some unit-tests that can be used to write/test new wysiwyg html editors or just the default browser behavior for contenteditable divs.

I want to record the keypresses (perhaps other events too, but keypresses are the most interesting) or just write the events manually and then play them back later on a div. In the end I would use it to simulate little html editing sessions and see if you end up with the expected serialized html.

BUT, I can’t get the following to invoke the default browser behaviour:

$(mydiv).trigger('keydown', {type: "keydown", keyCode: 13, which: 13}); 

(It doesn’t insert a line-break or break up the paragraph or do anything, really.)

I have also tried things like:

$(mydiv).trigger('textInput', {type: "textInput", data: 'H', target: mydiv});

(Which should have inserted the letter H)

and I even tried to keep the original event objects around and then trigger them like this:

$(mydiv).trigger(eventObject);

(where eventObject is an actual key event I got previuosly and then kept around)

Part of the problem is that I don’t know what the minimum event object attributes are that I have to keep around and then send back later. (All of it isn’t an option because you can’t just dump the whole event as JSON due to all the circular references.)

Another part of the problem is I’m not even sure how to properly focus the editable

At a minimum I need to be able to create a new empty div, set contenteditable=”true” and then “insert some text”, place the cursor in the middle of it and “press enter” by reading and replaying commands from a log of editing events.

---

Here’s why I need it:

The idea is to write a lot of tiny tests that can be run in any cutting edge browser (I’m only really interested in the latest versions of Chrome, Firefox, Opera and maybe IE9) to see where they differ from what’s expected. It is for a survey of what the latest browsers do, not for what 10 year old browsers did.

I can then come up with some kind of checklist of where the browsers deviate from each other. This could then be used by anyone that wants to write a new wysiwyg editor, but ideally the “core” of it – the parts that don’t contain or care about any interface/chrome – could be written once and shared by them all.

Individual editors handle things like inserting/removing inline elements, linking text, inserting/editing images, inserting lists and tables, changing a p to an h1 and so on. I’m only really interested in the keypress-level editing here.

Some of these tests could also be used similar to the way javascript frameworks do “feature detection” to see which bits of behavior has to be intercepted/patched so that enter and backspace always behaves the same, so that the cursor is always on the correct side of a b tag and so on.

Answer 1

You won’t be able to do what you want here, I don’t think. Most browsers do not allow script to fully simulate a keypress: you can fire the event but the associated browser behaviour (updating the value of an input, editing the content of a contenteditable element, moving the caret, etc.) will not happen.

Regarding documenting contenteditable in current browsers, there is an ongoing effort by WHATWG to specify various APIs around contenteditable. Currently in the works is a spec for execCommand() (there are various threads concerning this on the WHATWG mailing list, check the archives). Preceding this was some research done on current browser behaviour. There’s also ongoing work on a new version of the DOM Range spec, now incorporating Selection as well. For Enter key behaviour in contenteditable elements, see this thread.