Last modified: 2012-02-22 12:37:18 UTC
Created attachment 9480 [details] Patch fixing this bug To reproduce: 1. Open IE8, visit some page at a WMF project (I tried it with [[commons:User:Lupo]]) 2. Click "edit" 3. Place the cursor and/or select some text in the textarea. Choose a location somewhere in the middle of the text, not at the start. 4. Click on "Special characters" on the toolbar. Wait for the section to load. 5. Now change the character page: If "Latin" is displayed, click "IPA". The selection in the textarea disappears. 6. Click on any of the characters on the IPA page (without re-selecting in the textarea, obviously!) 7. The character is inserted at the very beginning of the text instead of where the cursor/selection was. Expected behavior: * After step 5, the selection is active in the textarea. * In step 7, the character is inserted at the cursor position or replaces the selection. The attached patch for jquery.wikiEditor.toolbar.js : * solves this problem by saving the selection on mousedown and restoring at the end of the click handler of the bookmark, * removes a stray linebreak, * and makes sure that page tables are properly closed.
BTW, is there some reason why some click handlers in this code access the context through $( this ).data ( 'context' ) even though the context is available in the closure scope as variable "context"? The mousedown handlers generally just use the latter...
Another question: it seems anyway that the iframe stuff overrides this selection saving/restoring to not do anything, and likewise the CodeEditor. This appears to be specific to the textarea and IE. Couldn't we make the textarea itself keep track of its own selection, and get rid of these save/restore calls sprinkled throughout the code? Using IE-specific events 'beforedeactivate' (save selection) and 'activate' (restore it) on the textarea, this should be possible.
(In reply to comment #2) > Another question: it seems anyway that the iframe stuff overrides this > selection saving/restoring to not do anything, and likewise the CodeEditor. > This appears to be specific to the textarea and IE. Couldn't we make the > textarea itself keep track of its own selection, and get rid of these > save/restore calls sprinkled throughout the code? Using IE-specific events > 'beforedeactivate' (save selection) and 'activate' (restore it) on the > textarea, this should be possible. This code is mostly hacks piled on hacks, so if you have a way to make it nicer, patches are welcome :) I'll review the patch from comment #0 later, probably over the weekend.
Patch committed in r103761.
