Last modified: 2014-01-30 18:24:41 UTC
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.
Confirmed in IE 8.0.7600.16385 and Chrome 14.0.835.202m, on English Wikipedia today.
Works correctly in Firefox 7.0.1.
Other buttons and dropdowns work fine, allowing undo with ctrl-Z.
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.
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?
*** Bug 23509 has been marked as a duplicate of this bug. ***
*** 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).