TL;DR: Fixed in the next build.
So we're using one of the 2.5 billion jQuery plugins that detect the cursor/selection position in a textbox. This plugin was written back when Internet Explorer still required hacks to get this information. The way this particular plugin goes about doing this is as follows: Say your textbox contains
abcde, and you have selected
IE versions before IE9 didn't give you the position of the selection. They however allowed you to a) get the content of the selection, and b) manipulate the selection, both via a
TextRange object. So the plugin took the selection and shifted its end to end of the textbox:
ab[cde] -> tail = "cde"
Then it took the original selection and shifted its start to the beginning of the textbox:
[abcd]e -> head = "abcd"
The plugin also knows the full content of the textbox,
all = "abcde". With this information, you can get the start and end of the selection:
start = all.lastIndexOf(tail) // or just all.length if tail is empty
end = head.length
Bingo! This works in IE9, IE8, IE7, and probably all the way back to the hot days of Geocities.
So, what changed in IE10? For some reason, after the corresponding keyboard event, IE10 immediately updates the textbox
.value, but sometimes waits for something like 200ms to update the corresponding
TextRange data, sometimes ignores spaces, etc. Bottom line:
TextRange suddenly is buggy. Well, horribly broken.
So in your particular case, when the textbox looked like this (
_ is a space,
| is the cursor):
we got the following values:
all = "some-tag " // correct, including space
head = "some-tag" // incorrect
tail = ""
start = all.length = 9
end = head.length = 8
start != end means there's not just a cursor, there's a selection!
And when there's text selected in the tag editor, we don't render tags as tags, but make the full thing editable*. That's why you didn't get the nicely rendered tags.
Fortunately, Internet Explorer since version 9 supports the standard
selectionEnd properties, so the above hack is no longer necessary. I've changed the plugin to use the (apparently not buggy) standard interface by default, which makes the tag editor work as expected again.
*This is because the tag editor only simulates the behavior of a normal textbox. Doing this correctly when there's a text selection is impossible if the browser doesn't support
selectionDirection, which only recently appeared in some browsers. Thus when there's a selection, we switch to giving you an actual textbox.