Page MenuHomePhabricator

WikiEditor dialogs kill the undo buffer
Open, MediumPublic


In WikiEditor, if you use the Link dialog (or any other 'dialog') to insert text into the edit box, then press control-Z, the edit does not get undone. This is true of all the supplied dialogs, including one I custom-developed.

Affected browsers:

  • Confirmed in IE 8.0.7600.16385 and Chrome 14.0.835.202m, on English Wikipedia today.
  • Works correctly in Firefox 7.0.1.
  • Chromium 68.0.3440 - even worse (ctrl+Z changes wrong text taht was never edited)
  • Firefox 62.0 - Killed the undo buffer --------------------------

See Also: T37887

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:53 PM
bzimport added projects: WikiEditor, Upstream.
bzimport set Reference to bz31780.
bzimport added a subscriber: Unknown Object (MLST).

Raising the priority and changing the title -- this problem actually kills the entire "undo" buffer for the textarea in IE and Chrome.

By "kills the undo buffer," I mean that once you insert text via a dialog, the textarea's current undo buffer gets cleared. So any previous typing you've done can no longer be undone via ctrl-Z.

Actually, if you merely *display* a WikiEditor dialog, it clears the undo buffer. You don't even have to use the dialog. Just displaying it is enough to trigger the problem.

Simple test:

  1. Edit an article in IE8 or Chrome.
  2. Type "abc"
  3. Click the Link button to display the Link dialog
  4. Hit ESC to close the dialog (don't use it in any other way)
  5. Type ctrl-Z. The "abc" cannot be undone.

Clarification to the preceding comment:

  • In IE, merely displaying and closing the dialog kills the undo buffer.
  • In Chrome, inserting text via a dialog kills the undo buffer. Merely displaying the dialog does not.

Looks like IE resets the undo buffers when elements get added to the DOM -- shows an example page.

Not sure there's much we can do about that; seems to happen through IE 9. :P The dialog setup would be clearing the buffer, I guess.

On Chrome I can confirm that it seems to reset the undo buffer when we do an insert even through for instance the bold button, which has no dialog. Looks like changing the textarea contents itself resets the undo buffer... which seems to defeat the purpose. ;)

On IE 8, the bold button seems to integrate properly into the undo/redo buffers. Type "xxx", then double-click a word and boldify it. First undo undoes the bold, second undoes the "xxx".

On IE 9, the bold button *almost* seems to be ok, but is actually messed up. First undo instead of removing the bold removes a few characters at what was originally the offset of the "xxx", but isn't anymore because we've added characters for the bold. Eeek!

[Note that on IE we do encapsulateText insertions through selection manipulation, while on other browsers we have no such API and perform them by splicing some strings and replacing the text contents of the entire textarea.]

This is totally an upstream problem, then, right?

  • Bug 23509 has been marked as a duplicate of this bug. ***

beau wrote:

*** Bug 36544 has been marked as a duplicate of this bug. ***

I just noticed that the problem also happens with the old toolbar on this page:
(from bug 36544).

TheDJ lowered the priority of this task from Medium to Lowest.Mar 21 2015, 9:09 AM
TheDJ updated the task description. (Show Details)
TheDJ set Security to None.
TheDJ removed a subscriber: Unknown Object (MLST).

Is it upstream bug in all the browsers? if yes - it would be nice if someone can link either to specific upstream bugs in Chrome/IE/FF or at least find the relevant spec in W3C explaining the correct behaviour.
If not - we can use execCommand as explained

see also:

eranroz renamed this task from WikiEditor dialogs kill the undo buffer in IE and Chrome to WikiEditor dialogs kill the undo buffer.Sep 11 2018, 5:14 AM
eranroz raised the priority of this task from Lowest to Medium.
eranroz updated the task description. (Show Details)

Change 474520 had a related patch set uploaded (by TheDJ; owner: TheDJ):
[mediawiki/core@master] textSelection: Use execcommand to replace text

Change 474520 merged by jenkins-bot:
[mediawiki/core@master] textSelection: Use execcommand to replace text

Jdforrester-WMF assigned this task to TheDJ.

Worked around for everyone except Firefox. Hopefully Mozilla will eventually fix that issue, but our work here is done.

matmarex added a subscriber: matmarex.

Reverted in due to concerns about compatibility with alternative editors that override the 'textSelection' API. This should be relatively easy to fix (see comments on, but somewhat time-consuming to verify that everything works correctly. Extensions to test: CodeEditor, CodeMirror, ProofreadPage, VisualEditor (NWE).

Change 478744 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/core@master] Revert "Revert "textSelection: Use execcommand to replace text""

TheDJ removed TheDJ as the assignee of this task.Jan 29 2020, 11:18 PM

I cannot reproduce this issue in IE11 and earlier IE versions are not supported as WikiEditor is a Javascript component (as I assume that it follows the MW browser support matrix). Does the title need to be updated to show that another supported browser is still having an issue or should this task be resolved?