Page MenuHomePhabricator

WikiEditor dialogs kill the undo buffer
Open, NormalPublic

Description

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

Details

Reference
bz31780

Event Timeline

bzimport raised the priority of this task from to Normal.
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 -- http://jsbin.com/ivaca 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?

He7d3r added a comment.May 5 2012, 6:22 PM
  • Bug 23509 has been marked as a duplicate of this bug. ***

beau wrote:

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

He7d3r added a comment.May 5 2012, 6:28 PM

I just noticed that the problem also happens with the old toolbar on this page:
https://en.wikisource.org/w/index.php?title=Page:The_book_of_try_and_learn.djvu/1&action=edit
(from bug 36544).

TheDJ updated the task description. (Show Details)
TheDJ lowered the priority of this task from Normal to Lowest.
TheDJ set Security to None.
TheDJ removed a subscriber: Unknown Object (MLST).
eranroz added a subscriber: eranroz.EditedOct 20 2017, 5:24 AM

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 https://stackoverflow.com/questions/16195644/in-chrome-undo-does-not-work-properly-for-input-element-after-contents-changed-p

see also:

eranroz added a subscriber: Kipod.Oct 20 2017, 5:24 AM
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 Normal.
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

https://gerrit.wikimedia.org/r/474520

TheDJ moved this task from Backlog to Doing on the WikiEditor board.Nov 27 2018, 1:45 PM

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

https://gerrit.wikimedia.org/r/474520

Jdforrester-WMF closed this task as Resolved.Dec 7 2018, 4:02 PM
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.

Restricted Application added a project: User-Ryasmeen. · View Herald TranscriptDec 7 2018, 4:02 PM
matmarex reopened this task as Open.Dec 10 2018, 6:40 PM
matmarex added a subscriber: matmarex.

Reverted in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/478734 due to concerns about compatibility with alternative editors that override the 'textSelection' API. This should be relatively easy to fix (see comments on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/474520), 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""

https://gerrit.wikimedia.org/r/478744