[Webkit/Blink] New strategy for Filling Character handling to avoid changes in DOM

[Olek Nowodziński]

At the moment…

Basic concepts

1. FillingChar (FC) is a ZWS text node.
2. selection.selectRanges() creates FC in Webkits to put selection in tricky places.
3. FC is not welcome in data returned from the editor and Undo Manager snapshots.
4. There may be a single FC in the editor at the time. There could be many other ZWSs there as well, as a regular user content.

Lifespan of FC

1. FC is removed from DOM as soon as possible, when no longer necessary.
2. FC is removed from DOM on #selectionChange.
   1. FC always survives first #selectionChange.
   2. It is removed on the second event because the first one is always fired by selectRanges() (so it isn't nuked right after created).
3. FC is removed from DOM before (on) certain #keydown events (<kbd>ENTER</kbd>, <kbd>LEFT/RIGHT ARROW</kbd>, <kbd>BACKSPACE</kbd>, etc.) to not to disrupt the commands.

FC and data processing

1. On #beforeGetData and #beforeUndoImage, if the selection is in the FC text node, a "native bookmark" is created and saved because changes in DOM done in the next point will break the selection.
2. On #beforeGetData and #beforeUndoImage, the FC's content (if present) is saved and then replaced in DOM with
   1. nothing (FC becomes an empty text node)
   2.  , if the white–space is right after it
3. Data is retrieved from editor DOM (editor.getData()), or an undo snapshot is created (CKEDITOR.instances.editor.undoManager.snapshots.map( s => s.contents )). Both data and snapshots are FC–free.
4. On #getData and #afterUndoImage FC's text in DOM is reverted back to the state saved on #beforeGetData or #beforeUndoImage.
5. On #getData and #afterUndoImage the native selection, devastated on #beforeGetData or #beforeUndoImage by changes to FC text content, is finally restored.

Problems

1. Because FC is removed from DOM on various data operations:
   1. A native #selectionchange is fired by document. It creates an infinite loop (#13593) if such listener is to be used in the editor.
   2. IME (Composition) gets broken when Undo Manager snapshot is taken. This is because FC is removed from DOM and the native selection changes. Try setInterval( function() { var i = new CKEDITOR.plugins.undo.Image( CKEDITOR.instances.editor ); console.log( i.contents ) }, 2000 ); and start composition.

Related tickets

• #12727
• #13377
• #13284
• #13389
• #13307
• #13284

---

A new approach

Basic concepts

1. When retrieving data or creating Undo Manager snapshots, remove FC from HTML strings, but not from DOM.
   1. How to tell which ZWSs are user content in HTML string and which belong to FC then?!
      1. The trick is to use a number of ZWS for FCSeq. Like 7, or 8. Or 42.
      2. It makes finding FCSeq in the contents much easier. If there are always 7 ZWS for FCSeq, any group of 7 ZWS can be removed and, if there are like 10 ZWS, the algorithm will know that 3 ZWS belong to the user content (still 7 to left to purge).

getData

1. Do noting on #beforeGetData.
2. Remove a pre–defined number of ZWS from HTML string (don't touch the DOM).

getSnapshot

1. Remove a pre–defined number of ZWS from HTML string (don't touch the DOM).

SelectionChange, keyboard events

1. FCSeq is removed from DOM on selectionChange and on keyboard events, just like in the "old approach".

Problem with bookmarks

1. createBookmark2( true ) is used to create undo snapshots. It normalizes snapshot content so adjacent text nodes are considered a single text node.
2. Because FCSeq is removed from HTML string while a snapshot is being taken (previously removed from DOM before the operation), addresses and offsets in the bookmark may be incorrect.
   1. The bookmarking algorithm must be smart to anticipate that the FCSeq visible in DOM will be gone in the snapshot data.
   2. Bookmark addresses and offsets must be corrected so when the bookmark is restored, the selection is correctly anchored.
   3. It is fun!

[Olek Nowodziński]

Pushed ​branch:t/13816 (previously "zws") with the new approach.