Editor crashes with a downcasting error when input contain an empty <tr></tr>

[hponcet]

This was fixed if i hard replace the source html by replace(/<tr[^<]*><\/tr>/gm, '<tr><th></th></tr>')

[Mgsy]

Hello, can you provide step-by-step instruction on how to reproduce the issue in the editor?

[jodator]

Hmm this will break the editor, ie in the article manual test:

<table><tr></tr><tr></tr></table>

Error:

article.js:44 TypeError: Cannot read property 'name' of undefined
    at Mapper.getModelLength (mapper.js:422)
    at Mapper._findPositionIn (mapper.js:487)
    at Mapper.on.priority (mapper.js:88)
    at Mapper.fire (emittermixin.js:207)
    at Mapper.toViewPosition (mapper.js:271)
    at DowncastDispatcher.modelViewSplitOnInsert (converters.js:198)
    at DowncastDispatcher.fire (emittermixin.js:207)
    at DowncastDispatcher._testAndFire (downcastdispatcher.js:466)
    at DowncastDispatcher.convertInsert (downcastdispatcher.js:177)
    at DowncastDispatcher.convertChanges (downcastdispatcher.js:136)

[mlewand]

The thing is that ideally we should not end up with model that has content like that - this is clearly pointless table markup.

We did put extra effort in iteration 30 to make sure no empty rows are created by our core plugins (ckeditor/ckeditor5-table#277, ckeditor/ckeditor5-table#278). But in the end we decided that we need to fix the source of the issue, rather to make all our algorithms work with flawed table structure.

I mentioned that there will be issues like this popping out with time, and we can see some examples:

• Table loses geometry after horizontal split and removing column #6439
• This very issue, although there's unfortunately no repro-case the easiest one I can see is simply pasting content from external sources - we will never be able to guarantee that the content doesn't contain empty rows (think of copying part of other page, pasting from Word, other WYSIWYG editors).

That being said I believe we should change our approach and gracefully handle case with empty row.

[jodator]

I mentioned that there will be issues like this popping out with time, and we can see some examples:

The issues you mentioned comes from, unfortunately, wrong table handling in our commands. The fixes are on the way: #6545 & #6546. 

However we should make our conversion process resilient and anticipate wrong input data.