How to track caret/cursor in contenteditable?

问题:

I'd like to track the movement of the caret/cursor in a contenteditable. I'm not sure what's the best way to do this, though.

I'm currently listening for click, keydown, keyup. (keypress of course doesn't even fire for things like arrow keys or ctrl-x.)

While click works fine, the problem with keydown is that it's fired before the caret actually moves, so when I query the current document selection range, I get the old position and not the new one. But if I rely on keyup to get the updated position, it fires too late: the caret moves as soon as the key is pressed down, but the key is released an arbitrary time later.

This must be possible because things like CKeditor are able to do this. Any hints?

回答1:

It's nice to read that people are talking about CKEditor :). I'm one of its developers and I haven't been working much on selection, but I'll try to help.

What I know is that we've got an internal selectionChange event. So when do we check if it changed? ... ... At least once per every 200ms :) See:

http://dev.ckeditor.com/browser/CKEditor/trunk/_source/plugins/selection/plugin.js#L39

We also check selection every time we know that it could have been changed (e.g. by the API or on keyup/mouseup or on native selectionchange - http://dev.ckeditor.com/browser/CKEditor/trunk/_source/plugins/selection/plugin.js#L554). So... pretty much all the time :) AFAIK we do some tricks, so it doesn't burn your CPU, but it's still heavy. However, if we did this, then it's the only possible way to have this working so nicely.

Unfortunately, selection handling is by far the worst task in wysiwygs world. It's so broken in all - old and new browsers. More than 75% LOC in the file I linked above are hacks and tricks. That's complete madness.

回答2:

In Mozilla and Opera, the nasty business of handling key and mouse events is your only option. Not only is it fiddly, it also doesn't cover every case: it's possible to change the selection via the edit and context menus (via Select All, for example). To cover that, you'd also need to add some kind of polling of the selection object.

However, in IE (all the way back to at least 5.5) and recent-ish WebKit, there is a selectionchange event that fires on the document whenever the selection changes.

document.onselectionchange = function() {
    alert("Selection changed!");
};

There is a chance that Mozilla will support it in the future: https://bugzilla.mozilla.org/show_bug.cgi?id=571294

回答3:

It's not an easy task for the reasons you said. I came up with some kludge like this:

var caretInterval, caretOffset;
document.addEventListener("keydown", function(e) {
    if (!e.target.contentEditable || caretInterval) return;
    if (e.keyCode !== 37 && e.keyCode !== 39) // Left and right
        return;
    var sel = getSelection();
    caretInterval = setInterval(function() {
        if (sel.type === "Caret") caretOffset = sel.baseOffset;
    }, 50);
});
document.addEventListener("keyup", function(e) {
    if (e.keyCode !== 37 && e.keyCode !== 39) // Left and right
        return;
    clearInterval(caretInterval);
    caretInverval = null;
    var sel = getSelection();
    if (sel.type === "Caret") caretOffset = sel.baseOffset;
});

There could be a small problem if someone tries to press left and right at the same time. For ctrl-X and ctrl-V, you should catch the cut and paste event, and that's actually another pain in the bollocks.

In the end, I decided it wasn't worth the effort for my purposes. Maybe you have different needs.

回答4:

WRT catching the event after the selection is updated: I simply wrap my handler functions in timeouts:

editor.onkeydown = function() {
  window.setTimeout( function(){
    // Your handler code here
  }, 0 );
};

This registers your handler to be executed in the browser's event loop as soon as possible, but after the current (eg click) event is processed. But be aware of possible races if you have other scripts modifying the content; there is no guarantee that your timeout is the next in line to be run.