Page MenuHomePhabricator

(IE8) Click on bookmark in enhanced toolbar loses selection
Closed, ResolvedPublic

Description

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.

Version: unspecified
Severity: normal
Platform: PC

Attached:

Details

Reference
bz32451
TitleReferenceAuthorSource BranchDest Branch
Fix statements generated for updating actor datarepos/mediawiki/services/ipoid!42tchandersdiffing-fix-updatemain
Customize query in GitLab

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 12:07 AM
bzimport set Reference to bz32451.
bzimport added a subscriber: Unknown Object (MLST).

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.