Introduced deep children text nodes rerendering

[f1ames]

Suggested merge commit message (convention)

Other: Introduced deep children text nodes rerendering. Closes ckeditor/ckeditor5#4174. Closes ckeditor/ckeditor5#4156. Closes ckeditor/ckeditor5#3103.

---

Additional information

The proposed solution is very similar to what was initially proposed by @scofalik - https://github.com/ckeditor/ckeditor5-engine/issues/1125#issuecomment-332791847. The logic marking text nodes is placed in renderer._updateChildren as this is the place where element nodes are modified and based on that modifications we can decide which elements' text nodes should be considered for rerendered.

The mutation observer change is also described here - https://github.com/ckeditor/ckeditor5-engine/issues/1125#issuecomment-373376368.

[coveralls]

Coverage remained the same at 100.0% when pulling c193379 on t/1125 into 679acf6 on master.

[Reinmar]

@Mgsy Could you check this PR? There's a wide range of test cases so we should ba careful.

[f1ames]

This PR introduces mechanism which forces rerendering of sibling text nodes of the text node which was modified.

One visible issue of previous behaviour is described in #1093 - in general, renderer failed when changes in one text node required rerendering of some of its sibling (e.g. spaces rerendering in siblings). And the introduced change takes care of that. Here renderer._updateText function was not changed so rendering happens in the same manner (text is rerendered only if it different than existing ones). The only difference is that it is executed for more text nodes than before.

The other change which may have some impact is change in rendering order. Previously, text nodes were rerendered first and element nodes after that. Now due to the logic which was applied (rerender children text nodes of synced element nodes), the order was changed so element nodes are rerendered before text nodes. So it may affect any operation which does more complex changes (so updating text/elements or its attributes at the same time) and probably we should look for any regressions in such cases.

The last thing was a change in processing mutations already described in https://github.com/ckeditor/ckeditor5-engine/issues/1125#issuecomment-373376368. Here it affects how mutations are generated (previously view element was passed with its children to mutation event and now it's passed without it). The scenarios which may get affected by this change are some bigger content modifications (when some bigger part of content, especially with deep structure, gets changed or partially updated) and also cases (I'm not sure if there are any of such situations) when editing one element inside editor changes the other one not in the subtree (so not a child but sibling or any not directly structurally connected element).

[Mgsy]

I've spent some time testing this one. It fixes mentioned issues and I haven't noticed any regressions caused by this fix.

[Reinmar]

There's one thing that would make us feel safer – a test which checks rendering one big batch of various type of changes – in text nodes, removing, adding elements in various places on various levels of a tree. The troublesome part is how text updates mix with element updates due to shifts in indexes.

[f1ames]

a test which checks rendering one big batch of various type of changes – in text nodes, removing, adding elements in various places on various levels of a tree...

Makes perfect sense, I will try to create such test so we could check if the change in rendering order had some unexpected effects.

[scofalik]

I wonder when this else path is taken (what else could viewElement be), but CC is 100%.

[f1ames]

Theoretically it shouldn't be anything else so simple if - else should be sufficient. But checking it in both cases is more future proof.

[f1ames]

@scofalik after merging master one unit test from model (looks irrelevant to the changes - model/document/should call all already processed callbacks again if a callback returned true) started to fail on Travis 🤔 But it seems master itself passes on Travis.

[scofalik]

Edit: I haven't seen your comment.

For me the PR looks good. I've pushed some slight changes in docs and merged master.

[f1ames]

And I pushed tests @Reinmar requested, so now we just need to figure out why this one test is failing on Travis.

[f1ames]

This test also fails on ckeditor5-engine#master - https://travis-ci.org/ckeditor/ckeditor5-engine/builds/359328562#L2272 so it is not related to this PR.