* (bug 31847) Fix positioning of WikiEditor 'header' insertions when selection is...

Follows up to the test cases added in r100391. jquery.textSelection's getCaretPosition() for IE needs to focus the textarea first in order to get consistent results when there's an empty selection -- getSelection() which returns the text already does this.

Because focus had previously been stolen by the drop-down menus in WikiEditor's toolbar, the saveCursorAndScrollTop() was getting a bogus result from getCaretPosition, saving that, then restoring the bad selection (wiping out the original caret position) right before going ahead with the encapsulateText call.

Now seems to get the correct caret position, and also doesn't appear to interfere with selections.

diff --git a/resources/jquery/jquery.textSelection.js b/resources/jquery/jquery.textSelection.js
index 8a1f44b..158f205 100644 (file)
--- a/resources/jquery/jquery.textSelection.js
+++ b/resources/jquery/jquery.textSelection.js
@@ -208,12 +208,20 @@ encapsulateSelection: function( options ) {
  * Get the position (in resolution of bytes not nessecarily characters)
  * in a textarea
  *
+ * Will focus the textarea in some browsers (IE/Opera)
+ *
  * @fixme document the options parameters
  */
  getCaretPosition: function( options ) {
        function getCaret( e ) {
                var caretPos = 0, endPos = 0;
                if ( $.browser.msie ) {
+                       // IE doesn't properly report non-selected caret position through
+                       // the selection ranges when textarea isn't focused. This can
+                       // lead to saving a bogus empty selection, which then screws up
+                       // whatever we do later (bug 31847).
+                       e.focus();
+
                        // IE Support
                        var preFinished = false;
                        var periFinished = false;