restoreSelection doesn't always work in internet explorer

[douglas]

When restoring a selection in internet explorer, if the textrange object points to the end of a text node that immediately precedes a block element, the selection isn't properly restored. This is because of a bug in IE when calling the select() method on a TextRange?. The cursor is moved forward one node into the beginning of the following block node.

[douglas]

Test case that demonstrates the problem

[douglas]

r1040 Offers up three different fixes ('InsertSpan?', 'JustificationHack?', and 'VisiblePrompt?', the default) each with different tradeoffs for the user. The fix is user configurable by setting 'selectWorkaround' in the config to one of the three options.

[ray]

Doug, there is a function Xinha.uniq() in the core which provides a globally unique id based on an increasing number, which I think you should use in your code

[douglas]

Ray, I already looked at Xinha.uniq(), but it's designed to give a unique id over the lifetime of the Xinha instance. Because of the nature of the IE workaround, it's unfortunately possible to litter these spans back into the document (and a large number of them, which is why this fix is not the default). In this instance, in a worst case situation, I would be going back to uniq() to pull id after id to try and get one that is unique. By doing it with a random suffix and an increasing keyspace, I keep from having to search linearly through the list of ids. My solution doesn't work in a general case, which is why I can't port it back to uniq(), but in this specific situation it has a lower chance of causing problems.

[ray]

Doug, your patch produces an error

Line: 427
Error: 'undefined' is Null or not an object

[nicholasbs]

What version of IE are you using, Ray? I'm pretty sure Doug's been testing against IE 6 and 7, so it might be an issue with IE8 if you're using that.

[ray]

rev [1056]: Ok, the bug was not really in your patch, it just revealed it. It was Dialog.hide() that called restoreSelection(), and wrongly so for example with Stylist as already assumed by nicholas in a code comment. restoreSelection() in Dialog.hide() makes only sense with modal dialog, as the selection is only saved with those in Dialog.show(). For safety I nevertheless return in restoreSelection() when no savedSelection is passed