tdf#109376 sw: fix SwUndoDelete with end pos on SwTableNode crash

Commit 6ff263b837831d46d0c215963b70543a9ea5bd2a added a check in
SwUndoSaveContent::DelContentIndex() to avoid moving the anchor of a
FLY_AT_PARA if its new position would be a table node, because
SwFlyAtContentFrame::Modify() requires a SwTextNode to be the anchor.
However, that doesn't actually avoid moving the anchor - later,
SwNodes::RemoveNode() relocates the anchor to the next node regardless
of type!

It's probably better to just delete the fly in the situation when the
end position is a SwTableNode, which fixes the reported crash.

Unfortunately on Redo, the SwUndoDelete::UndoImpl() does not recreate
the nodes correctly, hence the fly then is inserted on the wrong node,
which later crashes again.

The problem is that due to the table node, a dummy SwTextNode is inserted,
which should be at the end of the range, but ends up at the start due to
an erroneous ++aPos.nNode; - the result is that the fly is inserted on
the dummy node and is immediately deleted again, triggering another
assert.  If there is a dummy node, it also doesn't make sense to call
SplitNode().

Yet another problem is that in SwUndoDelete::UndoImpl(), the frames for
the moved text nodes are not created, because the first node is skipped
with the wrong assumption that it already has frames.

Reportedly this started to crash with commit
e07feb9457f2ffb373ae69b73dda290140e4005f, previously it was just wrong.

Change-Id: I5094638e34c6ed52c836e57691d377b8cd1608f9
Reviewed-on: https://gerrit.libreoffice.org/70683
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>

0 files changed, 0 insertions, 0 deletions