Source view: Undo removes all content

[Geir Helge Tjøstolvsen-Schmidt]

Browsers: Firefox 2.0.0.11 (win+lin), IE6+7

1. Go to ​http://www.fckeditor.net/demo/
2. Open source view
3. Press ctrl+z

What happens: All the content is removed.

What I expect: Only changes that I've done to be removed, not all the source.

You'll have to use ctrl+y (or ctrl+shift+z) to get the content back because the undo/redo buttons in the tool bar are deactivated. Personally I think that's ok, but several users claim to know about the ctrl+z shortcut and not the redo shortcut.

[Wojciech Olchawa]

Confirmed in IE, IE7 and FF

[Artur Formella]

The same bug occurs in V3 (changeset 3667).

[Tobiasz Cudnik]

Although this patch doesn't resolve issue in all browsers, but i found it interesting and decided to post it here. It simply iterates over older UndoManager snapshots, setting it as textarea content (from oldest to newest). This results in CTRL+Z / CTRL+R working in Gecko for previous states, but unfortunately does not work in IE and webkit.

I think only possible way will be extending UndoManager to support other editor modes.

[Tobiasz Cudnik]

Even if it's not a complete patch, i'm asking for a review to confirm i'm going correct way in this.

Whats right now is cooperation between wysiwyg and source modes inside undoManager, achieved by snapshot normalization (on demand, cached). Each mode keep their own snapshot. If one mode wants compare it's content with previous snapshot from other mode, it normalizes it. All undoManager code is reused inside sourcearea.

Whats missing is selection support in source view. Question related to this - should bookmarks also be stored on per-mode basis ? Then bookmarks normalization method is needed.

[Garry Yao]

As I can see, patch 1630_2_ref.patch is completely about a new feature: seamless undo/redo support in both source/wysiwyg mode, I'm not sure if we should proceed it right now with this ticket.
While the idea of the approach( normalize source/wysiwyg mode content ) is interesting, the performance penalty ( caused by 'toHtml/toDataFormat' ) brought by it would definitely be considered.

[Garry Yao]

Another concern regarding the usefulness of this feature : as we have no commands that operate on the source area html right now, when would the snapshot been saved? It sounds strange if it's just used on user forced redo/undo keystroke.

[Tobiasz Cudnik]

> performance penalty ( caused by 'toHtml/toDataFormat' ) brought by it would definitely be considered

Normalization is lazy and cached, so performance should be acceptable. Nerveless i have not profiled it. Other approach would be taking snapshots from all modes normalized from the beginning, but this could consume much more performance.

> when would the snapshot been saved?

Snapshot saving conditions are same as for WYSIWYG area, so this includes

• after certain amount of chars
• on modifier keys (eg delete)

This is handled by the exact same code.

[Tobiasz Cudnik]

Marking it as new feature, as it's not a bug, but missing functionality.

[Garry Yao]

Defer it as users can at least undo/redo with shortcut keys to trigger browsers' native capability.

[Frederico Caldeira Knabben]

Milestone CKEditor 3.x deleted

[Piotrek Koszuliński]

I couldn't reproduce this issue on latest FF, Chrome and IE9.