It seems that this was already mentioned, but since I just came across this issue myself and the tag editor has been fully deployed, I opted to turn it into a formal bug report. If you select text that borders a tag to the left in the tag editor, and press the backspace key, it de-tagifies the tag to the left and doesn't delete the selected text.


tag editor gone haywire

It looks like the keydown handler for the text field only lets the backspace event through if the caret start position is greater than zero. It should also take into account the situation where text is selected when the backspace key is pressed, with something like the following change (referencing the minified code function P(U)):

case 8:
    if (!T || W !== J.caret().end) {
        return true;
  • For more fun, with your cursor at the end of your 2nd "reputation" in your example, hit shift+left-arrow or ctrl+shift+left-arrow. – Rebecca Chernoff Aug 30 '11 at 7:44

Nope; the issue was actually something else: The mere fact that you were able to select text while still having styled tags. That was not supposed to be possible, but wasn't prevented in all cases (it is now). All other code (including the snippet you mention) relies on that.

The reason is this: In our reinvented text box, assume you are editing the last tag. You press the shift key and the press the left arrow over and over again, creating a selection. At some point, you have reached the beginning of that tag, so what you rightfully expect is that pressing Shift-Left a few more times also selects the last letters of the previous tag.

At the moment you "crossed the border" between the tags, the previous tag has to turn from styled to editable, in other words, we have to change the content of the actual input box. Unfortunately, you can't change the input box content without losing the selection. Of course we could remember the selection and, after changing the content, re-select the correct part.

But: It ain't gonna work. If we did that, and you pressed Shift-Left again, your selection suddenly wouldn't grow at the beginning; it would shrink at the end.

Until there is good browser support for the selectionDirection property (Firefox was the first to implement it, and that was a few weeks ago), there is no way to set the selection correctly in this case (you also can't get the direction of the selection, but it may be possible to work around this by remembering the "evolution" of the selection – it doesn't matter, because there's no way to set a backwards-facing selection).

This problem is the reason why as soon as there is any selection, we immediately bail out and just make the whole content editable.

  • Ah, I guess that is more consistent with the other behaviours (like pressing Shift + End). Makes sense. – Tim Stone Aug 30 '11 at 10:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .