There should be no errors when indenting a code block

[oleq]

📝 Provide detailed reproduction steps (if any)

1. Go to the code blocks guide/manual test.
2. Call

editor.setData( `<pre><code class="language-css">	}
}</code></pre>` );

3. Select all the content (Ctrl+A) then click "Indent"

✔️ Expected result

The content is indented.

❌ Actual result

An error is thrown:

remove.js:16 Uncaught TypeError: Cannot read property 'parentNode' of undefined
    at remove (remove.js:16)
    at Renderer._updateChildren (renderer.js:557)
    at Renderer.render (renderer.js:203)
    at View._render (view.js:682)
    at View.<anonymous> (view.js:187)
    at View.fire (emittermixin.js:209)
    at View.change (view.js:479)
    at View._disableRendering (view.js:669)
    at Model.EditingController.listenTo.priority (editingcontroller.js:84)
    at Model.fire (emittermixin.js:209)

---

If you'd like to see this fixed sooner, add a 👍 reaction to this post.

[oleq]

After a quick check, it looks like an engine bug. What indent command does is inserting a tab \t at these two positions [ 0, 3 ] and [ 0, 1 ] (in this exact order):

It uses writer.insertText(). When I change \t into a letter (anything non–whitespace) the error is gone. The stack trace goes into the renderer so there's some white-space optimization there that fails.

[oleq]

Note: When you use

<pre><code class="language-css">	x
x</code></pre>

there will be an error. But when you use

<pre><code class="language-css">	x
y</code></pre>

no error is thrown. My guess is something's wrong with the node lists diffing. In the first case, the diff is

["insert", "insert", "equal", "delete", "delete"]

and in the second

["insert", "delete", "equal", "insert", "delete"]

while actualDomChildren and expectedDomChildren make sense in both cases. I think we had this kind of issue in the past (1 character diffs having problems telling which char is which). @Reinmar do you remember what it was?

[Reinmar]

It seems that it's related to couple other issues that we've seen. Closing for now as DUP of #6092.